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

NEW
Unassigned

Status

()

Core
IPC
P3
normal
3 years ago
3 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(e10s+, firefox40 affected)

Details

(Reporter)

Description

3 years ago
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

3 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

3 years ago
tracking-e10s: --- → ?
(Reporter)

Updated

3 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

3 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.
(Reporter)

Updated

3 years ago
Depends on: 778866
Are you sure you lose your terminal? If you hit enter, do you see a prompt?
(Reporter)

Comment 4

3 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

3 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

3 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.
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.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.