[Top][All Lists]

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

Re: Core dumps in redisplay.

From: Jan D.
Subject: Re: Core dumps in redisplay.
Date: Sun, 27 Feb 2005 21:35:13 +0100

"Jan D." <address@hidden> writes:

Also with regard to the other report you answered (where I was wrong): I might well be mistaken. I am just trying to get a hold of why Emacs
keeps crashing on me.  It appears, anyway, that something seriously
elusive is going on here.  I'll probably have to implement some kind
of trace buffering for interrupt_input_block in order to get a hold of
what is happening here.

I already disassembled stuff because I thought the compiler might be
at fault.  Maybe I should also try without optimization.

If you configured with GTK, there is a possibility that multiple
threads are updating interrupt_input_block.  I've tried to handle that
situation, but bugs may of course still remain.

How did you try to handle it?  Basically, we have the following
accesses to interrupt_input_blocked:

BLOCK_INPUT increases it
UNBLOCK_INPUT decreases it
throws reset it to the state at the time of the catch

The last two options would behave really badly in the presence of

There must only be one thread touching interrupt_input_blocked, or we
get into trouble.  I don't see that we can sensibly handle the case
"reset to state at the time of the catch" in any manner with two
threads accessing the variable.  We need one variable per thread then,
and the input is blocked if either variable is nonzero.  Only a
per-thread variable can be reset to a meaningful value.

Could you elaborate on what happens here in parallel threads?  I can't
imagine that one can execute Lisp sanely in two threads, so one thread
would be likely C-only?  Why would that thread have to meddle with
interrupt_input_blocked at all?

The GTK file dialog can load different backends (Gnome has one) that may add or alter the behaviour of the file dialog. The Gnome backend creates several threads (the default GTK backend does not). This is not a problem, except when a signal (i.e. real Unix signal) is caught by Emacs. The signal may be caught by one of the Gnome threads and it would then execute the X event loop. This situation leads to two threads accessing variables and a crash usually occurs (perhaps a bit later).

The fix is basically to keep track of what thread id the Emacs main thread has, and if a signal handler is called by another thread id, the signal is delivered to the main thread and nothing more is done in the signal handler.

The goal is to get only the main thread to execute "Emacs" code, and keep the Gnome threads from interferring.

        Jan D.

reply via email to

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