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