Unable to live profiling

[marrtin]

Hi I am using profiler tool according tutorial https://visualgdb.com/tutorials/profiler/linux/live/. But it doesn’t create the dump file

Following error is displayed when I stop the profiling to see the results:

VisualGDB version: 5.5.104.3920
—————— System.Exception ——————
System.Exception: Failed to locate the newly created dump file in /tmp/2e48884f-d532-4289-9e0b-2e1378af5121
at uv1.a()
at y31.g1(Object a, EventArgs b)
trace=[uv1.a:698, y31.g1:46]

the path /tmp/2e48884f-d532-4289-9e0b-2e1378af5121 is valid directory with some valgrind files.

Please what’s wrong?

By the way I am on Red Hat Enterprise Linux Server release 7.9 and I am using valgrind from devtoolset-8

Thanks

 

[support]

This error happens with VisualGDB requests Valgrind to dump the current information gathered by the profiler into a dump file. Normally, it would create a new dump file in the Valgrind session directory (/tmp/2e48884f-d532-4289-9e0b-2e1378af5121 in this case), however due to some reason, Valgrind does not create it in this case, or VisualGDB fails to locate it.

In order to troubleshoot it further, please try following the steps below:

1. Enable View->Other Windows->VisualGDB Diagnostics Console.
2. Start a profiling session with debugging and wait for it to trigger on a breakpoint.
3. Locate the valgrind launch command in the diagnostics console and find out session directory from the –vgdb-prefix switch.
4. Check the contents on the session directory manually.
5. Try running the “monitor dump” command in the GDB Session window.
6. Check if this created any new files in the session directory.

If Valgrind did not create any new dump files, it could be a bug of Valgrind. Trying other configuration options, or a newer Valgrind version might solve the problem.

If the new dump file was created, the remote system might be missing the ‘ls’ or ‘stat’ commands used by VisualGDB to query the file list. You can locate the exact command lines used by VisualGDB (e.g. cd “/tmp/34f1e35f-a7e2-4b00-b34c-24659c90a8f5” && ls -1A | xargs -d “\n” stat -c “StatEntryL:|%N|%Y|%d|%s|%f” .) in VisualGDB Diagnostics Console and try running them manually to see if they work on the target. If you get any errors from running that command line, please let us know and we will investigate it further.

[marrtin]

Hi hopefully I have investigated the issue correct.

The command: ls -1A | xargs -d “\n” stat -c “StatEntryL:|%N|%Y|%d|%s|%f” gives following result in /tmp/xxxxxx-a7e2-4b00-b34c-xxxxx folder

StatEntryL:|‘callgrind.out’|1623402505|64771|0|11a4
StatEntryL:|‘callgrind.out.1’|1623402525|64771|489797|8180
StatEntryL:|‘valgrind.log’|1623402506|64771|0|11a4

But in reality only callgrind.out.1 and valgrind.log exist (callgrind.out is missing in filesystem)

callgrind.out.1 – has 478kb size in my small testcase and can be candidate for core file.

Thanks for next advision

[support]

If the ls/stat commands produce output that looks valid, but doesn’t match the actual state of the file system, it could indicate a filesystem corruption or some other strange bug.

In generally, VisualGDB needs a reliable way to find out the name of the file that was created in response to the “dump” command. Our best advice would be to experiment with different modes of ls, stat and also run the dump command multiple times to understand why they don’t work on that target. In generally, the output from the file listing command after running the dump command should contain exactly 1 more entry starting with “callgrind.out”.

[Author]

Posts