|
From: Julian S. <js...@ac...> - 2006-09-18 10:00:52
|
You got a bunch of different things going on here. First off, by far your best bet for getting this resolved is to file a bug report as described at http://www.valgrind.org/support/bug_reports.html. Secondly, please upgrade to the recently released 3.2.1 and try again. That might resolve some of the "unhandled syscall" messages. Thirdly, try using the --max-stackframe=18662400 option that V directs you to. Does that help? Probably not, but worth a try. Forthly, it looks like you have an 18.6MB array (or collection of them) as local data in __constraints_NMOD_init_imask_constr. Can you try allocating them somewhere else, specifically on the heap? I do know that recent Valgrinds work fairly well with xlc/xlf generated code. J On Monday 18 September 2006 05:20, David Robert Lee wrote: > hey Julian, > > i've been running valgrind v. 3.2.0 on a SLES 9 Linux from SUSE platform > using a single power5 CPU. > > when i try to run my code without valgrind it runs fine, but when i use > valgrind with any (or no) option is produces the following segmentation > fault: > > dlee@edda:~/wmd2/mem_test> valgrind ./wmd2 > ==2127== Memcheck, a memory error detector. > ==2127== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. > ==2127== Using LibVEX rev 1606, a library for dynamic binary translation. > ==2127== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. > ==2127== Using valgrind-3.2.0, a dynamic binary instrumentation framework. > ==2127== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. > ==2127== For more details, rerun with: -v > ==2127== > --2127-- WARNING: unhandled syscall: 104 > --2127-- You may be able to write your own handler. > --2127-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > ==2127== Warning: client switching stacks? SP change: 0x7FEFFD9B0 --> > 0x7FDE315B0 ==2127== to suppress, use: --max-stackframe=18662400 > or greater ==2127== Invalid write of size 8 > ==2127== at 0x10041D10: __constraints_NMOD_init_imask_constr (in > /home/san01/dlee/wmd2/mem_test/wmd2) ==2127== Address 0x7FDE315B0 is on > thread 1's stack > ==2127== > ==2127== Process terminating with default action of signal 11 (SIGSEGV) > ==2127== Access not within mapped region at address 0x7FDE315B0 > ==2127== at 0x10041D10: __constraints_NMOD_init_imask_constr (in > /home/san01/dlee/wmd2/mem_test/wmd2) ==2127== > ==2127== Invalid write of size 8 > ==2127== at 0x403079C: _vgnU_freeres (vg_preloaded.c:56) > ==2127== Address 0x7FDE315A8 is just below the stack ptr. To suppress, > use: --workaround-gcc296-bugs=yes ==2127== > ==2127== Process terminating with default action of signal 11 (SIGSEGV) > ==2127== Access not within mapped region at address 0x7FDE315A8 > ==2127== at 0x403079C: _vgnU_freeres (vg_preloaded.c:56) > ==2127== > ==2127== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 1) > ==2127== malloc/free: in use at exit: 21,633,538 bytes in 89 blocks. > ==2127== malloc/free: 235 allocs, 146 frees, 22,599,851 bytes allocated. > ==2127== For counts of detected errors, rerun with: -v > ==2127== searching for pointers to 89 not-freed blocks. > ==2127== checked 21,626,984 bytes. > ==2127== > ==2127== LEAK SUMMARY: > ==2127== definitely lost: 0 bytes in 0 blocks. > ==2127== possibly lost: 0 bytes in 0 blocks. > ==2127== still reachable: 21,633,538 bytes in 89 blocks. > ==2127== suppressed: 0 bytes in 0 blocks. > ==2127== Reachable blocks (those to which a pointer was found) are not > shown. ==2127== To see them, rerun with: --show-reachable=yes > Segmentation fault > > > the compiler options i've been building the code with (using an IBM xlf > FORTRAN 90 compiler) are as follows: > > F90FLAGS = -q64 -pg -qsuffix=f=f90 > > any ideas? > > cheers, dave. |