emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs abort backtrace from C-g in Message mode


From: David Hunter
Subject: Re: emacs abort backtrace from C-g in Message mode
Date: Sat, 07 May 2005 16:30:59 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

Richard Stallman wrote:
This backtrace seems to say that the call to sigprocmask
allowed a pending SIGPIPE to occur, and it was not handled.
It is supposed to be handled.  So the question is, why
wasn't it.

That could only have been the cause of the problem if you used
a datagram socket.  That's unusual, isn't it?  So I don't know
if this could be related to the problem.  But I think the patch
below would fix this bug.

Richard's patch fixes a bug, but that's not the bug that Timmy encountered.

As I proposed earlier, SIGPIPE handling in send_process does not restore the 
signal mask or the old signal handler.  The first SIGPIPE is handled, but since 
the signal is never unblocked, the second SIGPIPE isn't handled until something 
(e.g., sigprocmask) unintentionally unblocks it.  That's the cause of each 
backtrace Timmy provided which shows an impossible call to process_send.

Timmy (thanks!) was able to provide a backtrace of the first SIGPIPE (see 
below).  In summary, process-send-string was sending an NNTP command to a TCP 
socket process, which was connected to an NNTP server.  write threw the 
SIGPIPE, probably because the NNTP server timed out the connection.

On GNU/Linux, entry into a signal handler blocks the signal, but a non-local 
jump from the handler does not unblock it (restore the signal mask).  Therefore 
in send_process, if (!setjmp) is false (because send_process_trap called 
longjmp), it must unblock SIGPIPE.

On most Unixes (except USG systems), entry into a signal handler does not 
restore the old signal handler.  Therefore in send_process, if (!setjmp) is 
false, it must call signal (SIGPIPE, old_sigpipe).  Additionally, the 
declaration for old_sigpipe must be moved to the top of send_process and 
quantified volatile (auto?).

Note that failing to restore the old signal handler won't result in a problem 
unless the connection to the X server is lost.  Also note that BSD systems do 
unblock SIGPIPE; BSD 4.1 by calling sigrelse in send_process_trap, and 4.2+ 
because setjmp/longjmp save and restore the signal mask.

I'll propose a patch after I set up a workable GNU/Linux system, reproduce the 
bug, and verify a fix.

-Dave

(gdb) bt
#0  0xb7a47ebe in write () from /lib/libpthread.so.0
#1  0x00000020 in ?? ()
#2 0x08137dde in emacs_write (fildes=7, buf=0x92c73f0 "LIST ACTIVE soc.culture.korean\r\n", nbyte=7) at sysdep.c:3290 #3 0x081ba377 in send_process (proc=148134988, buf=0x92c73f0 "LIST ACTIVE soc.culture.korean\r\n", len=32, object=152387995) at process.c:5307
#4  0x081baaea in Fprocess_send_string (process=148134988, string=152387992) at 
process.c:5461
#5  0x08185c3c in Ffuncall (nargs=3, args=0xbfffd854) at eval.c:2786
#6  0x081b1645 in Fbyte_code (bytestr=148267873, vector=2, 
maxdepth=-1073751984) at bytecode.c:686
#7  0x0818514d in Feval (form=137319544) at eval.c:2135
#8  0x081873a0 in Fcondition_case (args=144113008) at eval.c:1332
#9  0x081b0df3 in Fbyte_code (bytestr=148271409, vector=143, 
maxdepth=-1073751328)
   at bytecode.c:864
#10 0x0818514d in Feval (form=137319544) at eval.c:2135
#11 0x08183bbf in internal_catch (tag=-32, func=0x8184c60 <Feval>, 
arg=148225125) at eval.c:1144
#12 0x081b0e40 in Fbyte_code (bytestr=141475513, vector=141, 
maxdepth=-1073750720)
   at bytecode.c:849
#13 0x0818514d in Feval (form=137319544) at eval.c:2135
#14 0x081873a0 in Fcondition_case (args=144113008) at eval.c:1332
#15 0x081b0df3 in Fbyte_code (bytestr=148268521, vector=143, 
maxdepth=-1073750080)
   at bytecode.c:864
#16 0x0818514d in Feval (form=137319544) at eval.c:2135
#17 0x08183bbf in internal_catch (tag=-32, func=0x8184c60 <Feval>, 
arg=148226261) at eval.c:1144
---Type <return> to continue, or q <return> to quit---
#18 0x081b0e40 in Fbyte_code (bytestr=137593113, vector=141, 
maxdepth=-1073749488)
   at bytecode.c:849
#19 0x08185637 in funcall_lambda (fun=148296404, nargs=2, 
arg_vector=0xbfffe354) at eval.c:2972
#20 0x08185a45 in Ffuncall (nargs=3, args=0xbfffe350) at eval.c:2840
#21 0x081b1645 in Fbyte_code (bytestr=141539585, vector=2, 
maxdepth=-1073749168) at bytecode.c:686
#22 0x08185637 in funcall_lambda (fun=145592396, nargs=2, 
arg_vector=0xbfffe4a4) at eval.c:2972
#23 0x08185a45 in Ffuncall (nargs=3, args=0xbfffe4a0) at eval.c:2840
#24 0x081b1645 in Fbyte_code (bytestr=137761657, vector=2, 
maxdepth=-1073748832) at bytecode.c:686
#25 0x08185637 in funcall_lambda (fun=141671940, nargs=2, 
arg_vector=0xbfffe5f4) at eval.c:2972
#26 0x08185a45 in Ffuncall (nargs=3, args=0xbfffe5f0) at eval.c:2840
#27 0x081b1645 in Fbyte_code (bytestr=137761657, vector=2, 
maxdepth=-1073748496) at bytecode.c:686
#28 0x08185637 in funcall_lambda (fun=141670660, nargs=2, 
arg_vector=0xbfffe6d0) at eval.c:2972
#29 0x081857fe in apply_lambda (fun=141670660, args=137593113, eval_flag=1) at 
eval.c:2894
#30 0x08184e75 in Feval (form=141670660) at eval.c:2187
#31 0x081873a0 in Fcondition_case (args=144113008) at eval.c:1332
#32 0x081b0df3 in Fbyte_code (bytestr=137678801, vector=143, 
maxdepth=-1073747632)
   at bytecode.c:864
#33 0x08185637 in funcall_lambda (fun=141670060, nargs=0, 
arg_vector=0xbfffeaa4) at eval.c:2972
#34 0x08185a45 in Ffuncall (nargs=1, args=0xbfffeaa0) at eval.c:2840
#35 0x081b1645 in Fbyte_code (bytestr=137845257, vector=0, 
maxdepth=-1073747296) at bytecode.c:686
#36 0x08185637 in funcall_lambda (fun=145260412, nargs=1, 
arg_vector=0xbfffec54) at eval.c:2972
#37 0x08185a45 in Ffuncall (nargs=2, args=0xbfffec50) at eval.c:2840
#38 0x0818256e in Fcall_interactively (function=141825409, 
record_flag=137593113, keys=148810668)
---Type <return> to continue, or q <return> to quit---
   at callint.c:884
#39 0x08125d28 in Fcommand_execute (cmd=141825409, record_flag=137593113, keys=-32, special=137593113) at keyboard.c:9719
#40 0x0812d037 in command_loop_1 () at keyboard.c:1796
#41 0x08183cb2 in internal_condition_case (bfun=0x812ccc0 <command_loop_1>, handlers=137654129, hfun=0x81266f0 <cmd_error>) at eval.c:1385
#42 0x08120b4e in command_loop_2 () at keyboard.c:1323
#43 0x08183bbf in internal_catch (tag=-32, func=0x8120b20 <command_loop_2>, 
arg=137593113)
   at eval.c:1144
#44 0x08120933 in command_loop () at keyboard.c:1302
#45 0x081209d4 in recursive_edit_1 () at keyboard.c:995
#46 0x08120ae0 in Frecursive_edit () at keyboard.c:1056
#47 0x0811fd37 in main (argc=3, argv=0xbffff4e4) at emacs.c:1772
(gdb) xbacktrace
"process-send-string"
"byte-code"
"byte-code"
"byte-code"
"byte-code"
"nntp-retrieve-groups"
"gnus-retrieve-groups"
"gnus-read-active-file-2"
"gnus-read-active-file-1"
"gnus-read-active-file"
"gnus-group-get-new-news"
"call-interactively"
(gdb) p p->childp
No symbol "p" in current context.
(gdb) c
Continuing.
send_process (proc=148134988, buf=0x92c73f0 "LIST ACTIVE soc.culture.korean\r\n", len=32, object=152387995) at process.c:5403
5403          p->raw_status_low = Qnil;
(gdb) p p->childp
$1 = 148091981
(gdb) pr
(:name "nntpd" :buffer #<buffer  *server news.gatech.edu nntp  *nntpd**> :host 
"news.gatech.edu" :service "nntp" :remote [130 207 244 116 119] :local [192 168 1 20 51415])




reply via email to

[Prev in Thread] Current Thread [Next in Thread]