CODEWITHSUNDEEP
debugginggdbvalgrindcoredump
tkrishtop
tkrishtop

Reputation: 816

How to get detailed valgrind core or attach for debug with gdb to the process which cores dump at start?

I have a process which core dumps at the start and would like to know why.

What I've managed to do is this 

path_to/valgrind --undef-value-errors=no --error-limit=no --leak-check=yes --log-file=$MY_LOG_FILE my_process.exe

though that results in not very detailed log file like this

==12688== Memcheck, a memory error detector
==12688== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12688== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==12688== Command: my_process.exe
==12688== Parent PID: 4469
==12688==

and not very detailed core file

malloc.c:2392: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.

What I'd like to do is to have a detailed valgrind core file, but don't know how to do this. Another option which would be great - is to attach with gdb to the process, though how to do it if the process cores at the start?

Thank you for the ideas.

Upvotes: 1

Views: 743

Answers (2)

Simon Sobisch
Simon Sobisch

Reputation: 7288

To do this, use valgrind's gdbserver, starting it with valgrind --vgdb=yes and then at any time use target remote | vgdb in GDB to attach to it. Commonly you'd also use --vgdb-error=0 when starting valgrind to let it wait for GDB to attach at the error.

Upvotes: 1

ks1322
ks1322

Reputation: 35708

Another option which would be great - is to attach with gdb to the process, though how to do it if the process cores at the start?

You don't need to attach to the process in this case, you can run it within gdb from start:

$ gdb my_process.exe
...
(gdb) run
...

Upvotes: 1

Related Questions