Created attachment 18983 [details] [review] little patch libSM callocs some memory, at some later stage some malloced memory is splatted on the calloc memory, which makes valgrind worried that some expected-to-be-zero stuff is now random. Its turns out to be a bogus error as the used bytes are correctly set, and only the unused holes are left with uninitialized foo. But its an ugly warning, and the only one left that appears when valgrinding openoffice.org. Maybe there's a possible argument in favour of the patch that memsetting it to 0 might allow some tiny compression advantage over LBX or something ==6986== Syscall param write(buf) points to uninitialised byte(s) ==6986== at 0x353960DECB: write (in /lib64/libpthread-2.8.90.so) ==6986== by 0x354560996E: (within /usr/lib64/libICE.so.6.3.0) ==6986== by 0x354560DBCF: _IceWrite (in /usr/lib64/libICE.so.6.3.0) ==6986== by 0x354560DCB3: IceFlush (in /usr/lib64/libICE.so.6.3.0) ==6986== by 0xFE3398B: SessionManagerClient::saveDone() (sm.cxx:393) ==6986== by 0xFE33BC4: SessionManagerClient::SaveYourselfProc(_SmcConn*, void*, int, int, int, int) (sm.cxx:332) ==6986== by 0x3545206496: _SmcProcessMessage (in /usr/lib64/libSM.so.6.0.0) ==6986== by 0x3545612213: IceProcessMessages (in /usr/lib64/libICE.so.6.3.0) ==6986== by 0xFE334CC: ICEConnectionWorker (sm.cxx:642) ==6986== by 0x4C3A1BF: (within /usr/lib64/openoffice.org/ure/lib/libuno_sal.so.3) ==6986== by 0x35396073D9: (within /lib64/libpthread-2.8.90.so) ==6986== by 0x3538AE9B8C: clone (in /lib64/libc-2.8.90.so) ==6986== Address 0xa2d7354 is 12 bytes inside a block of size 1,024 alloc'd ==6986== at 0x4A05174: calloc (vg_replace_malloc.c:397) ==6986== by 0x3545605E59: IceOpenConnection (in /usr/lib64/libICE.so.6.3.0) ==6986== by 0x35452027A0: SmcOpenConnection (in /usr/lib64/libSM.so.6.0.0) ==6986== by 0xFE3423A: SessionManagerClient::open() (sm.cxx:437) ==6986== by 0xFB9455C: GtkSalFrame::Show(unsigned char, unsigned char) (gtkframe.cxx:1264) ==6986== by 0x7B89C17: Window::Show(unsigned char, unsigned short) (window.cxx:6515) ==6986== by 0x7B8993F: Window::Show(unsigned char, unsigned short) (window.cxx:6502) ==6986== by 0x15591288: (within /usr/lib64/openoffice.org/basis3.0/program/libspllx.so) ==6986== by 0x50268B0: (within /usr/lib64/openoffice.org/basis3.0/program/libsofficeapp.so) ==6986== by 0x502A01E: (within /usr/lib64/openoffice.org/basis3.0/program/libsofficeapp.so) ==6986== by 0x79B6673: ImplSVMain() (svmain.cxx:195) ==6986== by 0x79B6714: SVMain() (svmain.cxx:236)
Fixed, thanks!
Created attachment 31514 [details] [review] alternative patch? I was investigating this same problem (in terms of valgrind warnings while starting Firefox), and came up with this (somewhat different) patch that you may or may not consider better; instead of calling memset over the whole buffer, it calls memset on the holes as it creates them. This approach has the advantage of fixing not just the one caller fixed above, but all callers of STORE_ARRAY8 and STORE_LISTOF_PROPERTY.
Created attachment 31515 [details] the valgrind warning in Firefox Here's the valgrind warning in Firefox; Ubuntu 9.10 still hasn't picked up the previous patch in this bug, so I'm still seeing it.
I stuck the above patch in bug 25785.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.