Comment on attachment 8626516
bug336193.patch
Unfortunately, the last paragraph of comment 23 is still relevant.
(In reply to Kestrel from comment #39)
> * nsAppStartup::Quit calls nsIAppShell::Exit asynchronously which does most
> of the work so it doesn't block the signal handler.
It is more complicated than just not blocking the signal handler.
See man 7 signal:
"Async-signal-safe functions
A signal handler function must be very careful, since processing
elsewhere may be interrupted at some arbitrary point in the execution
of the program. POSIX has the concept of "safe function". If a
signal interrupts the execution of an unsafe function, and handler
calls an unsafe function, then the behavior of the program is
undefined."
One of the most likely problems is taking a lock, if the process is
interrupted with the lock already held. For example,
nsComponentManagerImpl::GetService() uses locks, and memory allocations
are also likely to use locks.
Also, unless the signal mask of every thread is carefully managed, the
signals may be received on any thread. Therefore any methods called
that have state would need to be thread-safe, but locks can't be used
for the reason described above.
"A process-directed signal may be delivered to any one of the threads that
does not currently have the signal blocked. If more than one of the threads
has the signal unblocked, then the kernel chooses an arbitrary thread to
which to deliver the signal."
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/73536
Title:
MASTER Firefox crashes on instant X server shutdown
To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/73536/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
