Re: CVS emacs on Windows still crashes loading bongo.el

[David Kastrup <dak@gnu.org>]

dhruva <dhruvakm@gmail.com> writes:

> Hi,
>
> On Wed, May 28, 2008 at 9:51 AM, Dieter Deyke <deyke@yahoo.com> wrote:
>>> On Tue, May 27, 2008 at 9:49 PM, Dieter Deyke <ddeyke@ptc.com> wrote:
>>>> Just compiled CVS emacs on Windows XP with mingw, started it with -Q,
>>>> then executed (load-file "bongo.el"), and got the following crash:
>
>
> I have further isolated the problem to the following call:
> (font-info (face-font 'fringe))
>
> If you start emacs and evaluate the above expression TWICE (not the
> first time), you will get that crash (call to abort()) in
> font_close_object. The objlist seems to be empty and it does not enter
> the for loop. The following statement is a call to abort and hence, it
> had to enter the loop. I am currently trying to understand the data
> structures so that I can look deeper into it.

Did you compile with -fno-crossjumping?  Because if you didn't, the
traceback is likely to show the completely wrong abort call.

I have entered a bug report in the libgcc bug tracker asking to have the
"noreturn" attribute removed from abort's definition (users can probably
do that by themselves).  While "noreturn" is technically correct for
abort, the only reason to call abort instead of exit(1) or similar is to
get a core dump for post mortem debugging (or put a breakpoint on abort
for live debugging).

But the "noreturn" attribute tells gcc that it is free to clobber stack
pointer, stack state and instruction pointer since they will not be used
anymore.  Thus "noreturn" on "abort" totally defeats the one function
abort is supposed to provide: a usable post mortem state.

It sounds suspiciously like you might be currently wasting your
debugging skills on such a useless post mortem.  -fno-crossjumping makes
this less of a problem.  At least you can then expect to look in the
right place, even though the stack state might be somewhat stale.

-- 
David Kastrup