php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58368 32-bit Client does not work with 64-bit ids
Submitted: 2008-10-06 10:30 UTC Modified: 2008-11-13 05:00 UTC
From: brianlmoon@php.net Assigned:
Status: Closed Package: sphinx (PECL)
PHP Version: 5.2.4 OS: Mac OS
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: brianlmoon@php.net
New email:
PHP Version: OS:

 

 [2008-10-06 10:30 UTC] brianlmoon@php.net
Description:
------------
Sphinx servers compiled with --enable-id64 are capable of storing 64 bit integers for document ids.  The PECL client wraps those ids into negative numbers.  The PHP class that comes with sphinx preserves those values, even on 32-bit client hardware.

Reproduce code:
---------------
$cl = new SphinxClient();
$cl->SetServer( SPHINX_PRODUCT_DATA_SERVER, 3312 );
$cl->SetLimits( $start, $limit, 1000 );
$res = $cl->Query( $keywords );
print_r($res);


Expected result:
----------------
Result using packaged PHP class:

[matches] => Array
       (
           [415000000260] => Array
               (
                   [weight] => 2
                   [attrs] => Array
                       (
                           [vendor_id] => 415
                       )

               )

           [415000001443] => Array
               (
                   [weight] => 2
                   [attrs] => Array
                       (
                           [vendor_id] => 415
                       )

               )


Actual result:
--------------
Example print_r of sphinx result from PECL:

[matches] => Array
       (
           [-1611827452] => Array
               (
                   [weight] => 2
                   [attrs] => Array
                       (
                           [vendor_id] => 415
                       )

               )

           [-1611826269] => Array
               (
                   [weight] => 2
                   [attrs] => Array
                       (
                           [vendor_id] => 415
                       )

               )


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-10-07 04:36 UTC] tony at daylessday dot org
I don't have a 32bit machine, so please try this patch:
http://dev.daylessday.org/diff/sphinx_32bit.diff
 [2008-10-13 17:40 UTC] brianm at dealnews dot com
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c: In function 'php_sphinx_result_to_array':
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c:200: warning: passing argument 4 of 'add_assoc_string_ex' makes pointer from integer without a cast
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c:200: warning: passing argument 5 of 'add_assoc_string_ex' makes integer from pointer without a cast
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c: In function 'zim_SphinxClient_updateAttributes':
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c:867: error: 'uchar' undeclared (first use in this function)
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c:867: error: (Each undeclared identifier is reported only once
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c:867: error: for each function it appears in.)
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c:867: error: syntax error before 'id_type'
/Users/brianm/src/sphinx-0.2.0-patched/sphinx.c:883: error: 'id_type' undeclared (first use in this function)
 [2008-10-14 03:29 UTC] tony at daylessday dot org
Updated/fixed the patch.
 [2008-10-14 09:24 UTC] brianlmoon@php.net
Builds now.  I will test it when I get back to my office.
 [2008-10-29 14:53 UTC] nobleclem at fatalexception dot us
I tried the patch on FreeBSD 7 RC2 and I am still getting different results using the same test code but using the sphinxapi.php on one and using the extension with the other.
 [2008-11-10 09:31 UTC] brianlmoon@php.net
Ok, I have confirmed that this patch fixes the problem.  Please release when you can.  Thanks a lot.  Sorry for my delay in testing this.
 [2008-11-10 09:42 UTC] tony at daylessday dot org
Ok, committed the patch.
nobleclem at fatalexception dot us, can you check if the latest CVS version works for you?
See http://cvs.php.net/viewvc.cgi/pecl/sphinx/
 [2008-11-11 23:03 UTC] nobleclem at fatalexception dot us
Tested it on two systems but I think my issue is slightly different.  Looking at brianlmoon at php dot net in a little more detail he was having a problem with the ID's.  The problem I am having still are with attribute values > 32bit.  The native PHP sphinx library works fine however I am still getting negative values for attributes just like he was getting for ID's.

From "$ php -i":
----------------
sphinx support => enabled
Version => 0.2.0
Revision => $Revision: 1.13 $

Expected result:
----------------
[matches] => Array
                (
                    [0] => Array
                        (
                            [id] => 20080995581
                            [weight] => 1
                            [attrs] => Array
                                (
                                    [term_code] => 200809
                                    [crn] => 95581
                                    [class_code] => 1777078230
                                    [class] => 1862662430
                                    [subj_code] => 1295937198
                                    [crse_numb] => 1050
                                    [start_date] => 1226757600
                                    [end_date] => 1227376500
                                    [ssts_code] => 2147483647
                                    [edtogo_code] => 0
                                    [order_title] => 506
                                    [audiences] => Array
                                        (
                                            [0] => 2775031812
                                        )

                                    [categories] => Array
                                        (
                                            [0] => 929050978
                                            [1] => 4091002307
                                        )
                                )

                        )

                )

Actual result:
--------------
[matches] => Array
                (
                [0] => Array
                    (
                        [id] => 20080996352
                        [weight] => 1
                        [attrs] => Array
                            (
                                [term_code] => 200809
                                [crn] => 95581
                                [class_code] => 1777078230
                                [class] => 1862662430
                                [subj_code] => 1295937198
                                [crse_numb] => 1050
                                [start_date] => 1226757600
                                [end_date] => 1227376500
                                [ssts_code] => 2147483647
                                [edtogo_code] => 0
                                [order_title] => 506
                                [audiences] => Array
                                    (
                                        [0] => -1519935484
                                    )

                                [categories] => Array
                                    (
                                        [0] => 929050978
                                        [1] => -203964989
                                    )
                            )

                    )

            )
 [2008-11-12 03:45 UTC] tony at daylessday dot org
Ah, I think I got the problem.
Please check out this patch:
http://dev.daylessday.org/diff/pecl_14752.diff
 [2008-11-12 09:57 UTC] nobleclem at fatalexception dot us
No luck.  Also there is a typo in the patch.

line 32 of patch file
find: sizof
replace: sizeof

One more strange thing is that on the FreeBSD 7 system I get a slightly different result (see ssts_code attr).  But I ran this patch also on a CentOS4 system and I get the same result with a correct ssts_code value.

If there is anything else I can try to help figure out this bug please let me know.

FreeBSD 7 Result:
-----------------
[matches] => Array
                (
                    [0] => Array
                        (
                            [id] => 20080996352
                            [weight] => 1
                            [attrs] => Array
                                (
                                    [term_code] => 200809
                                    [crn] => 95581
                                    [class_code] => 1777078230
                                    [class] => 1862662430
                                    [subj_code] => 1295937198
                                    [crse_numb] => 1050
                                    [start_date] => 1226757600
                                    [end_date] => 1227376500
                                    [ssts_code] => -740712821
                                    [edtogo_code] => 0
                                    [order_title] => 506
                                    [audiences] => Array
                                        (
                                            [0] => -1519935484
                                        )

                                    [categories] => Array
                                        (
                                            [0] => 929050978
                                            [1] => -203964989
                                        )
                                )

                        )

                )
 [2008-11-12 10:10 UTC] tony at daylessday dot org
>No luck. 
Be more precise, please.

>One more strange thing is that on the FreeBSD 7 system I 
>get a slightly different result (see ssts_code attr). 
Yes, FreeBSD is known for its weirdness.

>If there is anything else I can try to help figure out 
>this bug please let me know.
Please try to adjust the patch, there are only a couple of lines, so that should not be that difficult, or we can play this try-and-fail game forever.
 [2008-11-12 21:15 UTC] nobleclem at fatalexception dot us
Took me some time to figure this out but here is my patch.

http://fatalexception.us/scripts/pecl/sphinx/pecl_sphinx_64bit.diff

I ended up having to switch from using a float to a double because even after getting the attr values converted correctly I still had some values not converting properly while others were.  My guess is the number ran beyond what the single float could handle.
 [2008-11-13 05:00 UTC] tony at daylessday dot org
Patch applied, thanks a lot.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 05:01:28 2024 UTC