I have the task to debug a program using Valgrind. The program becomes very slow due to the Valgrind usage. This is a problem, because the program has a watcher thread that kills slow threads with SIGABRT if they spend too much time in certain functions. The program is in a valid state when it exits in that way, so I would like to keep it running even if SIGABRT is cast. I cannot change the program to switch off the watcher thread from the source code.
Now my question:
Does Valgrind, or a tool compatible with Valgrind, give me the option to say to the program: "If you receive SIGABRT, treat it as a null op and go on?"
You might achieve what you want by running your program under valgrind + gdb, using vgdb.
With gdb, you can then control what to do with the SIGABRT signal.
For example, launch your program with:
valgrind --vgdb-stop-at=startup your_program
In another window, launch gdb:
(gdb) handle SIGABRT nostop print nopass
(gdb) target remote | vgdb
(gdb) continue
See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver for more information.
Related
I'm debugging a multi-threaded C++ application in Eclipse Oxygen with gdb 7.4
The default behaviour is that when a breakpoint is reached all threads are halted, however, I'd like only the thread that reached the breakpoint to halt and all others would continue to run.
How is possible?
How is possible?
(gdb) set non-stop on
By default non-stop mode is off. You want it to be on, see gdb builtin help:
(gdb) help set non-stop
Set whether gdb controls the inferior in non-stop mode.
When debugging a multi-threaded program and this setting is
off (the default, also called all-stop mode), when one thread stops
(for a breakpoint, watchpoint, exception, or similar events), GDB stops
all other threads in the program while you interact with the thread of
interest. When you continue or step a thread, you can allow the other
threads to run, or have them remain stopped, but while you inspect any
thread's state, all threads stop.
In non-stop mode, when one thread stops, other threads can continue
to run freely. You'll be able to step each thread independently,
leave it stopped or free to run as needed.
(gdb)
I'm using valgrind to check memory leaks.
My application has two threads:
Main thread who running tests.
Worker thread who waiting for messages from main thread and
executing commands according to the received message.
When memory leak is found by valgrind, if leak is related to the worker thread, valgrind report shows stack trace of the worker thread.
In order to fix such leak, I need to know which test caused the leak. The test name/ID is coming from the main thread trougth message queue.
Is it possible to add test name or ID to the valgrind report?
Is it possible to add test name or ID to the valgrind report?
No, it is impossible, as far as I know.
But you can attach to your application with gdb when memory leak is found by valgrind. Here is the description of how to do it in valgrind manual:
If you want to debug a program with GDB when using the Memcheck tool,
start Valgrind like this:
valgrind --vgdb=yes --vgdb-error=0 prog
In another shell, start GDB:
gdb prog
Then give the following command to GDB:
(gdb) target remote | vgdb
Now you can find in stack trace the place where you receiving messages from main thread and print in gdb test name, ID or whatever you want.
The solution we found is to use valgrind macros: VALGRIND_DO_CHANGED_LEAK_CHECK, VALGRIND_COUNT_LEAKS, VALGRIND_COUNT_LEAK_BLOCKS in order to determinate which test causes leak
I've been debugging multi-process job. Create multiple threads at program initialization. I found while I'm using gdb for debug, the threads can all be set up successfully, but when I execute the program directly in linux environment, it stucks after part of the threads being created. I'm thinking it must be some schedule problem between thread sleep and wakeup but haven't figure that out yet..
And although gdb can create the threads successfully, it quits with an unexpected segmentation fault in a glibc function after thread killed itself:
res_thread_freeres () at res_init.c:642
642 if (_res.nscount == 0)
which is also wierd because I can check the value of _res.nscount, it didn't overflow definately.
So.. Does anybody have a clue about the execution difference between an actual os and gdb debug environment? Thanks!
Update:
I've located the problem to pthread being set to SCHED_FIFO, after I removed this, it works fine. But I'm still not aware of why the program works fine in gdb environment.. Actually the thread state of the program got changed the moment it is attached to gdb.
Have been trying to remote debug an application running on my target using GDB.
The target is Armv6 based, the OS is linux and the application is a QT based Multithreaded application.
I am able to set the break point. But when the break point is hit, program gets crashed along with SIGTRAP.
Hint: I am able to run another small sample Multithreaded QT-App on the same target.
What could be the problem?
GDB Log as follows
Breakpoint 1 at 0x4ad52c: file <> , <>. (2 locations)
(gdb) c
Continuing.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
(gdb)
(gdb)
You have maybe a solution here:
http://sourceware.org/gdb/wiki/FAQ#GDB_does_not_see_any_threads_besides_the_one_in_which_crash_occurred.3B_or_SIGTRAP_kills_my_program_when_I_set_a_breakpoint.
Hope this help.
Regards.
well, the gdb trace the process by ptrace , and the ptrace set breakpoint in the space of the
thread , the space addr is shared by the other thread, if the other thread reached the breakpoint, oh, the kernel generate a sigtrap for the thread.
more info in the follow
http://lists.alioth.debian.org/pipermail/ltrace-devel/2006-April/000036.html
I have a server program, which doesn't have a very clean/graceful shutdown (not supposed to terminate in general). When tracing memory leaks, I run it under valgrind, but finally have to kill the process by a signal (^C). Generally I try to terminate the process when the ambiance is quiet but still then some threads might have been busy processing jobs and memory held by them cause false alarms. To assist such analysis, is there any way (tool) in valgrind, so that it can print the backtrace of threads when the program exits (by a signal?).
I know it's inconvenient, but could you get your program to dump core when it gets this signal, then diagnose the core dump with gdb?
Don't sure I quite understand your question, but you can print backtrace of all pthreads by gdb:
thread apply all bt