GNU bug report logs - #19660
24.4.51; Crash in draw_row_fringe_bitmaps

Previous Next

Full log

Message #28 received at 19660 <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19660 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#19660: Acknowledgement (24.4.51;
 Crash in draw_row_fringe_bitmaps)
Date: Tue, 27 Jan 2015 10:16:48 +0100

Eli Zaretskii skrev den 2015-01-26 10:31:
>> Date: Mon, 26 Jan 2015 10:12:35 +0100
>> From: "Jan D." <jan.h.d <at> swipnet.se>
>> CC: 19660 <at> debbugs.gnu.org, "Kim F. Storm" <storm <at> cua.dk>
>>
>>> If no other information emerges, my suggestion would be to remove the
>>> assertion on master, and see if we get any bug reports.
>>
>> No need for that, the NS version crashes later on if I remove that
>> assert.
>
> Where does it crash, and why?  Another similar assertion or something
> else?

Entering the GUI event loop, while in the event loop already.  There is 
an assertion for that on NS.

>
>> Better block input too much than to seldom I guess.
>
> Right.  But understanding why this happens is better yet ;-)
>
> Seriously: I thought we aren't supposed to be hit by this stuff, since
> we now never run code out of an interrupt handler.  I guess I missed
> something important.

I suspect doing unblock_input can enter the GUI event loop 
unconditionally if there is input pending.  This might be wrong in some 
situations.  Do we actually need block/unblock_input anymore?

>
>> Unfortunately I managed to loose my .desktop that consistently triggered
>> the error, so I can't investigate further.
>
> Don't you have a backup of that somewhere?
>

Yes, but it does not crash anymore.  It was probably timing related also 
as GUI events seems to be involved.

	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.