[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[2]: Speedbar segv
From: |
Gerd Moellmann |
Subject: |
Re: Re[2]: Speedbar segv |
Date: |
14 May 2001 12:41:21 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104 |
"Eric M. Ludlam" <address@hidden> writes:
> >> emacs -q
> >> ;; In your *scratch* buffer, eval these
> >> (add-to-list 'load-path "~/eieio-0.16")
> >> (add-to-list 'load-path "~/ede-1.0.beta2")
> >> ;; End
> >> M-x load-library RET ede RET
> >
> >
> >Eric, I'm afraid I don't get further than this. Loading `ede'
> >gives a ``speedbar-message: Wrong type argument: framep, nil''.
> >Likewise when I try to compile the files in EDE-1.0.beta2 with
> >the Makefile there.
>
> Yes, that error is ok. It happens after all the important EDE
> functions which cause the segv are loaded in. It is OK to continue
> with the above directions after this error which is what I did when
> trying to find the minimum set of things to download. If you do want
> to fix this to continue, you can get speedbar 0.14 beta1 which has the
> appropriate fixes in it, or you can remove the last few lines after
> the (provide 'ede) in ede.el which throws the error, and is not deeded
> to reproduce the bug.
When I ignore the error and proceed, the Speedbar frame comes up
normally, here. Hm, that's no good.
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?