Sounds like it might be a known bug which has been fixed, https://bugs.kde.org/show_bug.cgi?id=205541
Check out the trunk and try that. Instructions are at http://www.valgrind.org/downloads/repository.html Note that Memcheck doesn't like user-space threading implementations much, and so you still might have problems with it. J On Thursday 18 February 2010, Mathieu Lacage wrote: > hi, > > I have a recent build of 3.5.0 and the following output: > > SYSCALL[13019,1]( 9) sys_mmap ( 0x0, 1056768, 0, 34, -1, 0 ) --> > [pre-success] Success(0x0:0x404d000) > SYSCALL[13019,1]( 10) sys_mprotect ( 0x404e000, 1052672, 3 )[sync] --> > Success(0x0:0x0) > SYSCALL[13019,1]( 14) sys_rt_sigprocmask ( 0, 0x0, 0x64ee478, 8 ) --> > [pre-success] Success(0x0:0x0) > ==13019== Invalid write of size 8 > ==13019== at 0x339E041B2F: makecontext (makecontext.c:77) > ==13019== by 0x5B89D20: FiberContextNew (fiber-context-ucontext.c:212) > ==13019== by 0x5B34328: > ns3::ProcessManager::CreateThread(ns3::Process*, unsigned int) > (process-manager.cc:320) > ==13019== by 0x5B33B87: > ns3::ProcessManager::CreateWithStack(std::string, unsigned int, > std::vector<std::string, std::allocator<std::string> >, > std::vector<std::pair<std::string, std::string>, > std::allocator<std::pair<std::string, std::string> > >) > (process-manager.cc:262) > ==13019== by 0x5B475D4: ns3::ProcessManagerTestCase::DoRun() > (process-manager-test.cc:61) > ==13019== by 0x5497526: ns3::TestCase::Run() (test.cc:152) > ==13019== by 0x5499766: ns3::TestSuite::DoRun() (test.cc:684) > ==13019== by 0x5498E6A: ns3::TestSuite::Run() (test.cc:459) > ==13019== by 0x4023EA: main (test-runner.cc:263) > ==13019== Address 0x414dfe8 is not stack'd, malloc'd or (recently) free'd > ==13019== > ==13019== > ==13019== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y > ==13019== starting debugger with cmd: /usr/bin/gdb -nw /proc/13023/fd/1014 > 13023 > > [...] > > __makecontext (ucp=0x64ee350, func=0x5b369fc > <ns3::ProcessManager::DoCreateThread()>, argc=0) > at ../sysdeps/unix/sysv/linux/x86_64/makecontext.c:77 > 77 sp[0] = (unsigned long int) &__start_context; > (gdb) p sp > $1 = (long unsigned int *) 0x414dfe8 > Current language: auto; currently minimal > (gdb) set output-radix 16 > Output radix now set to decimal 16, hex 10, octal 20. > (gdb) p 0x404e000 + 1052672 > $2 = 0x414f000 > (gdb) p $pc > $3 = (void (*)()) 0x339e041b2f <__makecontext+95> > (gdb) disas > [...] > 0x000000339e041b28 <__makecontext+88>: mov %rax,0x80(%rdi) > 0x000000339e041b2f <__makecontext+95>: mov %rcx,(%r8) > [...] > (gdb) p $r8 > $4 = 0x414dfe8 > (gdb) > > Which shows that I do a successfull annonymous mmap of read/write > memory from 0x404e000 to 0x414f000 and then the libc makecontext > function attempts to write at 0x414dfe8 and that triggers the > valgrind "invalid write of size 8" warning. Any idea of what I could > possible be doing wrong here ? > > Mathieu ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
