|
From: Mehric A. <Asm...@ic...> - 2004-03-08 16:28:42
|
I'm running a multithreaded application on Red Hat 7.2. Valgrind was build from CVS and runs just fine with coregrind, addrcheck and cashecheck but fails with memcheck and helgrind. Here are the outputs from both problematic runs: ******************************* ==19005== Memcheck, a memory error detector for x86-linux. ==19005== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==19005== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==19005== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==19005== Valgrind library directory: /home/src/user/amehric/valgrind-new-inst/lib/valgrind ==19005== Command line ==19005== ./sca_sip ==19005== Startup, with flags: ==19005== -v ==19005== --tool=memcheck ==19005== Reading syms from /home/sca_sip/bin/sca_sip (0x8048000) --19005-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --19005-- si_code=1 Fault EIP: 0xB030B673 (); Faulting address: 0x50100000 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 0 ==19005== at 0xB802D502: ??? ==19005== by 0xB802D501: ??? ==19005== by 0xB802D519: ??? ==19005== by 0xB80332A7: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==19005== at 0x3C001E10: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ******************************* ==19037== Helgrind, a data race detector for x86-linux. ==19037== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==19037== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==19037== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==19037== Valgrind library directory: /home/src/user/amehric/valgrind-new-inst/lib/valgrind ==19037== Command line ==19037== ./sca_sip ==19037== Startup, with flags: ==19037== -v ==19037== --tool=helgrind ==19037== Reading syms from /home/sca_sip/bin/sca_sip (0x8048000) --19037-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --19037-- si_code=1 Fault EIP: 0xB016AB70 (); Faulting address: 0x54100000 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 0 ==19037== at 0xB802D502: ??? ==19037== by 0xB802D501: ??? ==19037== by 0xB802D519: ??? ==19037== by 0xB80332A7: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==19037== at 0x3F001E10: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ********************************** It seams to be the same problem in both cases. How can I debug this ? Are there any command line flags that will give more information ? Thanks Asmir Mehic |
|
From: Tom H. <th...@cy...> - 2004-03-08 17:17:33
|
In message <32B...@is...>
Mehric Asmir <Asm...@ic...> wrote:
> I'm running a multithreaded application on Red Hat 7.2.
> Valgrind was build from CVS and runs just fine with coregrind, addrcheck and
> cashecheck but fails with memcheck and helgrind.
> Here are the outputs from both problematic runs:
It's failing with the skins that ask for a lot of shadow memory by
the looks of it, which probably means the large mmaps are failing
which is something I saw once but was unable to reproduce after a
reboot.
I think some kernels reject vaery large mmaps under certain sorts
of memory starvation condition or something - there is a bug for it
on the bug tracker somewhere.
If you're not already using the latest kernel for that version
of RH then I'd suggest upgrading or even just trying a reboot of
the machine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-03-08 17:52:32
|
On Mon, 2004-03-08 at 09:09, Tom Hughes wrote: > I think some kernels reject vaery large mmaps under certain sorts > of memory starvation condition or something - there is a bug for it > on the bug tracker somewhere. > > If you're not already using the latest kernel for that version > of RH then I'd suggest upgrading or even just trying a reboot of > the machine. It could also be a virtual address size limit, like the one Dirk has installed. There's not a lot we can do about it, other than trying to raise the soft limit. Actually, the most useful thing we can do is check the error returns on all mmaps and generate a useful error message rather than SEGV mysteriously. J |