[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9943: 24.0.91; Abort in check_glyph_memory
From: |
Jan Djärv |
Subject: |
bug#9943: 24.0.91; Abort in check_glyph_memory |
Date: |
Sat, 5 Nov 2011 13:26:08 +0100 |
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.
- bug#9943: 24.0.91; Abort in check_glyph_memory, martin rudalics, 2011/11/03
- bug#9943: 24.0.91; Abort in check_glyph_memory, Eli Zaretskii, 2011/11/03
- bug#9943: 24.0.91; Abort in check_glyph_memory, Glenn Morris, 2011/11/03
- bug#9943: 24.0.91; Abort in check_glyph_memory, Ken Brown, 2011/11/03
- bug#9943: 24.0.91; Abort in check_glyph_memory, Eli Zaretskii, 2011/11/03
- bug#9943: 24.0.91; Abort in check_glyph_memory,
Jan Djärv <=
- bug#9943: 24.0.91; Abort in check_glyph_memory, Eli Zaretskii, 2011/11/05
- bug#9943: 24.0.91; Abort in check_glyph_memory, Jan Djärv, 2011/11/05
- bug#9943: 24.0.91; Abort in check_glyph_memory, Eli Zaretskii, 2011/11/05
- bug#9943: 24.0.91; Abort in check_glyph_memory, Glenn Morris, 2011/11/07
- bug#9943: 24.0.91; Abort in check_glyph_memory, Eli Zaretskii, 2011/11/03
- bug#9943: 24.0.91; Abort in check_glyph_memory, Stefan Monnier, 2011/11/03
- bug#9943: 24.0.91; Abort in check_glyph_memory, Eli Zaretskii, 2011/11/04
- bug#9943: 24.0.91; Abort in check_glyph_memory, Glenn Morris, 2011/11/04