Summary: | Unable to start oocalc under memcheck on openSUSE 10.3 (64-bit) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Bart Van Assche <bart.vanassche+kde> |
Component: | memcheck | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Bart Van Assche
2008-01-22 20:16:36 UTC
> valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No
> such file or directory
Are you sure your build successfully built a working 32- and 64-bit version?
Failure to do so is a common cause of the above message.
Running 32-bit executables under Valgrind works fine. Note: by this time I have installed openSUSE 10.3 on a new PC and I have rebuilt Valgrind from SVN source code. oocalc still doesn't start under Valgrind. I believe this is caused by Valgrind causing sys_readlink to fail when it would normally succeed, because the bottom page of the stack isn't mapped at the point the syscall happens. So the kernel fails the syscall. Nasty. In native execution the kernel would automagically extend the stack down by one page and there would be no problem. Here's a small test case. #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <assert.h> #include <sys/syscall.h> #include <unistd.h> #define VG_STRINGIFZ(__str) #__str #define VG_STRINGIFY(__str) VG_STRINGIFZ(__str) #define __NR_READLINK VG_STRINGIFY(__NR_readlink) extern int my_readlink ( const char* path ); asm( ".text\n" ".globl my_readlink\n" "my_readlink:\n" "\tsubq $0x1008,%rsp\n" "\tmovq %rdi,%rdi\n" // path is in rdi "\tmovq %rsp,%rsi\n" // &buf[0] -> rsi "\tmovl $0x1000,%edx\n" // sizeof(buf) in rdx "\tmovl $"__NR_READLINK",%eax\n" // syscall number "\tsyscall\n" "\taddq $0x1008,%rsp\n" "\tret\n" ".previous\n" ); int recurse ( const char* path, int count ) { if (count <= 0) { return my_readlink(path); } else { int r = recurse(path, count-1); // assert(r == /* value indicating readlink succeeded */); return r; } } int main ( void ) { int i, r; for (i = 0; i < 10000; i++) { printf("depth %d: ", i ); r = recurse( "/proc/self", i ); printf("r = %d\n", r); assert(r >= 4); } } The test program runs fine natively on my system, but fails when run under Valgrind: $ ./readlink-test ... depth 9996: r = 5 depth 9997: r = 5 depth 9998: r = 5 depth 9999: r = 5 $ ./vg-in-place ./readlink-test ... depth 64: r = 5 depth 65: r = 5 depth 66: r = 5 depth 67: r = -14 readlink-test: readlink-test.c:48: main: Assertion `r >= 4' failed. ... I think the following (nasty, uncommented, and not production-ready hack fixes it): Index: coregrind/m_syswrap/syswrap-main.c =================================================================== --- coregrind/m_syswrap/syswrap-main.c (revision 8708) +++ coregrind/m_syswrap/syswrap-main.c (working copy) @@ -30,6 +30,7 @@ #include "libvex_guest_offsets.h" #include "pub_core_basics.h" +#include "pub_core_aspacemgr.h" #include "pub_core_vki.h" #include "pub_core_vkiscnums.h" #include "pub_core_threadstate.h" @@ -45,6 +46,7 @@ #include "pub_core_options.h" #include "pub_core_signals.h" // For VG_SIGVGKILL, VG_(poll_signals) #include "pub_core_syscall.h" +#include "pub_core_machine.h" #include "pub_core_syswrap.h" #include "priv_types_n_macros.h" @@ -789,6 +791,21 @@ tst = VG_(get_ThreadState)(tid); +# if defined(VGO_linux) + /* XXXX */ + if (tid == 1) { + Addr stackMin = VG_(get_SP)(tid) - VG_STACK_REDZONE_SZB; + NSegment const* seg = VG_(am_find_nsegment)(stackMin); + if (seg && seg->kind == SkAnonC) { + /* stackMin is already mapped. Nothing to do. */ + } else { + Bool b = VG_(extend_stack)( VG_(get_SP)(tid) - VG_STACK_REDZONE_SZB, + tst->client_stack_szB ); + } + } + /* /XXXX */ +# endif + /* First off, get the syscall args and number. This is a platform-dependent action. */ Sorry, but I still get the same error message after having applied the above patch: svn diff coregrind/m_syswrap/syswrap-main.c Index: coregrind/m_syswrap/syswrap-main.c =================================================================== --- coregrind/m_syswrap/syswrap-main.c (revision 8713) +++ coregrind/m_syswrap/syswrap-main.c (working copy) @@ -881,6 +881,21 @@ # endif /* END ensure root thread's stack is suitably mapped */ +# if defined(VGO_linux) + /* XXXX */ + if (tid == 1) { + Addr stackMin = VG_(get_SP)(tid) - VG_STACK_REDZONE_SZB; + NSegment const* seg = VG_(am_find_nsegment)(stackMin); + if (seg && seg->kind == SkAnonC) { + /* stackMin is already mapped. Nothing to do. */ + } else { + Bool b = VG_(extend_stack)( VG_(get_SP)(tid) - VG_STACK_REDZONE_SZB, + tst->client_stack_szB ); + } + } + /* /XXXX */ +# endif + /* First off, get the syscall args and number. This is a platform-dependent action. */ Hmm, in that case I guess the sys_readlink problem is not the cause of the bug you originally reported. At least the test case I made now runs OK for you, yes? The sys_readlink testcase runs indeed fine on my system with the patch applied. What happens if you try running the OOo binary directly? like this: valgrind /usr/lib64/ooo-2.0/program/soffice.bin This last command works fine: $ ./vg-in-place /usr/lib64/ooo-2.0/program/soffice.bin ==28578== Memcheck, a memory error detector. ==28578== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==28578== Using LibVEX rev 1811, a library for dynamic binary translation. ==28578== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==28578== Using valgrind-3.4.0.SVN, a dynamic binary instrumentation framework. ==28578== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==28578== For more details, rerun with: -v ==28578== ==28578== Thread 4: ==28578== Syscall param write(buf) points to uninitialised byte(s) ==28578== at 0x8A3788B: (within /lib64/libpthread-2.8.so) ==28578== by 0x82D5FDE: (within /usr/lib64/libICE.so.6.3.0) ==28578== by 0x82DA28F: _IceWrite (in /usr/lib64/libICE.so.6.3.0) ==28578== by 0x82DA373: IceFlush (in /usr/lib64/libICE.so.6.3.0) ==28578== by 0xEA4673C: (within /usr/lib/qt3/lib64/libqt-mt.so.3.3.8) ==28578== by 0xEA468D1: (within /usr/lib/qt3/lib64/libqt-mt.so.3.3.8) ==28578== by 0xEA4DF6B: (within /usr/lib/qt3/lib64/libqt-mt.so.3.3.8) ==28578== by 0xEA4F219: (within /usr/lib/qt3/lib64/libqt-mt.so.3.3.8) ==28578== by 0x80C9C16: _SmcProcessMessage (in /usr/lib64/libSM.so.6.0.0) ==28578== by 0x82DE95D: IceProcessMessages (in /usr/lib64/libICE.so.6.3.0) ==28578== by 0xF2A1024: (within /usr/lib64/ooo-2.0/program/libvclplug_gen680lx.so) ==28578== by 0x716649F: (within /usr/lib64/ooo-2.0/program/libuno_sal.so.3) ==28578== Address 0xd9f8fd4 is 12 bytes inside a block of size 1,024 alloc'd ==28578== at 0x4C23724: calloc (vg_replace_malloc.c:397) ==28578== by 0x82D24E1: IceOpenConnection (in /usr/lib64/libICE.so.6.3.0) ==28578== by 0x80C5CB0: SmcOpenConnection (in /usr/lib64/libSM.so.6.0.0) ==28578== by 0xEA4BF42: QSessionManager::QSessionManager(QApplication*, QString&, QString&) (in /usr/lib/qt3/lib64/libqt-mt.so.3.3.8) ==28578== by 0xEABB35A: QApplication::initialize(int, char**) (in /usr/lib/qt3/lib64/libqt-mt.so.3.3.8) ==28578== by 0xEABC6DB: QApplication::construct(int&, char**, QApplication::Type) (in /usr/lib/qt3/lib64/libqt-mt.so.3.3.8) ==28578== by 0xE4D79D3: KApplication::KApplication(bool, bool) (in /opt/kde3/lib64/libkdecore.so.4.2.0) ==28578== by 0xDB10A7D: (within /usr/lib64/ooo-2.0/program/libvclplug_kde680lx.so) ==28578== by 0xDB10454: create_SalInstance (in /usr/lib64/ooo-2.0/program/libvclplug_kde680lx.so) ==28578== by 0x515398E: (within /usr/lib64/ooo-2.0/program/libvcl680lx.so) ==28578== by 0x5154AE9: (within /usr/lib64/ooo-2.0/program/libvcl680lx.so) ==28578== by 0x4F0A2BF: InitVCL(com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const&) (in /usr/lib64/ooo-2.0/program/libvcl680lx.so) ==28578== ==28578== ERROR SUMMARY: 8 errors from 1 contexts (suppressed: 31 from 3) ==28578== malloc/free: in use at exit: 2,711,793 bytes in 31,139 blocks. ==28578== malloc/free: 553,384 allocs, 522,245 frees, 38,898,440 bytes allocated. ==28578== For counts of detected errors, rerun with: -v ==28578== Use --track-origins=yes to see where uninitialised values come from ==28578== searching for pointers to 31,139 not-freed blocks. ==28578== checked 12,229,768 bytes. ==28578== ==28578== LEAK SUMMARY: ==28578== definitely lost: 762,654 bytes in 6,703 blocks. ==28578== possibly lost: 1,056 bytes in 7 blocks. ==28578== still reachable: 1,948,083 bytes in 24,429 blocks. ==28578== suppressed: 0 bytes in 0 blocks. ==28578== Rerun with --leak-check=full to see details of leaked memory. Closing. If any more info about the original problem appears (which, AFAICS, is unrelated to the sys_readlink problem that this report morphed into) then we can reopen it. Note: commit r8729 solved this issue. |