Open
Bug 1161757
Opened 9 years ago
Updated 2 years ago
Interrupting e10s Firefox with Ctrl+C triggers "###!!! ABORT: Aborting on channel error.: file ipc/glue/MessageChannel.cpp, line 1631", and "Sleeping for 300 seconds" in debug builds
Categories
(Core :: IPC, defect, P3)
Core
IPC
Tracking
()
NEW
People
(Reporter: dholbert, Unassigned)
References
Details
STR: 1. Start Firefox (debug build or opt build) from the terminal, with a fresh profile. 2. Kill it with Ctrl + C ACTUAL RESULTS: One or more copies of this scary-looking error message: { [Child 1604] ###!!! ABORT: Aborting on channel error.: file $SRC/ipc/glue/MessageChannel.cpp, line 1631 } And more importantly: if you're running a debug build, you don't get your terminal back -- you're dropped to a "Sleeping for 300 seconds / Type 'gdb ...' to attach your debugger to this thread." prompt.
Reporter | ||
Comment 1•9 years ago
|
||
EXPECTED RESULTS: - (with debug builds) I should get my terminal prompt back, instead of a "Sleeping for 300 seconds"-style abort. - (all builds) A less severe shutdown message (if any is needed at all).
Reporter | ||
Updated•9 years ago
|
tracking-e10s:
--- → ?
Reporter | ||
Updated•9 years ago
|
Summary: Interrupting e10s Firefox with Ctrl+C triggers "###!!! ABORT: Aborting on channel error.: file ipc/glue/MessageChannel.cpp, line 1631" → Interrupting e10s Firefox with Ctrl+C triggers "###!!! ABORT: Aborting on channel error.: file ipc/glue/MessageChannel.cpp, line 1631", and "Sleeping for 300 seconds" in debug builds
Reporter | ||
Comment 2•9 years ago
|
||
Historical note: looks like this abort was added in bug 778866, to prevent (plugin-related) child processes from simply being orphaned. I suppose the status quo is better than having orphaned processes :) but ideally it'd be nice to shut down these child processes more cleanly (per comment 1) after a Ctrl+C.
Are you sure you lose your terminal? If you hit enter, do you see a prompt?
Reporter | ||
Comment 4•9 years ago
|
||
Oh, you're right -- I don't actually lose my terminal. There's just a child process that's still printing to stdout (stderr?), which makes it look like I've lost my terminal.
Comment 5•9 years ago
|
||
What does "more cleanly" mean? _exit(0) would be fine as long as we can guarantee that it won't run static destructors, but that has been an issue in the past on Windows. Otherwise, an abort/crash is the cleanest way to abruptly terminate a process.
Reporter | ||
Comment 6•9 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > What does "more cleanly" mean? When I press Ctrl+C to terminate a process, I expect to see something like this: > ^C > [dholbert@cyan:~]$ (Maybe with a some lines of output before the prompt back.) Then I'm confident I can type my next command and hit enter, and all will be well. In contrast, right now, I instead see this: { ^C[Child 14688] ###!!! ABORT: Aborting on channel error.: file /scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/mozilla/ipc/glue/MessageChannel.cpp, line 1631 #01: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x118d9ef] #02: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x118f1b5] #03: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x118f1e9] #04: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x114de72] #05: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1119524] #06: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1100467] [dholbert@cyan:~]$ #07: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x10ffd0b] #08: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x10e9dd3] #09: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x10e8f4d] #10: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x11198de] #11: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1117665] #12: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1117595] #13: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x111756d] #14: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1137f87] #15: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x113834e] #16: ???[/lib/x86_64-linux-gnu/libpthread.so.0 +0x76aa] #17: clone[/lib/x86_64-linux-gnu/libc.so.6 +0x106eed] #18: ??? (???:???) [Child 14688] ###!!! ABORT: Aborting on channel error.: file /scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/mozilla/ipc/glue/MessageChannel.cpp, line 1631 Hit MOZ_CRASH() at /scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/mozilla/memory/mozalloc/mozalloc_abort.cpp:33 Program /scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/plugin-container (pid = 14688) received signal 11. Stack: #01: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x59f3779] #02: ???[/lib/x86_64-linux-gnu/libpthread.so.0 +0x10d10] #03: mozalloc_abort(char const*)[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/plugin-container +0x5b17] #04: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0xad0235] #05: NS_DebugBreak[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0xacfdc2] #06: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x118d9ef] #07: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x118f1b5] #08: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x118f1e9] #09: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x114de72] #10: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1119524] #11: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1100467] #12: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x10ffd0b] #13: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x10e9dd3] #14: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x10e8f4d] #15: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x11198de] #16: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1117665] #17: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1117595] #18: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x111756d] #19: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x1137f87] #20: ???[/scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/libxul.so +0x113834e] #21: ???[/lib/x86_64-linux-gnu/libpthread.so.0 +0x76aa] #22: clone[/lib/x86_64-linux-gnu/libc.so.6 +0x106eed] #23: ??? (???:???) Sleeping for 300 seconds. Type 'gdb /scratch/work/builds/mozilla-central/mozilla-central.13-11-22.16-03/obj/dist/bin/plugin-container 14688' to attach your debugger to this thread. } Note that there's a prompt buried in there, followed by ~20 lines of error output, but it's easy to miss. And more importantly, when I start typing my next command, it's not clear to me where the error output ends and where the command I'm about to execute begins.
Comment 7•9 years ago
|
||
C++11 explicitly specifies _Exit() to not call destructors, it looks like? _exit() should also be safe on most (I hesitate to say "all") Unix-like systems, including Linux. Also, unless the parent process waits for children to exit, there's the possibility of the children writing log messages over the next shell prompt, but it would likely not be as dramatic as in comment #6.
Updated•8 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•