Core dumps in redisplay.

Core dumps in redisplay.

[David Kastrup]

Hello, in keyboard.c there is the following code:

DEFUN ("top-level", Ftop_level, Stop_level, 0, 0, "",
       doc: /* Exit all recursive editing levels.  */)
     ()
{
#ifdef HAVE_X_WINDOWS
  if (display_hourglass_p)
    cancel_hourglass ();
#endif

  /* Unblock input if we enter with input blocked.  This may happen if
     redisplay traps e.g. during tool-bar update with input blocked.  */
  while (INPUT_BLOCKED_P)
    UNBLOCK_INPUT;

  return Fthrow (Qtop_level, Qnil);
}

This approach of unblocking input appears completely useless to me,
since unwinding the stack includes restoration of
interrupt_input_blocked.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Richard Stallman]

      /* Unblock input if we enter with input blocked.  This may happen if
	 redisplay traps e.g. during tool-bar update with input blocked.  */
      while (INPUT_BLOCKED_P)
	UNBLOCK_INPUT;

      return Fthrow (Qtop_level, Qnil);
    }

    This approach of unblocking input appears completely useless to me,
    since unwinding the stack includes restoration of
    interrupt_input_blocked.

Probably that code was needed in the past,
before unwind_to_catch did this.  I will try deleting it.

Re: Core dumps in redisplay.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       /* Unblock input if we enter with input blocked.  This may happen if
> 	 redisplay traps e.g. during tool-bar update with input blocked.  */
>       while (INPUT_BLOCKED_P)
> 	UNBLOCK_INPUT;
>
>       return Fthrow (Qtop_level, Qnil);
>     }
>
>     This approach of unblocking input appears completely useless to me,
>     since unwinding the stack includes restoration of
>     interrupt_input_blocked.
>
> Probably that code was needed in the past,
> before unwind_to_catch did this.  I will try deleting it.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Jan D.]

> 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.

	Jan D.

Re: Core dumps in redisplay.

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> 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
TOTALLY_UNBLOCK_INPUT resets 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
multithreading.

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?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> 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
> TOTALLY_UNBLOCK_INPUT resets 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
> multithreading.
>
> 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.

Re: Core dumps in redisplay.

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>> "Jan D." <jan.h.d@swipnet.se> writes:
>>
>>> 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?
>>
>> There must only be one thread touching interrupt_input_blocked, or
>> we get into trouble.
>>
>> 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.

This sounds like normally only the main thread should ever be touching
interrupt_input_blocked, unless we have a bug.  Correct?  So we need
not think about how to synchronize accesses to the variable, but
rather make sure that no thread except the main thread will ever run
code touching it.  Correct?

A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a
bug.  Correct?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Stefan Monnier]

> 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.

If for some reason you think the problems you're experience have something
to do with interrupt_input_block, maybe you should try to recompile
with -DSYNC_INPUT.


        Stefan

Re: Core dumps in redisplay.

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> This sounds like normally only the main thread should ever be touching
> interrupt_input_blocked, unless we have a bug.  Correct?  So we need
> not think about how to synchronize accesses to the variable, but
> rather make sure that no thread except the main thread will ever run
> code touching it.  Correct?
>
> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a
> bug.  Correct?

Maybe you could compile without GTK and see if the problem persists.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Core dumps in redisplay.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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.
>
> If for some reason you think the problems you're experience have something
> to do with interrupt_input_block, maybe you should try to recompile
> with -DSYNC_INPUT.

I'd rather get a hold of what happens.  Fortunately, one can place
something like

#define BLOCK_INPUT do { __label__ zap; int i = tp++ & 255; \
  zap: tb[i].adr = &&zap; tb[i].value = ++interrupt_input_blocked; \
  while (0)

into a header file.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Jan D.]

>
> This sounds like normally only the main thread should ever be touching
> interrupt_input_blocked, unless we have a bug.  Correct?  So we need
> not think about how to synchronize accesses to the variable, but
> rather make sure that no thread except the main thread will ever run
> code touching it.  Correct?
>
> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a
> bug.  Correct?

Yes times three.

	Jan D.

Re: Core dumps in redisplay.

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>>
>> This sounds like normally only the main thread should ever be touching
>> interrupt_input_blocked, unless we have a bug.  Correct?  So we need
>> not think about how to synchronize accesses to the variable, but
>> rather make sure that no thread except the main thread will ever run
>> code touching it.  Correct?
>>
>> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a
>> bug.  Correct?
>
> Yes times three.

xmalloc uses BLOCK_INPUT.  BLOCK_INPUT is rather often used in alloc.c.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Richard Stallman]

    This sounds like normally only the main thread should ever be touching
    interrupt_input_blocked, unless we have a bug.  Correct?  So we need
    not think about how to synchronize accesses to the variable, but
    rather make sure that no thread except the main thread will ever run
    code touching it.  Correct?

That is one coherent design plan.  It may not be the only one.

Meanwhile, operations carried out in another thread are somewhat like
operations carried out in a signal handler.  So in some cases it may
be necessary for other threads to wait for interrupt_input_blocked to
be 0 before they do their work.

And unless those threads have strictly higher priority than the main
thread, we have to worry about locking: how to prevent the main thread
from continuing and entering code that does BLOCK_INPUT while the
other thread is doing something that's supposed to be blocked by
BLOCK_INPUT.

Re: Core dumps in redisplay.

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>>
>> This sounds like normally only the main thread should ever be touching
>> interrupt_input_blocked, unless we have a bug.  Correct?  So we need
>> not think about how to synchronize accesses to the variable, but
>> rather make sure that no thread except the main thread will ever run
>> code touching it.  Correct?
>>
>> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a
>> bug.  Correct?
>
> Yes times three.

I have got the debugging working.  Clearly xmalloc is called in a
separate thread (its BLOCK/UNBLOCK calls which are placed just round
malloc are interspersed with that of other routines), and its
deallocation interferes with the deallocation from the main thread.
So we should probably add an xassert into BLOCK_INPUT and
UNBLOCK_INPUT that complains when we are in anything but the main
thread.  And then see whether we can get rid of all the resulting
aborts in a sane manner.

If we don't do this, I am afraid that we will be plagued with
occasional unreproduceable aborts and/or problems.

I also doubt that it is a good idea to have mallocs in parallel
threads at the same time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>>
>>> This sounds like normally only the main thread should ever be 
>>> touching
>>> interrupt_input_blocked, unless we have a bug.  Correct?  So we need
>>> not think about how to synchronize accesses to the variable, but
>>> rather make sure that no thread except the main thread will ever run
>>> code touching it.  Correct?
>>>
>>> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a
>>> bug.  Correct?
>>
>> Yes times three.
>
> xmalloc uses BLOCK_INPUT.  BLOCK_INPUT is rather often used in alloc.c.

Yes, there is a check for main thread there also, see macros 
(UN)BLOCK_INPUT_ALLOC.

	Jan D.

Re: Core dumps in redisplay.

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>> "Jan D." <jan.h.d@swipnet.se> writes:
>>
>>>>
>>>> This sounds like normally only the main thread should ever be
>>>> touching
>>>> interrupt_input_blocked, unless we have a bug.  Correct?  So we need
>>>> not think about how to synchronize accesses to the variable, but
>>>> rather make sure that no thread except the main thread will ever run
>>>> code touching it.  Correct?
>>>>
>>>> A use of BLOCK_INPUT or UNBLOCK_INPUT outside of the main thread is a
>>>> bug.  Correct?
>>>
>>> Yes times three.
>>
>> xmalloc uses BLOCK_INPUT.  BLOCK_INPUT is rather often used in alloc.c.
>
> Yes, there is a check for main thread there also, see macros
> (UN)BLOCK_INPUT_ALLOC.

This is a bad joke, right?  BLOCK_INPUT_ALLOC makes sure that it uses
BLOCK_INPUT only in the main thread, using a semaphore elsewhere.  So
far, so nice.  And BLOCK_INPUT_ALLOC hooks into malloc, free and
realloc.

But xmalloc and all related routines use BLOCK_INPUT nevertheless.  So
it is obvious that although malloc seemingly can be used (given _BOTH_
PTHREAD and GTK) without problems, all uses of xmalloc still are
flawed in the old way.

So we still can't allow using xmalloc except in the main thread.  What
is the design?  Should xmalloc be usable outside of the main thread or
not?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Jan D.]

> But xmalloc and all related routines use BLOCK_INPUT nevertheless.  So
> it is obvious that although malloc seemingly can be used (given _BOTH_
> PTHREAD and GTK) without problems, all uses of xmalloc still are
> flawed in the old way.
>
> So we still can't allow using xmalloc except in the main thread.  What
> is the design?  Should xmalloc be usable outside of the main thread or
> not?

The Gnome file backend does not know about or use xmalloc and friends, 
so only the main thread calls it.  Note, the threading checks are there 
for the purpose of the Gnome file chooser backend only, it is not a 
general thread safe solution.

	Jan D.

Re: Core dumps in redisplay.

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>> But xmalloc and all related routines use BLOCK_INPUT nevertheless.  So
>> it is obvious that although malloc seemingly can be used (given _BOTH_
>> PTHREAD and GTK) without problems, all uses of xmalloc still are
>> flawed in the old way.
>>
>> So we still can't allow using xmalloc except in the main thread.  What
>> is the design?  Should xmalloc be usable outside of the main thread or
>> not?
>
> The Gnome file backend does not know about or use xmalloc and friends,
> so only the main thread calls it.

You wish.  I am putting appropriate assertions in right now and expect
to report otherwise soon (the trace output is rather clear-spoken
about this).  I want to have this out of the way before I make an
Emacs/AUCTeX/preview-latex representation at a major GNU/Linux
conference Saturday and a workshop at a major TeX conference next week
without having the demos crash.  That's simply uncool.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>> But xmalloc and all related routines use BLOCK_INPUT nevertheless.  
>>> So
>>> it is obvious that although malloc seemingly can be used (given 
>>> _BOTH_
>>> PTHREAD and GTK) without problems, all uses of xmalloc still are
>>> flawed in the old way.
>>>
>>> So we still can't allow using xmalloc except in the main thread.  
>>> What
>>> is the design?  Should xmalloc be usable outside of the main thread 
>>> or
>>> not?
>>
>> The Gnome file backend does not know about or use xmalloc and friends,
>> so only the main thread calls it.
>
> You wish.

No. I know.  The only way the other threads can call xmalloc is if a 
signal handler is called in a non-main thread and then calls xmalloc.  
This should not happen, but if it does there is a bug somewhere.
>

> I am putting appropriate assertions in right now and expect
> to report otherwise soon (the trace output is rather clear-spoken
> about this).  I want to have this out of the way before I make an
> Emacs/AUCTeX/preview-latex representation at a major GNU/Linux
> conference Saturday and a workshop at a major TeX conference next week
> without having the demos crash.  That's simply uncool.


Please insert the thread id in the trace output, otherwise you can't 
know if it is another thread or a signal handler that calls xmalloc.

	Jan D.

Re: Core dumps in redisplay.

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

>> You wish.
>
> No. I know.  The only way the other threads can call xmalloc is if a
> signal handler is called in a non-main thread and then calls xmalloc.
> This should not happen, but if it does there is a bug somewhere.
>>
>
>> I am putting appropriate assertions in right now and expect to
>> report otherwise soon (the trace output is rather clear-spoken
>> about this).  I want to have this out of the way before I make an
>> Emacs/AUCTeX/preview-latex representation at a major GNU/Linux
>> conference Saturday and a workshop at a major TeX conference next
>> week without having the demos crash.  That's simply uncool.
>
>
> Please insert the thread id in the trace output, otherwise you can't
> know if it is another thread or a signal handler that calls xmalloc.

Apparently a signal handler.  I'd have an assertion get thrown if it
were another thread.  But I get my aborts not on the comparisons of
the thread id.

Ok, what is the beef with signal handlers?  Are they supposed to ever
throw a longjmp, whether in the course of Lisp exceptions or not?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Core dumps in redisplay.

[Jan D.]

2005-02-28 kl. 15.49 skrev Richard Stallman:

>     This sounds like normally only the main thread should ever be 
> touching
>     interrupt_input_blocked, unless we have a bug.  Correct?  So we 
> need
>     not think about how to synchronize accesses to the variable, but
>     rather make sure that no thread except the main thread will ever 
> run
>     code touching it.  Correct?
>
> That is one coherent design plan.  It may not be the only one.
>
> Meanwhile, operations carried out in another thread are somewhat like
> operations carried out in a signal handler.  So in some cases it may
> be necessary for other threads to wait for interrupt_input_blocked to
> be 0 before they do their work.

I think this is only needed if the other threads will be executing 
Emacs code.  For the case at hand (the Gnome file chooser backend), 
this is the case only for malloc and friends because Emacs inserts it 
hooks for malloc etc.

>
> And unless those threads have strictly higher priority than the main
> thread, we have to worry about locking: how to prevent the main thread
> from continuing and entering code that does BLOCK_INPUT while the
> other thread is doing something that's supposed to be blocked by
> BLOCK_INPUT.

Signal handling with multiple threads is not portable and very tricky.  
If we could minimize the work done in signal handlers, preferrably just 
setting a variable or two, thing would be simpler.

But a mutex lock/unlock in BLOCK/UNBLOCK_INPUT is the obvious initial 
approach.

	Jan D.