Bug 444228
Summary: | sdp broken with symbian phones (broken compile) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pierre Ossman <pierre-bugzilla> | ||||||
Component: | bluez-utils | Assignee: | David Woodhouse <dwmw2> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 9 | CC: | bnocera, jakub, patrick | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 3.32-1.fc9 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2008-06-27 19:35:55 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Pierre Ossman
2008-04-25 20:59:52 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. 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. 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 Please could you show output of 'hcidump -XV' for both runs, so we have sample data to poke it with? Created attachment 303903 [details]
hcidump -XV from good run
Created attachment 303904 [details]
hcidump -XV from bad run
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
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? 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 *** Bug 446580 has been marked as a duplicate of this bug. *** 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. (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. 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 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. i have tried it with bluez-libs only, this doesnt help. installing bluez-utils from f10 helps... Rebuilt version at: http://koji.fedoraproject.org/koji/taskinfo?taskID=661713 works fine with this version thanks! bluez-utils-3.32-1.fc9 has been submitted as an update for Fedora 9 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 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 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. |