|
From: Guoqiuping <guo...@hu...> - 2014-06-30 01:27:40
|
Hello: My application work without using valgrind, but when I use valgrind 390 with my application, the application crash soon after start: ==25545== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==25545== Access not within mapped region at address 0x86C006000 ==25545== at 0x52308C4: _IO_vfscanf (in /lib64/libc-2.4.so) ==25545== by 0x523E7A4: vsscanf (in /lib64/libc-2.4.so) ==25545== by 0x52399E7: sscanf (in /lib64/libc-2.4.so) ==25545== by 0x47455D32: ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::priRefreshTotalMEMInfo()(resourcedetect.cpp:647) ==25545== by 0x47455F03: ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::priCalcTotalMEMUsage()(resourcedetect.cpp:975) ==25545== by 0x47458274: ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::priRefreshSysResInfo()(resourcedetect.cpp:1271) ==25545== by 0x474587C9: ngin::common::V1_0_0_0::resourcemonitor::CSystemResCtrlThread::run()(resourcedetect.cpp:86) ==25545== by 0x6A27554: startHook (Thread.cpp:411) ==25545== by 0x4A23142: start_thread (in /lib64/libpthread-2.4.so) ==25545== by 0x529E74C: clone (in /lib64/libc-2.4.so) ==25545== If you believe this happened as a result of a stack ==25545== overflow in your program's main thread (unlikely but ==25545== possible), you can try to increase the size of the ==25545== main thread stack using the --main-stacksize= flag. ==25545== The main thread stack size used in this run was 16777216. ==25545== The stack trace seems like the Bug 95667 reported in 2004. I think the bug has been already solved. But why it happened again for me? My application's code as below: resourcedetect.cpp:647 647: if ( MEM_INFO_RECORDS_ITEM_NUM != sscanf(m_arrArray4TempBuff, 648: "%s %llu", 649: m_arrCurTotalMemInfo[i].name, 650: &m_arrCurTotalMemInfo[i].value)) The type of m_arrCurTotalMemInfo[i].name is char[], And the type of m_arrCurTotalMemInfo[i].value is int8, so I think there is no bug in my application. Anyone could help me? |
|
From: John R.
|
> My application work without using valgrind, but when I use valgrind 390 Thank you for mentioning the version number of valgrind. with my application, the application crash soon after start: > > > > ==25545== Process terminating with default action of signal 11 > > (SIGSEGV): dumping core > > ==25545== Access not within mapped region at address 0x86C006000 > > ==25545== at 0x52308C4: _IO_vfscanf (in /lib64/libc-2.4.so) Please tell us what hardware architecture, and which operating system and version, and which distribution. Post the output from "uname -a", which gives good information. /lib64 implies a 64-bit machine. Current glibc on x86_64 boxes is something like: $ ls -l /lib64/libc-*.so -rwxr-xr-x. 1 root root 2108632 Nov 16 2013 /lib64/libc-2.17.so [that's Fedora 19] so libc-2.4.so must be something else. > The stack trace seems like the Bug 95667 reported in 2004. I think the bug has been already solved. But why it happened again for me? Bug 95667 [in 2004, ten years ago] was on x86*, Because the bug and the fix are machine-dependent, then perhaps a similar situation arose afterwards on a different machine architecture. What architecture *are* you running? |
|
From: Guoqiuping <guo...@hu...> - 2014-06-30 08:03:45
|
uname -a: Linux TB2SEE1 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux rpm -q glibc: glibc-2.4.31.43.6.PTE.473402.0 /lib64/libc.so.6->libc.2.4.so -----邮件原件----- 发件人: John Reiser [mailto:jreiser@BitWagon.com] 发送时间: 2014年6月30日 11:19 收件人: val...@li... 主题: Re: [Valgrind-users] valgrind3.9.0 does not work with my application. > My application work without using valgrind, but when I use valgrind > 390 Thank you for mentioning the version number of valgrind. with my application, the application crash soon after start: > > > > ==25545== Process terminating with default action of signal 11 > > (SIGSEGV): dumping core > > ==25545== Access not within mapped region at address 0x86C006000 > > ==25545== at 0x52308C4: _IO_vfscanf (in /lib64/libc-2.4.so) Please tell us what hardware architecture, and which operating system and version, and which distribution. Post the output from "uname -a", which gives good information. /lib64 implies a 64-bit machine. Current glibc on x86_64 boxes is something like: $ ls -l /lib64/libc-*.so -rwxr-xr-x. 1 root root 2108632 Nov 16 2013 /lib64/libc-2.17.so [that's Fedora 19] so libc-2.4.so must be something else. > The stack trace seems like the Bug 95667 reported in 2004. I think the bug has been already solved. But why it happened again for me? Bug 95667 [in 2004, ten years ago] was on x86*, Because the bug and the fix are machine-dependent, then perhaps a similar situation arose afterwards on a different machine architecture. What architecture *are* you running? ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R.
|
> uname -a: > Linux TB2SEE1 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux > > rpm -q glibc: > glibc-2.4.31.43.6.PTE.473402.0 > > /lib64/libc.so.6->libc.2.4.so That information shows that the software environment is about 7 years old. While valgrind-3.9.0 is the latest release, and problems with the latest release always are relevant, the old age of the user application environment likely will make it more difficult to catch and hold the attention of valgrind developers. Here are two things that can be done to increase interest: 1) Construct a small test case which reproduces the problem. Extract code from the application, or write a new program. Something like 50 to 100 lines should be enough. In some cases using 'strace' on the application (or on valgrind running the application) may provide hints about what is important just before the error. In other cases using a debugger such as 'gdb' may give insights about what is happening. Pay particular attention to signals, threading (if any), and other less-common events. 2) Reproduce the problem using recent glibc. Determine the shared libraries that the application uses by running "ldd ./my_application". Intersect that with the shared libraries provided by glibc, which are listed by: "rpm -ql glibc". Then go to another machine that has recent glibc installed, and copy the intersected shared libraries from the newer glibc installation onto a new directory $NEWDIR on the _old_ machine. In that new directory $NEWDIR on the old machine, also create any symbolic links that are relevant, such as libc.so -> libc-2.NN.so. Then run valgrind running the old application using the newer glibc by: $NEWDIR/ld-linux-x86-64.so.2 --library-path $NEWDIR:$LD_LIBRARY_PATH \ valgrind _valgrind_options_ ./my_application _application_arguments_ Read the hints given by: $NEWDIR/ld-linux-x86-64.so.2 You can test the shared library dependencies using $NEWDIR/ld-linux-x86-64.so.2 --library-path $NEWDIR:$LD_LIBRARY_PATH --list ./my_application to verify that all the shared libraries are coming from the correct directories. If the problem persists when using current glibc, then that increases the motivation of valgrind developers to investigate. If the problem goes away when using current glibc, then a) you have a running valgrind on the application, and b) why not install the newer glibc? |