Thanks for your reply.
> Does this happen if you just let the system run within gdb, or only when you start setting breakpoints, stopping and starting etc?
The signal is sent to my main program if I just let it run under gdb, no breakpoints or anything set. It is a remote gdb session to an arm machine, probably relevant if there is a very short timing issue involved.
> Which process are you debugging - the parent or child?
I am debugging the parent process. I had tried setting follow fork mode:
Code:
set follow-fork-mode child
But the result is the same when I do this. It does not seem to actually attach to the child for some reason.
I just set CURLOPT_NOSIGNAL to 1 and this didn't seem to change anything. Also confirmed that I'm not setting any of curl's timeout options so it should be all defaults. I think the child is actually crashing legitimately and that if I could get gdb to debug it, I would see what the issue is.
>> A crash does occur after the program has run for several minutes, but this seems unrelated (I'm sure it's related).
> Is this because the pipes are full, because the debugged parent isn't reading information fast enough to keep up with the free-running child?
This one only occurs outside of gdb. Under gdb, the earlier crash prevents the curl request from completing, so the child never writes anything to its output pipe. When this crash outside of gdb happens, the parent program is able to read the full contents of the worker's output pipe three times (child writes to it every 30 seconds) before it crashes with an unexpected null pointer. This does seem like some kind of buffer overflow as so far it's always exactly three times (and the curl'd response size sent over the pipe has not varied during testing so far).
I'm going to see if I can get rid of this crash when not running under gdb since that at least seems debug-able and see if fixing that changes the behavior under gdb...