Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162836 - hcid dies during connect() of rfcomm socket.
Summary: hcid dies during connect() of rfcomm socket.
Keywords:
Status: CLOSED DUPLICATE of bug 160676
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez-utils
Version: 4
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: David Woodhouse
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-10 05:50 UTC by Dave Mielke
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-27 13:54:43 UTC


Attachments (Terms of Use)

Description Dave Mielke 2005-07-10 05:50:37 UTC
Description of problem:

We [http://mielke.cc/brltty/] have code for connecting to a Bluetooth device
via an rfcomm socket. It works fine on FC3, but fails on FC4. The hcid daemon
dies as soon as the connect() is attempted.

Version-Release number of selected component (if applicable):

kernel-2.6.12-1.1390_FC4
dbus-0.33-3
bluez-libs-2.15-1
bluez-utils-2.15-7

How reproducible:

Every time.

Steps to Reproduce:

Let me know if you'd like a complete test program. The relevant code segments
are as follows:

   int connection;
   connection = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);

   struct sockaddr_rc local;
   local.rc_family = AF_BLUETOOTH;
   local.rc_channel = 0;
   bacpy(&local.rc_bdaddr, BDADDR_ANY);
   bind(connection, (struct sockaddr *)&local, sizeof(local));
   
   struct sockaddr_rc remote;
   remote.rc_family = AF_BLUETOOTH;
   remote.rc_channel = suppliedChannelNumber;
   bacpy(&remote.rc_bdaddr, &suppliedBluetoothDeviceAddreess);
   connect(connection, (struct sockaddr *)&remote, sizeof(remote));

Actual results:

hcid starts up fine: 

==============================================================================
hcid -n
hcid[12537]: Bluetooth HCI daemon
hcid[12537]: Starting security manager 0
==============================================================================

As soon as the connect() is done, however, hcid dies like this:

==============================================================================
hcid[12537]: link_key_request (sba=00:0A:3A:53:D7:FC, dba=00:A0:96:0A:C9:10)
hcid[12537]: pin_code_request (sba=00:0A:3A:53:D7:FC, dba=00:A0:96:0A:C9:10)
12537: arguments to dbus_type_is_basic() were incorrect, assertion 
"_dbus_type_is_valid (typecode) || typecode == DBUS_TYPE_INVALID" failed in 
file dbus-signature.c line 259.
This is normally a bug in some application using the D-BUS library.
type unknown isn't supported yet in dbus_message_append_args_valist
*** buffer overflow detected ***: hcid: processing events terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x781565]
hcid: processing events[0x880e8b]
/usr/lib/libdbus-1.so.1[0x296155]
/usr/lib/libdbus-1.so.1[0x27649e]
/usr/lib/libdbus-1.so.1(dbus_connection_dispatch+0x20a)[0x27af44]
hcid: processing events[0x8809c0]
hcid: processing events[0x8808b0]
hcid: processing events(main+0x4c5)[0x87cfef]
/lib/libc.so.6(__libc_start_main+0xc6)[0x6b7de6]
hcid: processing events[0x87c071]
======= Memory map: ========
0026a000-002d3000 r-xp 00000000 fd:00 3051963    /usr/lib/libdbus-1.so.1.0.0
002d3000-002d8000 rwxp 00069000 fd:00 3051963    /usr/lib/libdbus-1.so.1.0.0
00301000-0031b000 r-xp 00000000 fd:00 8676400    /lib/ld-2.3.5.so
0031b000-0031c000 r-xp 00019000 fd:00 8676400    /lib/ld-2.3.5.so
0031c000-0031d000 rwxp 0001a000 fd:00 8676400    /lib/ld-2.3.5.so
003cd000-003ce000 r-xp 003cd000 00:00 0
006a3000-007c7000 r-xp 00000000 fd:00 8676401    /lib/libc-2.3.5.so
007c7000-007c9000 r-xp 00124000 fd:00 8676401    /lib/libc-2.3.5.so
007c9000-007cb000 rwxp 00126000 fd:00 8676401    /lib/libc-2.3.5.so
007cb000-007cd000 rwxp 007cb000 00:00 0
0085c000-00865000 r-xp 00000000 fd:00 8676405    
/lib/libgcc_s-4.0.0-20050520.so.1
00865000-00866000 rwxp 00009000 fd:00 8676405    
/lib/libgcc_s-4.0.0-20050520.so.1
0087a000-00884000 r-xp 00000000 fd:00 3051713    /usr/sbin/hcid
00884000-00885000 rwxp 00009000 fd:00 3051713    /usr/sbin/hcid
00a09000-00a15000 r-xp 00000000 fd:00 3048829    
/usr/lib/libbluetooth.so.1.0.15
00a15000-00a16000 rwxp 0000c000 fd:00 3048829    
/usr/lib/libbluetooth.so.1.0.15
00eb6000-00ec8000 r-xp 00000000 fd:00 8676413    /lib/libnsl-2.3.5.so
00ec8000-00ec9000 r-xp 00011000 fd:00 8676413    /lib/libnsl-2.3.5.so
00ec9000-00eca000 rwxp 00012000 fd:00 8676413    /lib/libnsl-2.3.5.so
00eca000-00ecc000 rwxp 00eca000 00:00 0
08462000-08483000 rw-p 08462000 00:00 0          [heap]
b7f78000-b7f7a000 rw-p b7f78000 00:00 0
b7f9e000-b7f9f000 rw-p b7f9e000 00:00 0
bfb89000-bfb9f000 rw-p bfb89000 00:00 0          [stack]
Aborted
==============================================================================

Expected results:

hcid shouldn't die, and the connect() should return a meaningful result which
is wholly dependent on the device's availability.

Additional info:

I posted this problem to the Bluetooth development list, and, among other
things, was told (by Marcel Holtmann <marcel@holtmann.org>), "last time I
looked at the D-Bus 0.33 changes in the Fedora packages they seemed to be
wrong."

This failure is preventing users of braille displays which use Bluetooth-based
connections from using Fedora Core 4.

Comment 1 John (J5) Palmieri 2005-07-11 20:21:52 UTC
Reassigning to bluez-utils

Comment 2 John (J5) Palmieri 2005-07-11 20:28:05 UTC
dwmw2, 

there are a couple of issues with the D-Bus patch.  

First, you are leaking in reply_handler_function.  You need to unref your
pending call.

Second, in hcid_dbus_request_pin, you pass an iterator to
dbus_message_append_args.  This causes the crash described in this bug report. 
dbus_message_append_args only take a message and a list of type, value pairs. 
You only need to use an iterator when dealing with dbus_message_iter_* methods.

If you have any question I'll stay cc'ed to this bug report.

Comment 3 Bastien Nocera 2005-07-27 13:54:43 UTC

*** This bug has been marked as a duplicate of 160676 ***


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