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]
