bug#9943: 24.0.91; Abort in check_glyph_memory

[Jan Djärv]

Hello.

3 nov 2011 kl. 22:59 skrev Eli Zaretskii:

>> Date: Thu, 03 Nov 2011 17:05:45 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: Eli Zaretskii <eliz@gnu.org>, 9943@debbugs.gnu.org
>> 
>> On 11/3/2011 3:58 PM, Glenn Morris wrote:
>>> Eli Zaretskii wrote:
>>> 
>>>> I fixed this for w32 (revision 106273 on the trunk).  I think the same
>>>> problem can happen on X, but I cannot run Emacs on X where I'm typing
>>>> this.  Could someone please try the recipe on X and see if the same
>>>> problem happens there?  It could matter which toolkit was used to
>>>> build Emacs, so please tell which toolkit you are using.  TIA.
>>> 
>>> Lucid toolkit:
>> 
>> [...]
>> 
>> Eli,
>> 
>> I don't know if you need results from a second toolkit, but here's what 
>> I get with gtk:
>> 
>> (gdb) bt full
>> #0  abort () at emacs.c:386
>> No locals.
>> #1  0x00404781 in check_glyph_memory () at dispnew.c:2370
>>         tail = 8775706
>>         frame = -2147299323
>> #2  0x005149e8 in shut_down_emacs (sig=0, no_x=0, stuff=8775706)
>>     at emacs.c:2102
> 
> Thanks, I installed a fix.

I don't think it was quite correct.

In x-create-frame terminal->reference_count gets incremented before 
record_unwind_protect, but it is not decremented in case the unwind protect 
function is called.

I don't know if w32 has the same problem?

Also, in w32term.c, image_cache_refcount is assigned before init_frame_faces is 
called, but in xterm.c, this is reversed.  Indeed, turning on GLYPH_DEBUG and 
recreating this bug causes an assert violation in unwind_create_frame.

I don't know about w32, but on ns and X, accessing FRAME_IMAGE_CACHE 
(f)->refcount before calling init_frame_faces causes a segmentation violation, 
as FRAME_IMAGE_CACHE (f) is NULL.

Also, there is a typo in the comment to unwind_create_frame, x_create_top_frame 
should be ..._tip_frame.  This may have been an old thing.

I fixed these issues on X and ns (I hope :-).

> 
> nsfns.m has a similar problem, but x-create-frame there doesn't have
> an unwind-protect function to add a similar change.  Can someone test
> this recipe on a Mac?

The same bug was present there, but is fixed now.

        Jan D.