GDB blows up when debugging multithreaded program that fast-forks and executes another program

Question

I'm debugging my C program(s) with GDB and it's kinda wonky, probably because I'm not using glibc so it doesn't detect new threads until it breaks in them. I fixed this by adding a breakpoint which immediately resumes (break if 0).

Today however I ran into a wall.

I need to execve() really fast so normal fork() is out of the question (will use a ton of memory) and I can't vfork() (I need a stack to set up pipes etc) so I used the same method as in this library (https://code.google.com/p/popen-noshell/) which is basically only cloning with CLONE_VM. This (or calling execve() in general - I don't really know) makes GDB really confused for some reason - basically it's outputting something like this:

[New LWP 516]
[New LWP 520]
[New LWP 519]
[New LWP 521]
LWP 521 is executing new program: /bin/bash
Error in re-setting breakpoint 1: No source file named xxx.c.
Error in re-setting breakpoint 2: No source file named yyy.c.
Error in re-setting breakpoint 4: Function "zzz_main" not defined.
[LWP 521 exited]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to LWP 519]
0x00000000004307f8 in shell_execve ()
(gdb) info threads 
Id   Target Id         Frame 
* 5    LWP 519 "self-tes" 0x00000000004307f8 in shell_execve ()
4    LWP 520 "self-tes" 0x000000000040825f in ?? ()
3    LWP 516 "self-tes" 0x000000000040825f in ?? ()
2    LWP 515 "self-tes" 0x000000000040825f in ?? ()
1    LWP 512 "self-tes" 0x000000000040848a in ?? ()

GDB basically get's confused about everything and think it's currently executing /bin/bash - it's not - running without GDB works fine however I need it to debug my program. I've tried to disable every fork and exec setting I could find but nothing like "follow exec" is enabled. As you can see it tries to re-set breakpoints after the execve()... why?? It no longer recognizes any frames or symbols as it completely wiped the previous space and loaded /bin/bash instead.

How can I make GDB ignore the thread that calls the execve() and NOT try to load symbols for the subprocess?

EDIT: Oh and I'm currently using x86_64 Linux 3.2.0-27 (Ubuntu).

EDIT2: Also GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04

EDIT3: Also just checked with gdb 7.5. Same problem.

Answer 1

Found the problem! Apparently I forgot to mask flags with SIGCHLD when cloning which apparently gdb (or libthread) uses as a hint of spawning a subprocess (fork style) and not just another thread. Thanks @R.. for the hint which lead me in the right direction.