[Top][All Lists]

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

Re: Re[2]: Speedbar segv

From: Eli Zaretskii
Subject: Re: Re[2]: Speedbar segv
Date: Mon, 14 May 2001 14:27:42 +0300 (IDT)

On 14 May 2001, Gerd Moellmann wrote:

> Judging from the backtrace, the abort is caused by UNBLOCK_INPUT
> finding that the interrupt_input_blocked counter became negative which
> could indicate that there's some path through the code where an
> UNBLOCK_INPUT is done without a matching BLOCK_INPUT.  That on the
> other hand is impossible in this case, since realize_basic_faces has a
> matching BLOCK_INPUT.  If interrupt_input_blocked becomes negative in
> the UNBLOCK_INPUT matching that BLOCK_INPUT it already was negative
> before the BLOCK_INPUT, and there seems to be no way how that can
> happen (there's no place in sight where interrupt_input_blocked is set
> directly to a negative value, for instance).  
> Very strange; a wild pointer maybe?
> Can you reproduce this at will?  If so, could you please set a 
> breakpoint on realize_basic_faces, and step through the code, 
> displaying the value of interrupt_input_blocked at each step?

If GDB on Eric's machine supports hardware watchpoints, a more efficient 
way might be setting a watchpoint on interrupt_input_blocked and looking 
at all the places which block and unblock input.

reply via email to

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