* CVS emacs on Windows still crashes loading bongo.el
@ 2008-05-27 16:19 Dieter Deyke
2008-05-28 3:58 ` dhruva
0 siblings, 1 reply; 8+ messages in thread
From: Dieter Deyke @ 2008-05-27 16:19 UTC (permalink / raw
To: emacs-devel
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CVS emacs on Windows still crashes loading bongo.el
2008-05-27 16:19 CVS emacs on Windows still crashes loading bongo.el Dieter Deyke
@ 2008-05-28 3:58 ` dhruva
[not found] ` <wkk5hfkqin.fsf@yahoo.com>
0 siblings, 1 reply; 8+ messages in thread
From: dhruva @ 2008-05-28 3:58 UTC (permalink / raw
To: Dieter Deyke; +Cc: emacs-devel
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CVS emacs on Windows still crashes loading bongo.el
[not found] ` <wkk5hfkqin.fsf@yahoo.com>
@ 2008-05-28 11:49 ` dhruva
2008-05-28 12:00 ` David Kastrup
2008-05-28 12:23 ` Kenichi Handa
0 siblings, 2 replies; 8+ messages in thread
From: dhruva @ 2008-05-28 11:49 UTC (permalink / raw
To: Dieter Deyke; +Cc: Dieter Deyke, emacs-devel
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CVS emacs on Windows still crashes loading bongo.el
2008-05-28 11:49 ` dhruva
@ 2008-05-28 12:00 ` David Kastrup
2008-05-28 12:24 ` dhruva
2008-05-28 15:56 ` Jason Rumney
2008-05-28 12:23 ` Kenichi Handa
1 sibling, 2 replies; 8+ messages in thread
From: David Kastrup @ 2008-05-28 12:00 UTC (permalink / raw
To: dhruva; +Cc: Dieter Deyke, Dieter Deyke, emacs-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CVS emacs on Windows still crashes loading bongo.el
2008-05-28 11:49 ` dhruva
2008-05-28 12:00 ` David Kastrup
@ 2008-05-28 12:23 ` Kenichi Handa
1 sibling, 0 replies; 8+ messages in thread
From: Kenichi Handa @ 2008-05-28 12:23 UTC (permalink / raw
To: dhruva; +Cc: deyke, ddeyke, emacs-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CVS emacs on Windows still crashes loading bongo.el
2008-05-28 12:00 ` David Kastrup
@ 2008-05-28 12:24 ` dhruva
2008-05-28 15:56 ` Jason Rumney
1 sibling, 0 replies; 8+ messages in thread
From: dhruva @ 2008-05-28 12:24 UTC (permalink / raw
To: David Kastrup; +Cc: Dieter Deyke, Dieter Deyke, emacs-devel
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!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CVS emacs on Windows still crashes loading bongo.el
2008-05-28 12:00 ` David Kastrup
2008-05-28 12:24 ` dhruva
@ 2008-05-28 15:56 ` Jason Rumney
2008-05-28 16:09 ` David Kastrup
1 sibling, 1 reply; 8+ messages in thread
From: Jason Rumney @ 2008-05-28 15:56 UTC (permalink / raw
To: David Kastrup; +Cc: Dieter Deyke, Dieter Deyke, emacs-devel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CVS emacs on Windows still crashes loading bongo.el
2008-05-28 15:56 ` Jason Rumney
@ 2008-05-28 16:09 ` David Kastrup
0 siblings, 0 replies; 8+ messages in thread
From: David Kastrup @ 2008-05-28 16:09 UTC (permalink / raw
To: Jason Rumney; +Cc: Dieter Deyke, Dieter Deyke, emacs-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-05-28 16:09 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-27 16:19 CVS emacs on Windows still crashes loading bongo.el Dieter Deyke
2008-05-28 3:58 ` dhruva
[not found] ` <wkk5hfkqin.fsf@yahoo.com>
2008-05-28 11:49 ` dhruva
2008-05-28 12:00 ` David Kastrup
2008-05-28 12:24 ` dhruva
2008-05-28 15:56 ` Jason Rumney
2008-05-28 16:09 ` David Kastrup
2008-05-28 12:23 ` Kenichi Handa
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).