Hi, This bug seems to take an annoyingly long time to fix, so I tried to run "hald --daemon=no --verbose=yes" under valgrind and I got:
==9630== Invalid read of size 1 ==9630== at 0x4A07AC4: strcmp (mc_replace_strmem.c:341) ==9630== by 0x4C2E68D: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C2E955: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C2E350: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C2E578: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C35D5D: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C35E22: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C3608C: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C1498D: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C13B7A: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C13D9B: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C13325: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C2B92E: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C2C80E: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== by 0x4C2D0AA: (within /usr/lib/libdbus-1.so.3.4.0) ==9630== Address 0x4F0D228 is 0 bytes inside a block of size 5 free'd ==9630== at 0x4A0682B: free (vg_replace_malloc.c:233) I don't know if this is _the_ reason why hald quits but at least it is clearly a use-after-free bug and it should be easy to catch if someone recompiles hal & libdbus with full debug info and runs hald under valgrind again - I don't have the time right now. iF hal 0.5.10-3 Hardware Abstraction Layer ii libdbus-1-3 1.1.2-1 simple interprocess messaging system Gabor -- --------------------------------------------------------- MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences --------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]