From: Dan K. <da...@ke...> - 2003-05-12 05:52:48
|
Hi all! Now that I have my nice shiny new valgrind1.9.6 running on Red Hat 7.2 with OpenOffice1.1beta1, I'd like to figure out whether the errors that pop up are real or not. Here's the first one that shows up: ==6424== Invalid memory access of size 1 ==6424== at 0x4119C4C5: _STL::basic_string<wchar_t, _STL::char_traits<wchar_t>, _STL::allocator<wchar_t> >::basic_string(wchar_t const*, _STL::allocator<wchar_t> const&) (in /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so) ==6424== by 0x41162A2F: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so) ==6424== by 0x41162B11: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so) ==6424== by 0x41171E46: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so) ==6424== Address 0xBFFFF4C9 is just below %esp. Possibly a bug in GCC/G++ ==6424== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes ==6424== ==6424== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y ==6424== starting GDB with cmd: /usr/bin/gdb -nw /proc/6424/exe 6424 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) ... (gdb) bt #0 vg_do_syscall3 (syscallno=65535, arg1=1, arg2=3221222680, arg3=1091971632) at vg_mylibc.c:92 #1 0x0000191c in ?? () at eval.c:41 #2 0x4119c4c5 in _STL::basic_string<wchar_t, _STL::char_traits<wchar_t>, _STL::allocator<wchar_t> >::basic_string(wchar_t const*, _STL::allocator<wchar_t> const&) () from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so #3 0x41162a30 in _STL::numpunct<wchar_t>::do_falsename() const () from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so #4 0x41162b12 in _STL::numpunct<wchar_t>::do_falsename() const () from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so #5 0x41171e47 in _STL::tanh(_STL::complex<long double> const&) () from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so #6 0x411556b6 in _init () from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so #7 0x4000d9e7 in _dl_init () at eval.c:41 That one looks real to me (although I can't for the life of me figure out what punctuation has to do with hyperbolic tangents). I think OpenOffice contains its own copy of STL, which appears to have an off-by one bug. Or is it really just a gcc bug, and I should do as the message suggests? Anyone know of valgrind issues in stlport.org's stl implementation? Second problem: at startup time, I get this: ==18415== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) ==18415== at 0x40170F87: vgAllRoadsLeadToRome_writev (vg_intercept.c:108) ==18415== by 0x40170FC4: __writev (vg_intercept.c:733) ==18415== by 0x40C2588F: (within /usr/X11R6/lib/libX11.so.6.2) ==18415== by 0x40C264CE: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2) ==18415== Address 0x43F51058 is 32 bytes inside a block of size 2048 alloc'd ==18415== at 0x4015E780: calloc (vg_clientfuncs.c:245) ==18415== by 0x40BF852B: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2) ==18415== by 0x4048C395: SalXLib::Init(int*, char**) (in /opt/OpenOffice.org644/program/libvcl644li.so) ==18415== by 0x4048BFD8: SalData::Init(int*, char**) (in /opt/OpenOffice.org644/program/libvcl644li.so) This might just be normal X library behavior; see http://keithp.com/~keithp/talks/usenix2003/html/net.html, which says "Gian Filippo Pinzari [Pin03] has recently pointed out that Xlib does not zero out unused bytes in the protocol stream but transmits the left over bytes in the protocol buffer where the requests are formed. " Doesn't sound valgrind-friendly offhand. Ripe for suppression? Guidence from the masters would be welcome. I'll probably be bugging this list quite a bit in the next few days as I come up to speed on valgrind/ooo. Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |