[Valgrind-users] valgrind3.9.0 does not work with my application.

[Guoqiuping <guo...@hu...>]

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?