PR# 14424 Early runtime crash when pressing Ctrl+C

Problem Report Summary
Submitter: manus_eiffel
Category: Runtime
Priority: Medium
Date: 2008/05/29
Class: Bug
Severity: Serious
Number: 14424
Release: 5.6
Confidential: No
Status: Open
Responsible:
Environment: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Synopsis: Early runtime crash when pressing Ctrl+C

Description
The crash is easily reproducible in gdb:

(gdb) b initsig
Breakpoint 1 at 0x9279eb0: file sig.c, line 583.
(gdb) run @info
Starting program: /home/nasadmin/semion/nas_cmd @info
[Thread debugging using libthread_db enabled]
[New Thread -1208006976 (LWP 301)]
[Switching to Thread -1208006976 (LWP 301)]

Breakpoint 1, initsig () at sig.c:583
583     sig.c: No such file or directory.
        in sig.c
(gdb) finish
Run till exit from #0  initsig () at sig.c:583
0x0914112d in main ()
(gdb) signal SIGINT
Continuing with signal SIGINT.

Program received signal SIGSEGV, Segmentation fault.
0x09291388 in extop (stk=0x9685990) at except.c:3029
3029    except.c: No such file or directory.
        in except.c
(gdb) bt
#0  0x09291388 in extop (stk=0x9685990) at except.c:3029
#1  0x0928ea36 in eraise (tag=0x31c68e "Interrupt", num=12) at
except.c:1138
#2  0x09279b6a in eiffel_signal_handler (sig=2, is_fpe=0) at sig.c:246
#3  0x09279b85 in ehandler (sig=2) at sig.c:262
#4  <signal handler called>
#5  0x0914112d in main ()
(gdb) info thr
* 1 Thread -1208006976 (LWP 301)  0x09291388 in extop (stk=0x9685990) at
except.c:3029

Thanks,
Semion
To Reproduce

										
Problem Report Interactions
From:ted_eiffel    Date:2008/09/27    Download   
Sorry. Should be:
The signal handler was *NOT* executed in last run.

From:ted_eiffel    Date:2008/09/27    Download   
The signal handler was executed in last run. This one makes more sense, since the trace is correctly printed.

bash-3.00# dbx sample
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading sample
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.2
Reading librt.so.1
Reading libpthread.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd5.so.1
(dbx) stop in initsig
dbx: warning: 'initsig' has no debugger info -- will trigger on first instruction
(2) stop in initsig
(dbx) run
Running: sample
(process id 19149)
t@1 (l@1) stopped in initsig at 0x08aae794
0x08aae794: initsig       :     pushl    %ebp
(dbx) (dbx)
(dbx) cont
^Cdbx: warning: Interrupt ignored but forwarded to child.
t@1 (l@1) signal INT (Interrupt) in F38_793 at 0x896973a
0x0896973a: F38_793+0x022a:     movl     0xfffffff4(%ebp),%eax
(dbx) cont -sig INT

sample: system execution failed.
Following is the se
....
Output truncated, Click download to get the full message

From:ted_eiffel    Date:2008/09/27    Download   
For more info, it seems fine on Solaris with dbx.

bash-3.00# dbx ./sample
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc
Reading sample
Reading ld.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.2
Reading librt.so.1
Reading libpthread.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd5.so.1
(dbx) stop in initsig
dbx: warning: 'initsig' has no debugger info -- will trigger on first instructio n
(2) stop in initsig
(dbx) run
Running: sample
(process id 18817)
t@1 (l@1) stopped in initsig at 0x08aae794
0x08aae794: initsig       :     pushl    %ebp
(dbx) where
current thread: t@1
=>[1] initsig(0x8047310, 0x80471e0, 0xd13fb840, 0x8a8002f, 0x0, 0xd1250408), at 0x8aae794
  [2] main(0x1, 0x8047224, 0x804722c), at 0x8a80073
(dbx) threads
*>    t@1  a  l@1   ?()   breakpoint       in  initsig()
(dbx) catch
INT QUIT ILL TRAP ABRT BUS SEGV SYS PIPE TERM USR1 USR2 PWR URG POLL STOP T
....
Output truncated, Click download to get the full message

From:manus_eiffel    Date:2008/09/26    Download   
Just some additional information. This bug is for Linux/Unix system. On Windows Ctrl+C has a different bug since the exception handler is created in a different thread.