Posts for General Preethi Selvaraju http://community.qnx.com/sf/go/post121906 2022-08-29T12:42:00Z 2022-08-29T12:42:00Z

when I run my application, Hardware which has QNX OS [QDrive] itself is crashing when I use --leak-check=full option. If I use --leak-check=summary, its working. Is there anyway to find why valgrind is not working with full option? I need to find memory leak in child processes also. In order to use --track-children=yes , Do we need to use full option not summary?

Preethi Selvaraju 2022-08-29T12:42:00Z Preethi Selvaraju http://community.qnx.com/sf/go/post121899 2022-08-23T04:11:56Z 2022-08-23T04:11:56Z

Thank you for the support. I've copied architecture specific valgrind libs and binaries to QDrive and set the LD_LIBRARY_PATH and VALGRIND_LIB path. Now Valgrind is working. I could able to run small applications with valgrind and it detects memory leak and double free perfectly. But when I run my application, Hardware which has QNX OS [QDrive] itself is crashing. I just used --leak-check=full option. is there any way to collect valgrind logs or why is it happening?

Preethi Selvaraju 2022-08-23T04:11:56Z Jim Sleeth http://community.qnx.com/sf/go/post121898 2022-08-18T04:25:24Z 2022-08-18T04:25:24Z

The command line options are described on http://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/v/valgrind.html but you will first need to copy the architecture specific files from the QSC package onto your system. com.qnx.qnx710.target.utils.valgrind

Jim Sleeth 2022-08-18T04:25:24Z Preethi Selvaraju http://community.qnx.com/sf/go/post121897 2022-08-17T12:26:53Z 2022-08-17T12:26:53Z

Hardware(QDrive): QualCOMM Snapdragon ride platform QNX: SDK 11.1 Is it possible to run valgrind as a command without using Momentics IDE? Basically our application is crashing in initialization itself if we run through Momentics[We are talking to the appropriate team to fix this. Even simple programs is not working]. So for now, What we basically do is copy our executable to the QDrive through WinSCP and execute through command prompt using telnet to that QDrive IP. We've QNX SDK 11.1 on our QDrive. If we enter valgrind command, its not able to find. # valgrind sh: valgrind: cannot execute - No such file or directory What is the correct way of using Valgrind tool without using Momentics IDE? Do we need to re-build QNX SDK with certain option when configure/build to include valgrind? If so, Can you please specify. We download QNX SDK from https://chipcode.qti.qualcomm.com/ Currently using sa8540p-qx-1-0_hlos_dev_qnx/tree/r00011.1a.502856.3 SDK. Note: Please let me know if it is not the right forum to ask questions about valgrind tool and point me to the appropriate forum.

Preethi Selvaraju 2022-08-17T12:26:53Z Murugaiyan Perumal(deleted) http://community.qnx.com/sf/go/post119972 2019-09-24T01:41:52Z 2019-09-24T01:41:52Z

Able to run same application successfully(without crash) in valgrind using callgrind and cachegrind as tool options. The problem is the application crash if I use memcheck as passed in tool options or no options in valgrind. The same application using valgrind ran successfully in QNX 6.5 for memcheck tools.

Murugaiyan Perumal(deleted) 2019-09-24T01:41:52Z Murugaiyan Perumal(deleted) http://community.qnx.com/sf/go/post119971 2019-09-24T01:11:04Z 2019-09-24T01:11:04Z

Hi, Running valgrind for QNX6.6. In my application std::vector are used in c++ application. The valgrind always crash in std::vector push_back function. The application release and debug version always crash if I run using valgrind. The same application no crash without valgrind if I run in release/debug mode. Couldn't able to find out what could be the reason for the application crashes in std::vector push_back() using valgrind. Below are the valgrind logs stripped. Attached the stack backtrace of crash --00:00:00:00.000 39178275-- Valgrind options: --00:00:00:00.000 39178275-- --tool=memcheck --00:00:00:00.000 39178275-- -v --00:00:00:00.000 39178275-- --time-stamp=yes --00:00:00:00.000 39178275-- --log-file=/var/valgrind/report/tkmain_g_memcheck.log.092419.090119 --00:00:00:00.000 39178275-- --extra-debuginfo-path=/lib --00:00:00:00.000 39178275-- --allow-mismatched-debuginfo=yes --00:00:00:00.000 39178275-- --track-origins=yes --00:00:00:00.000 39178275-- Contents of /proc/version: --00:00:00:00.000 39178275-- can't open /proc/version --00:00:00:00.000 39178275-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-lzcnt --00:00:00:00.000 39178275-- Page sizes: currently 4096, max supported 4096 --00:00:00:00.000 39178275-- Valgrind library directory: /usr/lib/valgrind ..................... --00:00:00:02.686 39178275-- REDIR: 0x159d7a0 (libcpp.so.5:operator new(unsigned int)) redirected to 0xc97c7 (operator new(unsigned int)) ==00:00:00:05.955 39178275== Invalid read of size 1 ==00:00:00:05.955 39178275== at 0xCA6E1: strlcpy (vg_replace_strmem.c:578 in /usr/lib/valgrind/vgpreload_memcheck-x86-nto.so) ==00:00:00:05.956 39178275== by 0x8051F8F: int* std::_Uninit_move<int, int, int>(int*, int*, int*, std::_Wrap_alloc<std::allocator<int> >&, int*, std::_Scalar_ptr_iterator_tag) (xmemory:486 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8051EEC: int* std::_Uninit_move<int*, int*, std::_Wrap_alloc<std::allocator<int> > >(int*, int*, int*, std::_Wrap_alloc<std::allocator<int> >&) (xmemory:513 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8051DD4: int* std::_Uninitialized_move<int*, int*, std::_Wrap_alloc<std::allocator<int> > >(int*, int*, int*, std::_Wrap_alloc<std::allocator<int> >&) (xmemory:524 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8051C88: int* std::vector<int, std::allocator<int> >::_Umove<int*>(int*, int*, int*) (vector:1863 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x80514AC: std::vector<int, std::allocator<int> >::_Reallocate(unsigned int) (vector:1806 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8050A20: std::vector<int, std::allocator<int> >::_Reserve(unsigned int) (vector:1832 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x804FDFF: std::vector<int, std::allocator<int> >::push_back(int&&) (vector:1012 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x804DD6E: main (TUKMainApp.cpp:149 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==00:00:00:05.956 39178275== ==00:00:00:05.956 39178275== ==00:00:00:05.956 39178275== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==00:00:00:05.956 39178275== Access not within mapped region at address 0x0 ==00:00:00:05.956 39178275== at 0xCA6E1: strlcpy (vg_replace_strmem.c:578 in /usr/lib/valgrind/vgpreload_memcheck-x86-nto.so) ==00:00:00:05.956 39178275== by 0x8051F8F: int* std::_Uninit_move<int, int, int>(int*, int*, int*, std::_Wrap_alloc<std::allocator<int> >&, int*, std::_Scalar_ptr_iterator_tag) (xmemory:486 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8051EEC: int* std::_Uninit_move<int*, int*, std::_Wrap_alloc<std::allocator<int> > >(int*, int*, int*, std::_Wrap_alloc<std::allocator<int> >&) (xmemory:513 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8051DD4: int* std::_Uninitialized_move<int*, int*, std::_Wrap_alloc<std::allocator<int> > >(int*, int*, int*, std::_Wrap_alloc<std::allocator<int> >&) (xmemory:524 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8051C88: int* std::vector<int, std::allocator<int> >::_Umove<int*>(int*, int*, int*) (vector:1863 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x80514AC: std::vector<int, std::allocator<int> >::_Reallocate(unsigned int) (vector:1806 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x8050A20: std::vector<int, std::allocator<int> >::_Reserve(unsigned int) (vector:1832 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x804FDFF: std::vector<int, std::allocator<int> >::push_back(int&&) (vector:1012 in /var/debug/TUKMainApp_g) ==00:00:00:05.956 39178275== by 0x804DD6E: main (TUKMainApp.cpp:149 in /var/debug/TUKMainApp_g)

Murugaiyan Perumal(deleted) 2019-09-24T01:11:04Z Matthew Falkoski(deleted) http://community.qnx.com/sf/go/post117566 2017-03-28T21:53:34Z 2017-03-28T21:53:34Z

I running into this exact issue as well. Were you ever able to get it to work?

Matthew Falkoski(deleted) 2017-03-28T21:53:34Z Mario Charest http://community.qnx.com/sf/go/post117438 2017-02-21T21:41:40Z 2017-02-21T21:41:40Z

> mkifs is a little aggressive and will strip off the build-id and debuglink > sections. > > Without one of these valgrind is not able to reliably tell if a symbol/debug > file actually corresponds to the one being loaded. > > One method is to use the raw attribute to avoid stripping libc, as you have > been doing. You can also tell mkifs to leave certain sections alone with "-s <section>" > . If neither of these are options for you and you are positive you have the > right files, Can't do that, tech support teels me that doing so (using raw attributes) prevents the shared object from being really shared, consume extra memory in the process, > you can start playing with fire and pass "--allow-mismatched- > debuginfo=yes" to valgrind. Got it, I have to use --allow-mismtched-debuginfo AND --extra-debuginfo-path. It does not seems to be searching the default paths at all. Thanks for pointing me in the right direction.

Mario Charest 2017-02-21T21:41:40Z Michael Daniels(deleted) http://community.qnx.com/sf/go/post117437 2017-02-21T20:53:46Z 2017-02-21T20:53:46Z

mkifs is a little aggressive and will strip off the build-id and debuglink sections. Without one of these valgrind is not able to reliably tell if a symbol/debug file actually corresponds to the one being loaded. One method is to use the raw attribute to avoid stripping libc, as you have been doing. You can also tell mkifs to leave certain sections alone with "-s <section>". If neither of these are options for you and you are positive you have the right files, you can start playing with fire and pass "--allow-mismatched-debuginfo=yes" to valgrind.

Michael Daniels(deleted) 2017-02-21T20:53:46Z Mario Charest http://community.qnx.com/sf/go/post117436 2017-02-21T19:31:52Z 2017-02-21T19:31:52Z

On 650SP1 been trying to get valgrind to load symbols files for libc.so.3. Before today I used raw option to leave the symbols in /proc/boot but this creates issues so we have to take the raw option out. What ever I try to do I can't seems to get vlgrind to even search for it. Running with the same option as on the wiki page, it differs in that it does not seems to go through the search paths. Using --extra-debuginfo-path makes no difference. Suggestions? #:/tmp> QNX_TARGET=/ valgrind -v -v -v ls ==47526085== Memcheck, a memory error detector ==47526085== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==47526085== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==47526085== Command: ls ==47526085== --47526085-- Valgrind options: --47526085-- --tool=memcheck --47526085-- -v --47526085-- -v --47526085-- -v --47526085-- Contents of /proc/version: --47526085-- can't open /proc/version --47526085-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-lzcnt --47526085-- Page sizes: currently 4096, max supported 4096 --47526085-- Valgrind library directory: /usr/lib/valgrind --47526085-- TT/TC: VG_(init_tt_tc) (startup of code management) --47526085-- TT/TC: cache: 16 sectors of 27597024 bytes each = 441552384 total --47526085-- TT/TC: table: 16 tables of 11007528 bytes each = 176120448 total --47526085-- TT/TC: table: 65521 entries each = 1048336 total entries max occupancy 681408 (65%) --47526085-- Reading syms from /proc/boot/libc.so.3 --47526085-- svma 0x0000000000, avma 0x0000001000 --47526085-- No CRC or build-id in "/proc/boot/libc.so.3" ==47526085== ==47526085== ==47526085== Valgrind is exiting: ==47526085== Symbols for /proc/boot/libc.so.3 are required but not found. ==47526085== (Suggestion: compile that binary with debug-information, or provide a separate symbol-file.) ==47526085== ==47526085==

Mario Charest 2017-02-21T19:31:52Z