Re: crash when opening a newsgroup

[David Hunter]

Timmy Douglas wrote:
> I was just reading a newsgroup earlier today and when I went to the
> next message:
>
>
> Program received signal SIGPIPE, Broken pipe.
> 0xb772cca7 in *__GI___sigsuspend (set=0x8329ce0) at sigsuspend.c:69
> 69      sigsuspend.c: No such file or directory.
>         in sigsuspend.c
> (gdb) bt
> #0  0xb772cca7 in *__GI___sigsuspend (set=0x8329ce0) at sigsuspend.c:69
> #1  0x08137933 in wait_for_termination (pid=4974) at sysdep.c:481

Hmm.  As in your C-g abort, that also looks like a previously blocked SIGPIPE, but 
this time being unblocked by sigsuspend (&empty_mask).  When you (accidentally) 
continued, execution transferred immediately to the SIGPIPE signal handler, which 
took you back to send_process.  You showed with the backtrace from sigsuspend that 
you weren't even in a call to send_process.  The longjmp from the signal handler 
was therefore invalid, resulting in stack mangling and quick death.

I bet that was the second SIGPIPE you got.  I'm interested in the first one, 
the one that occurred inside write.  What's gnus doing to get frequent 
SIGPIPEs?  Is it due to a TCP RST from your newsserver?  I'd be surprised if 
you're the only user to experience that problem.

According to recent lore, gdb can generate a core dump on the command `gcore'.  
You'll get a file `core.PID'.  Then you can come back to examine it later.

Next time you get the first SIGHUP, save a core dump, and try this:

(gdb) tbreak 'process.c:5403     # (or whatever line starts with 
p->raw_status_low)
(gdb) c

That should put you in a safe place to do debugging.  Let's see where you are 
in gnus:

(gdb) bt
(gdb) xbacktrace

Examine the process structure.  If it's a network stream, the childp field 
contains a property list:

(gdb) p p->childp
(gdb) pr                         # but don't post your IP address!

The documentation for `make-network-process' describes this list.  If it's a 
TCP connection, check if it was just reset.  Shell out, run netstat, and look 
for the line describing that connection.  If it was reset by remote, it'll be 
in CLOSE_WAIT or TIME_WAIT, I forget which.

-Dave