Which version of bluez-pin and dbus are you using on this machine?
Could you please follow the instructions at
http://fedora.linux.duke.edu/wiki/StackTraces to gather a backtrace on hcid?

Same here. Including a backtrace.

# rpm -q bluez-utils bluez-libs bluez-pin dbus
bluez-utils-2.15-7
bluez-libs-2.15-1
bluez-pin-0.24-2
dbus-0.33-3

HCI daemon ver 2.15

gdb hcid
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run -n
Starting program: /usr/sbin/hcid -n
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x29b000
hcid[18412]: Bluetooth HCI daemon
Detaching after fork from child process 18416.
Detaching after fork from child process 18417.
hcid[18412]: Starting security manager 0
hcid[18412]: pin_code_request (sba=00:10:DC:AF:F7:70, dba=00:0F:DE:1C:B4:DD)
18412: 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)[0x200565]
hcid: processing events[0xab7e8b]
/usr/lib/libdbus-1.so.1[0xe57155]
/usr/lib/libdbus-1.so.1[0xe3749e]
/usr/lib/libdbus-1.so.1(dbus_connection_dispatch+0x20a)[0xe3bf44]
hcid: processing events[0xab79c0]
hcid: processing events[0xab78b0]
hcid: processing events(main+0x4c5)[0xab3fef]
/lib/libc.so.6(__libc_start_main+0xc6)[0x136de6]
hcid: processing events[0xab3071]
======= Memory map: ========
00122000-00246000 r-xp 00000000 03:03 2715551    /lib/libc-2.3.5.so
00246000-00248000 r-xp 00124000 03:03 2715551    /lib/libc-2.3.5.so
00248000-0024a000 rwxp 00126000 03:03 2715551    /lib/libc-2.3.5.so
0024a000-0024c000 rwxp 0024a000 00:00 0
0029b000-0029c000 r-xp 0029b000 00:00 0
00ab1000-00abb000 r-xp 00000000 03:03 1642413    /usr/sbin/hcid
00abb000-00abc000 rwxp 00009000 03:03 1642413    /usr/sbin/hcid
00bc5000-00bce000 r-xp 00000000 03:03 2724376    /lib/libgcc_s-4.0.0-20050520.so.1
00bce000-00bcf000 rwxp 00009000 03:03 2724376    /lib/libgcc_s-4.0.0-20050520.so.1
00c0a000-00c24000 r-xp 00000000 03:03 2715550    /lib/ld-2.3.5.so
00c24000-00c25000 r-xp 00019000 03:03 2715550    /lib/ld-2.3.5.so
00c25000-00c26000 rwxp 0001a000 03:03 2715550    /lib/ld-2.3.5.so
00e2b000-00e94000 r-xp 00000000 03:03 1639043    /usr/lib/libdbus-1.so.1.0.0
00e94000-00e99000 rwxp 00069000 03:03 1639043    /usr/lib/libdbus-1.so.1.0.0
00f23000-00f2f000 r-xp 00000000 03:03 1653147   
/usr/lib/libbluetooth.so.1.0.1500f2f000-00f30000 rwxp 0000c000 03:03 1653147   
/usr/lib/libbluetooth.so.1.0.1500f72000-00f84000 r-xp 00000000 03:03 2715558   
/lib/libnsl-2.3.5.so
00f84000-00f85000 r-xp 00011000 03:03 2715558    /lib/libnsl-2.3.5.so
00f85000-00f86000 rwxp 00012000 03:03 2715558    /lib/libnsl-2.3.5.so
00f86000-00f88000 rwxp 00f86000 00:00 0
08b5e000-08b7f000 rw-p 08b5e000 00:00 0          [heap]
b7f8a000-b7f8c000 rw-p b7f8a000 00:00 0
bfc8d000-bfca3000 rw-p bfc8d000 00:00 0          [stack]

Program received signal SIGABRT, Aborted.
0x0029b402 in __kernel_vsyscall ()
(gdb) bt
#0  0x0029b402 in __kernel_vsyscall ()
#1  0x0014a1f8 in raise () from /lib/libc.so.6
#2  0x0014b948 in abort () from /lib/libc.so.6
#3  0x0017f52a in __libc_message () from /lib/libc.so.6
#4  0x00200565 in __chk_fail () from /lib/libc.so.6
#5  0x00ab7e8b in reply_handler_function (call=0x0, user_data=0x8b60950)
    at dbus.c:91
#6  0x00e57155 in dbus_pending_call_get_data () from /usr/lib/libdbus-1.so.1
#7  0x00e3749e in dbus_connection_has_messages_to_send ()
   from /usr/lib/libdbus-1.so.1
#8  0x00e3bf44 in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.1
#9  0x00ab79c0 in watch_func (chan=0x8b60288, cond=G_IO_IN, data=0x0)
    at dbus.c:169
#10 0x00ab78b0 in g_main_loop_run (loop=0x8b5e038) at glib-ectomy.c:163
#11 0x00ab3fef in main (argc=2, argv=0xbfca0984, env=0x0) at main.c:598
(gdb) quit
The program is running.  Exit anyway? (y or n) y

*** Bug 162836 has been marked as a duplicate of this bug. ***

From bug 162836, comment 2:
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.

Please try bluez-libs-2.19-1 and bluez-utils-2.19-1 from rawhide. 

I have rebuild bluez-libs-2.19-1.src.rpm and bluez-utils-2.19-1.scr.rpm, for I
did not want to upgrade all my glibc packages. Hcid is still crashing. Including
a new trace.

hcid -n
hcid[3766]: Bluetooth HCI daemon
hcid[3766]: Starting security manager 0
hcid[3766]: pin_code_request (sba=00:10:DC:AF:F7:70, dba=00:0F:DE:1C:B4:DD)
Speicherzugriffsfehler

Created attachment 117585 [details]
hcid 2.19-1 trace

The relevant call here is:

dbus_message_append_args(message, DBUS_TYPE_BOOLEAN, &ci->out,
                        DBUS_TYPE_ARRAY, DBUS_TYPE_BYTE,
                        &ci->bdaddr, sizeof(bdaddr_t), DBUS_TYPE_INVALID);

I think the problem is &ci->bdaddr.  The dbus docs state this as the format for
appending fixed arrays:

const dbus_int32_t array[] = { 1, 2, 3 };
const dbus_int32_t *v_ARRAY = array;
DBUS_TYPE_ARRAY, DBUS_TYPE_INT32, &v_ARRAY, 3

So above should look more like:
const bdaddr_t *v_bdaddr = ci->bdaddr;
DBUS_TYPE_ARRAY, DBUS_TYPE_BYTE, &v_bdaddr, sizeof(bdaddr_t)

Does the patch in bluez-utils-2.19-2 look OK?

Looks good to me

Thanks. In comment #2, Bastien says "you are leaking in reply_handler_function.
 You need to unref your pending call."

My dbus-fu is weak. If that's still a problem in the 2.19 code, please could you
elaborate so I can fix it? Preferably in 'diff -u' form :)

Don't shoot the messenger, John said that in the other bug. I have no idea what
he's on about ;)

Created attachment 118084 [details]
Unref your pending call

Here you go

My hcid is still crashing so i think nothing had happened so far.
Can we get this bug fixed somehow?

Thomas: still crashing with rawhide bluez-utils?

bluez-utils and the other bluez rpm's in rawhide have got different
dependencies, which are not available for FC4.

Failed dependencies:
        bind-libs = 28:9.3.2rc1-1.1 is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libc.so.6(GLIBC_2.4)(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libcrypto.so.6()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libdns.so.21()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libisc.so.11()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        liblwres.so.9()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        bind-utils = 24:9.3.1-14_FC4 is needed by (installed)
bind-9.3.1-14_FC4.x86_64

If there are bluez rpm's for FC4 in the testing repo, i will install them and
give a feedback, but i will not upgrade FC4 to rawhide.

still having problems with current rawhide
bluez-libs-2.22-1.1
bluez-pin-0.24-3.1
bluez-utils-2.22-2.1

bluez-pin --dbus gives error  9334: arguments to
dbus_message_iter_get_fixed_array() were  incorrect, assertion
"dbus_type_is_fixed (_dbus_type_reader_get_current_type (& real->u.reader))"
failed in file dbus-message.c line 1741.
This is normally a bug in some application using the D-BUS library.

hcid output to /var/log/messages
Jan 10 21:52:28 localhost hcid[9477]: pin_code_request (sba=00:10:C6:62:97:8B,
dba=00:11:9F:6C:4D:24)
Jan 10 21:52:28 localhost hcid[9477]: org.bluez.Error.WrongArgs: Byte array
expected, other type given

Still not fixed with latest stuff under FC5test3:

bluez-pin-0.24-3.2.1
bluez-utils-2.22-2.2.1
bluez-libs-2.25-1
dbus-0.60-7.2

3635: arguments to dbus_message_iter_get_fixed_array() were incorrect, assertion
"dbus_type_is_fixed (_dbus_type_reader_get_current_type (&real->u.reader))"
failed in file dbus-message.c line 1741.
This is normally a bug in some application using the D-BUS library.

Feb 25 01:07:01 baraddur hcid[3673]: pin_code_request (sba=00:0A:3A:58:BC:54,
dba=00:07:A4:10:30:C6)
Feb 25 01:07:01 baraddur hcid[3673]: org.bluez.Error.WrongArgs: Byte array
expected, other type given

rawhide now has bluez-utils-2.25. Please retest.

Still the same problem:

dbus-0.61-3
bluez-utils-2.25-3
bluez-pin-0.24-3.2.1
bluez-libs-2.25-1
selinux-policy-targeted-2.2.23-15

BTW: SELinux still prevents hcid to access DBUS (see also bug #183145):

Mar 10 19:20:45 baraddur hcid[11444]: Bluetooth HCI daemon
Mar 10 19:20:45 baraddur hcid[11444]: Can't get system message bus name:
Connection ":1.12" is not allowed to own the service "org.bluez" due to SELinux
policy
Mar 10 19:20:45 baraddur hcid[11444]: Unable to get on D-BUS

Testing under "setenforce 0":

Mar 10 19:25:34 baraddur hcid[11571]: pin_code_request (sba=00:0A:3A:58:BC:54,
dba=00:02:EE:93:9F:C8)
Mar 10 19:25:34 baraddur hcid[11571]: org.bluez.Error.WrongArgs: Byte array
expected, other type given

$ bluez-pin --dbus
11605: arguments to dbus_message_iter_get_fixed_array() were incorrect,
assertion "(subtype == DBUS_TYPE_INVALID) || dbus_type_is_fixed (subtype)"
failed in file dbus-message.c line 1743.
This is normally a bug in some application using the D-BUS library.

With the latest bluez-pin it finally works (as long as you use "setenforce 0")...

dbus-0.61-3
bluez-libs-2.25-1
bluez-pin-0.30-2
bluez-utils-2.25-4

In which case this should be changed to an SELinux issue.  We strive to have all
software work with SELinux.  Stefan, can you attach the relevant portions of
/var/log/audit/audit.log.  Thanks.

There is already bug #183145 open for this, so I think this one can be closed...

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