emacs-devel
[Top][All Lists]
Advanced

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




reply via email to

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