bug#9943: 24.0.91; Abort in check_glyph_memory

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 5 Nov 2011 13:26:08 +0100
> Cc: Ken Brown <kbrown@cornell.edu>,
>  9943@debbugs.gnu.org
> 
> >> #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.

Thanks for double-checking it.

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

Isn't it safer (from the POV of potentially destabilizing Emacs during
a pretest) to leave the increment where it was, and decrement it in the
unwind protect function?

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

An old bug, now fixed.  Thanks.  (Looks like not many people have
GLYPH_DEBUG turned on these days.)

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

Even if it doesn't, it doesn't hurt to add the test in w32fns.c as
well.

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

Thanks.

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

Thanks.