Bug 444228 - sdp broken with symbian phones (broken compile)
Summary: sdp broken with symbian phones (broken compile)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez-utils
Version: 9
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: David Woodhouse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 446580 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-25 20:59 UTC by Pierre Ossman
Modified: 2008-06-27 19:35 UTC (History)
3 users (show)

Fixed In Version: 3.32-1.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-27 19:35:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
hcidump -XV from good run (2.05 MB, text/plain)
2008-04-27 09:13 UTC, Pierre Ossman
no flags Details
hcidump -XV from bad run (4.65 KB, text/plain)
2008-04-27 09:13 UTC, Pierre Ossman
no flags Details

Description Pierre Ossman 2008-04-25 20:59:52 UTC
There is something miscompiled with the bluez-utils package currently in
rawhide. hcid fails to look up services when queried by a symbian phone.

Recompiling the RPM on my rawhide machine gives a working binary though, so it
seems the build servers had something broken on them when this package was produce.

Comment 1 Pierre Ossman 2008-04-25 21:05:51 UTC
For reference, here's how your binary reacts:

hcid[5075]: Got a svc srch req
hcid[5075]: Seq type : 53
hcid[5075]: Data size : 3
hcid[5075]: Data type: 0x19
hcid[5075]: No of elements : 1
hcid[5075]: Expected count: 65535
hcid[5075]: Bytes scanned : 5
hcid[5075]: Continuation State size : 0
hcid[5075]: Match count: 0
hcid[5075]: Sending rsp. status 0
hcid[5075]: Bytes Sent : 10

And here's how my binary (built with rpmbuild) does the same thing:

hcid[26107]: Got a svc srch req
hcid[26107]: Seq type : 53
hcid[26107]: Data size : 3
hcid[26107]: Data type: 0x19
hcid[26107]: No of elements : 1
hcid[26107]: Expected count: 65535
hcid[26107]: Bytes scanned : 5
hcid[26107]: Continuation State size : 0
hcid[26107]: Checking svcRec : 0x0
hcid[26107]: Checking svcRec : 0x1
hcid[26107]: Checking svcRec : 0x10000
hcid[26107]: Checking svcRec : 0x10001
hcid[26107]: Checking svcRec : 0x10002
hcid[26107]: Checking svcRec : 0x10003
hcid[26107]: Checking svcRec : 0x10004
hcid[26107]: Match count: 1
hcid[26107]: Sending rsp. status 0
hcid[26107]: Bytes Sent : 14


Don't let this output fool you into thinking that the broken binary cannot
enumerate services at all. I've tested querying the system from a Fedora 8
machine, and that works just fine.

Comment 2 David Woodhouse 2008-04-27 07:05:25 UTC
The original reporter says that he suspects a GCC bug since this doesn't occur
with a local rebuild of the same package -- and it doesn't occur with the
scratch rebuild at http://koji.fedoraproject.org/koji/taskinfo?taskID=584054

Pierre, what platform is this on? 

Can you compare the assembly of the service_search_req() functions in each
(which is static, so might be inlined in service_request(), which itself may be
inlined in handle_request()).

Can you also install the -debuginfo package and step through it, particularly
making sure that it is working on the same response buffer as the working
version (and that it didn't screw up the _query_ rather than the response).

I'm reluctant to accept that it's a GCC bug and just ship the rebuilt package
unless we know we fixed such a bug -- and at this stage of the release, unless
we take a serious look at what _other_ packages would need to be rebuilt.

Comment 3 Pierre Ossman 2008-04-27 08:28:23 UTC
I'll try to have a look and figure out the difference. Probably not today though.

The assembly is available to everyone to browse through and compare.

For reference:

Bad:
http://koji.fedoraproject.org/packages/bluez-utils/3.30/2.fc9/i386/bluez-utils-3.30-2.fc9.i386.rpm

Good:
http://koji.fedoraproject.org/koji/getfile?taskID=584057&name=bluez-utils-3.30-2.fc9.i386.rpm

Comment 4 David Woodhouse 2008-04-27 08:34:38 UTC
Please could you show output of 'hcidump -XV' for both runs, so we have sample
data to poke it with?

Comment 5 Pierre Ossman 2008-04-27 09:13:03 UTC
Created attachment 303903 [details]
hcidump -XV from good run

Comment 6 Pierre Ossman 2008-04-27 09:13:19 UTC
Created attachment 303904 [details]
hcidump -XV from bad run

Comment 7 Pierre Ossman 2008-04-27 09:14:33 UTC
There was unfortunately some reordering of requests between the runs, but the
meat of the diff is this:

-< ACL data: handle 11 flags 0x02 dlen 14
-    L2CAP(d): cid 0x0040 len 10 [psm 1]
-        SDP SS Rsp: tid 0x1 len 0x5
-          count 0
+< ACL data: handle 11 flags 0x02 dlen 18
+    L2CAP(d): cid 0x0040 len 14 [psm 1]
+        SDP SS Rsp: tid 0x1 len 0x9
+          count 1
+          handle 0x10004
           cont 00

which is the reply to:

> ACL data: handle 11 flags 0x02 dlen 17
    L2CAP(d): cid 0x0040 len 13 [psm 1]
        SDP SS Req: tid 0x1 len 0x8
          pat uuid-16 0x1105 (OBEXObjPush)
          max 65535
          cont 00


Comment 8 Pierre Ossman 2008-04-27 11:16:17 UTC
I tried to do some debugging, but I'm utterly confused by the behaviour. I have
the following snippet:

    0xb7f5e832 <handle_request+3746>:       call   0xb7f5fd00 <sdp_get_record_list>
    0xb7f5e837 <handle_request+3751>:       test   %eax,%eax
    0xb7f5e839 <handle_request+3753>:       mov    %eax,-0xf4(%ebp)
    0xb7f5e83f <handle_request+3759>:       je     0xb7f5ea8f <handle_request+4351>

%eax is set to a pointer (i.e. non-zero). ZF is therefore not set by the test.
But the jump is still executed (?!). Also, it jumps to 0xb7f5e90c, not 0xb7f5ea8f.

Ideas?

Comment 9 Bug Zapper 2008-05-14 10:11:12 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Bastien Nocera 2008-06-02 08:41:36 UTC
*** Bug 446580 has been marked as a duplicate of this bug. ***

Comment 11 Patrick Steiner 2008-06-11 20:24:38 UTC
could someone with koji access  please build bluez 0.32 for fedora 9

so i can test if the symbian bug is away

obex-data-server should also work with symbian phones after that.

Comment 12 Bastien Nocera 2008-06-12 09:28:14 UTC
(In reply to comment #11)
> could someone with koji access  please build bluez 0.32 for fedora 9
> 
> so i can test if the symbian bug is away
> 
> obex-data-server should also work with symbian phones after that.

If you have a Fedora account, you can do scratch builds yourself in F-9.
Otherwise it'll have to wait until David or I get to it.

Comment 13 Patrick Steiner 2008-06-12 11:06:52 UTC
i have created a fedora account. now i have to figure out how i can access koji :-)

i have installed bluez 0.32 from rawhide (fedora 10) via koji, now sending files
from my symbian files works without problems.

tested with sony ericsson m600i and nokia 6120 classic

Comment 14 Bastien Nocera 2008-06-12 13:55:14 UTC
Could you please test with _just_ bluez-utils upgraded (ie. still using
bluez-utils-3.30 for FC9), using this package:
http://koji.fedoraproject.org/koji/taskinfo?taskID=659132

I'll do an update with just that if it's enough.

Comment 15 Patrick Steiner 2008-06-12 20:35:33 UTC
i have tried it with bluez-libs only, this doesnt help. installing bluez-utils
from f10 helps...

Comment 16 Bastien Nocera 2008-06-14 12:23:10 UTC
Rebuilt version at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=661713

Comment 17 Patrick Steiner 2008-06-14 17:24:42 UTC
works fine with this version thanks!

Comment 18 Fedora Update System 2008-06-15 11:26:41 UTC
bluez-utils-3.32-1.fc9 has been submitted as an update for Fedora 9

Comment 19 Fedora Update System 2008-06-16 23:32:44 UTC
bluez-utils-3.32-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update bluez-utils'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5383

Comment 20 Bastien Nocera 2008-06-23 22:07:13 UTC
As mentioned in the update comments:

Juhaz - 2008-06-23 20:30:34 (karma: +1)
Unlike what was speculated in the bug report, I believe this was actually a bug
in bluez-utils, and not a failed compile in any way, was fixed by 
http://bluez.cvs.sourceforge.net/bluez/utils/sdpd/request.c?r1=1.22&r2=1.23

Comment 21 Fedora Update System 2008-06-27 19:35:52 UTC
bluez-utils-3.32-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.