CVS emacs on Windows still crashes loading bongo.el

CVS emacs on Windows still crashes loading bongo.el

[Dieter Deyke]

Just compiled CVS emacs on Windows XP with mingw, started it with -Q,
then executed (load-file "bongo.el"), and got the following crash:

Breakpoint 1, w32_abort () at w32fns.c:9417
9417	  button = MessageBox (NULL,
(gdb) bt all

Lisp Backtrace:
"font-info" (0x82e4e0)
"or" (0x82e5a4)
"aref" (0x82e624)
"catch" (0x82e754)
"bongo-face-height" (0x82e7d0)
"or" (0x82e904)
">=" (0x82e984)
"if" (0x82ea14)
"if" (0x82eaa4)
"bongo-fringe-icon-size" (0x82eb20)
"let" (0x82ec84)
"case" (0x82ed04)
"ecase" (0x82ed84)
"put" (0x82ee04)
"eval-buffer" (0x82ef54)
"load-with-code-conversion" (0x82f098)
"load" (0x82f644)
"load-file" (0x82f7b4)
"call-interactively" (0x82f95c)
"execute-extended-command" (0x82fae4)
"call-interactively" (0x82fc9c)

where showed:

#0  w32_abort () at w32fns.c:9417
#1  0x011182be in font_close_object (f=0x1e04200, font_object=28872708)
    at font.c:2628
#2  0x01123bb0 in Ffont_info (name=33313891, frame=24004609) at fontset.c:1681
#3  0x0101437b in Feval (form=38584397) at eval.c:2371
#4  0x01016c96 in For (args=38583253) at eval.c:345
#5  0x01014440 in Feval (form=38584405) at eval.c:2315
#6  0x0101420e in Feval (form=38584413) at eval.c:2353
#7  0x010145f4 in Fprogn (args=38583181) at eval.c:449
#8  0x01013863 in internal_catch (tag=39239897, func=0x10145cb <Fprogn>,
    arg=38583181) at eval.c:1242
#9  0x01014491 in Fcatch (args=38584421) at eval.c:1210
#10 0x01014440 in Feval (form=38584445) at eval.c:2315
#11 0x010145f4 in Fprogn (args=38584453) at eval.c:449
#12 0x01014861 in funcall_lambda (fun=38583160, nargs=1, arg_vector=0x82e7d0)
    at eval.c:3217
#13 0x0101497b in apply_lambda (fun=38583165, args=38710709, eval_flag=1)
    at eval.c:3148
#14 0x01014098 in Feval (form=38710733) at eval.c:2428
#15 0x01016c96 in For (args=38710701) at eval.c:345
#16 0x01014440 in Feval (form=38710741) at eval.c:2315
#17 0x0101420e in Feval (form=38710749) at eval.c:2353
#18 0x01016bd2 in Fif (args=38710669) at eval.c:393
#19 0x01014440 in Feval (form=38710757) at eval.c:2315
#20 0x010145f4 in Fprogn (args=38710645) at eval.c:449
#21 0x01014440 in Feval (form=38710797) at eval.c:2315
#22 0x010145f4 in Fprogn (args=38710805) at eval.c:449
#23 0x01014861 in funcall_lambda (fun=38710624, nargs=0, arg_vector=0x82eb20)
    at eval.c:3217
#24 0x0101497b in apply_lambda (fun=38710629, args=24004609, eval_flag=1)
    at eval.c:3148
#25 0x01014098 in Feval (form=28081493) at eval.c:2428
#26 0x0101690a in Flet (args=28081917) at eval.c:1068
#27 0x01014440 in Feval (form=28081925) at eval.c:2315
#28 0x010141ea in Feval (form=28081637) at eval.c:2426
#29 0x010141ea in Feval (form=28081485) at eval.c:2426
#30 0x0101420e in Feval (form=28081429) at eval.c:2353
#31 0x0107649b in readevalloop (readcharfun=26029572, stream=0x0,
    sourcename=33432515, evalfun=0x1013eb9 <Feval>, printflag=0,
    unibyte=24004609, readfun=24004609, start=24004609, end=24004609)
    at lread.c:1789
#32 0x01076adb in Feval_buffer (buffer=26029572, printflag=24004609,
    filename=33433107, unibyte=24004609, do_allow_print=24004657)
    at lread.c:1852
#33 0x01014d6b in Ffuncall (nargs=6, args=0x82ef50) at eval.c:3051
#34 0x010d63ea in Fbyte_code (bytestr=18348403, vector=18348420, maxdepth=48)
    at bytecode.c:678
#35 0x0101478c in funcall_lambda (fun=18348332, nargs=4, arg_vector=0x82f098)
    at eval.c:3224
#36 0x01014b73 in Ffuncall (nargs=5, args=0x82f094) at eval.c:3094
#37 0x01014f47 in call4 (fn=24367273, arg1=33433107, arg2=33433107,
    arg3=24004609, arg4=24004609) at eval.c:2887
#38 0x010778fc in Fload (file=33433251, noerror=24004609, nomessage=24004609,
    nosuffix=24004657, must_suffix=24004609) at lread.c:1206
#39 0x01014d6b in Ffuncall (nargs=5, args=0x82f640) at eval.c:3051
#40 0x010d63ea in Fbyte_code (bytestr=18405979, vector=18405996, maxdepth=40)
    at bytecode.c:678
#41 0x0101478c in funcall_lambda (fun=18405940, nargs=1, arg_vector=0x82f7b4)
    at eval.c:3224
#42 0x01014b73 in Ffuncall (nargs=2, args=0x82f7b0) at eval.c:3094
#43 0x01016410 in Fapply (nargs=2, args=0x82f7b0) at eval.c:2470
#44 0x01016456 in apply1 (fn=33054745, arg=38705837) at eval.c:2786
#45 0x010d7c1a in Fcall_interactively (function=33054745,
    record_flag=24004657, keys=24038148) at callint.c:389
#46 0x01014db2 in Ffuncall (nargs=4, args=0x82f958) at eval.c:3043
#47 0x01014f7a in call3 (fn=24198033, arg1=33054745, arg2=24004657,
    arg3=24004609) at eval.c:2863
#48 0x01062f55 in Fexecute_extended_command (prefixarg=24004609)
    at keyboard.c:10547
#49 0x01014ddd in Ffuncall (nargs=2, args=0x82fae0) at eval.c:3037
#50 0x010d8f0c in Fcall_interactively (function=24064577,
    record_flag=24004609, keys=24038148) at callint.c:857
#51 0x01014db2 in Ffuncall (nargs=4, args=0x82fc98) at eval.c:3043
#52 0x01014f7a in call3 (fn=24198033, arg1=24064577, arg2=24004609,
    arg3=24004609) at eval.c:2863
#53 0x0106de55 in command_loop_1 () at keyboard.c:1910
#54 0x010137c8 in internal_condition_case (bfun=0x106db08 <command_loop_1>,
    handlers=24068289, hfun=0x106818e <cmd_error>) at eval.c:1506
#55 0x01067616 in command_loop_2 () at keyboard.c:1367
#56 0x01013863 in internal_catch (tag=24064361,
    func=0x10675f3 <command_loop_2>, arg=24004609) at eval.c:1242
#57 0x01067ffd in command_loop () at keyboard.c:1346
#58 0x01068319 in recursive_edit_1 () at keyboard.c:955
#59 0x01068435 in Frecursive_edit () at keyboard.c:1017
#60 0x01002a05 in main (argc=8585136, argv=0xa42d20) at emacs.c:1770

Any help?
--
Dieter Deyke

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

[dhruva]

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:

Where do I get "bongo.el". I can try the same on the MSVC build I am using.

-dky

-- 
Contents reflect my personal views only!

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

[dhruva]

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.

-dky

-- 
Contents reflect my personal views only!

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

[David Kastrup]

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

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

[Kenichi Handa]

In article <e3f230850805280449g12f58806n33453b9010aefbaa@mail.gmail.com>, dhruva <dhruvakm@gmail.com> writes:

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

Thank you for finding this bug.  I've just installed a fix.
Even if Ffont_info opens a font, it should not close the
font because it's still kept in OBJLIST of font-entity, and
may be used by some other place.

BTW, it seems that the current code has a bug in releasing a
font-object.  I'll investigate it.

---
Kenichi Handa
handa@ni.aist.go.jp

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

[dhruva]

Hello,

On Wed, May 28, 2008 at 5:30 PM, David Kastrup <dak@gnu.org> wrote:
> Did you compile with -fno-crossjumping?  Because if you didn't, the

No, I have not, I will do it right away.

> It sounds suspiciously like you might be currently wasting your

Thank you very much for the details information, I did get to learn a lot.

with best regards,
dhruva

-- 
Contents reflect my personal views only!

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

[Jason Rumney]

David Kastrup wrote:
> I have entered a bug report in the libgcc bug tracker asking to have the
> "noreturn" attribute removed from abort's definition

I don't think this is the full solution, as there are similar problems 
debugging any inline function with cross-jumping enabled - the inline 
function gets inlined into one function that uses it, and other uses 
often jump into the same inlined instance, so the instruction pointer 
points inside a function that has nothing to do with the call stack.

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

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> I have entered a bug report in the libgcc bug tracker asking to have the
>> "noreturn" attribute removed from abort's definition
>
> I don't think this is the full solution, as there are similar problems
> debugging any inline function with cross-jumping enabled - the inline
> function gets inlined into one function that uses it, and other uses
> often jump into the same inlined instance, so the instruction pointer
> points inside a function that has nothing to do with the call stack.

That's only a problem when the function (inline or not) is at the
ultimate end of the function and all the register usage and stack frame
cleanup is identical.  That's not so very common.  Note that for
"noreturn" functions (inline or not), the stack frame cleanup is
disregarded, and we are by definition at "the ultimate end".  So what is
a rare occurence in other circumstances becomes pretty much the
default.

I don't see that inlining functions would make cross-jumping more of a
problem.  Actually, it would seem to me that inlining would make
crossjumping _less_ likely since the call arguments are not placed into
a standardized stack frame, but are substituted into the inline function
depending on where it is used.  So there should be less chance of code
recycling rather than more.

-- 
David Kastrup