[Top][All Lists]

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

Re: Suspicious error in GTk

From: Stefan Monnier
Subject: Re: Suspicious error in GTk
Date: Mon, 11 Jun 2007 17:16:49 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

>> While trying out SYNC_INPUT with Gtk together with the `eassert' debugging
>> I bumped into the appended backtrace, right at startup.  Basically, the code
>> run from XTread_socket (run asynchronously at any time) can call
>> update_frame_tool_bar which in turn calls xpm_load which ends up calling
>> encode_coding_string (to encode the file's name) which fiddles with
>> specpdl_ptr (via record_unwind_protect) and may run elisp code.
>> Most likely it will usually not lead to any problem, but I believe it'll
>> bite every now and then and will be difficult to trace.

AFAICT my bug report has nothing to do with alloc.c.  I even believe it's
got nothing to do with SYNC_INPUT.  I just happened to bump into it with
a SYNC_INPUT build (because all my builds use SYNC_INPUT).

> ISTR that parts of alloc.c are carried out inside BLOCK_INPUT, but
> only if SYNC_INPUT is off.

This is an optimization: if SYNC_INPUT is used, we never use malloc inside
a signal handler, so we don't need to wrap them with BLOCK_INPUT.

> Does this mean that we need BLOCK_INPUT even when SYNC_INPUT is on?

I'm not sure what "this" refers to.


reply via email to

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