* core dump.
@ 2004-01-21 0:50 Han-Wen Nienhuys
2004-01-21 21:49 ` Kevin Ryde
0 siblings, 1 reply; 11+ messages in thread
From: Han-Wen Nienhuys @ 2004-01-21 0:50 UTC (permalink / raw)
hi,
I have a nasty coredump; this is with fairly recent CVS (ChangeLog
timestamp 26/12). Any thoughts? This is from within LilyPond. The
only funky thing was that the file was doing some operations with a
trivial GOOPS class. Any ideas?
****
elapsed time: 0.01 secondsBacktrace:
In c.ly:
2: 0* [determine-split-list #(# # # # ...) #(# # # #)]
In unknown file:
?: 1
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1074493760 (LWP 27557)]
0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
(gdb) bt
#0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
#1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x4050de58) at eval.c:2469
#2 0x4002f640 in scm_unmemocopy (x=0x404da7e0, env=0x4050de58) at eval.c:2468
#3 0x4002fadc in scm_unmemocopy (x=0x404da7d8, env=0x4050de58) at eval.c:2457
#4 0x4002f640 in scm_unmemocopy (x=0x404da778, env=0x4050de58) at eval.c:2468
#5 0x4002f640 in scm_unmemocopy (x=0x404dcad0, env=0x4050de58) at eval.c:2468
#6 0x4002f640 in scm_unmemocopy (x=0x404f4e00, env=0x4050e3f8) at eval.c:2468
#7 0x4002fa59 in scm_unmemocopy (x=0x404f4df0, env=0x4050e3f8) at eval.c:2366
#8 0x400261c0 in scm_unmemoize (m=0x167f) at debug.c:282
#9 0x40022cd7 in display_frame (frame=0x4050e408, nfield=1, indentation=1,
sport=0x40507020, port=0x402ca0f0, pstate=0x829a520) at backtrace.c:621
#10 0x40022fd1 in display_backtrace_body (a=0xbfffde00) at backtrace.c:728
#11 0x4006ea85 in scm_internal_catch (tag=0x37c,
body=0x40022d78 <display_backtrace_body>, body_data=0xbfffde00,
handler=0x400222c4 <display_error_handler>, handler_data=0xbfffddf8)
at throw.c:172
#12 0x400231bf in scm_display_backtrace (stack=0x167f, port=0x0, first=0x167f,
depth=0x167f) at backtrace.c:758
#13 0x4006ef55 in handler_message (handler_data=0x0, tag=0x824ce60,
args=0x405070e0) at throw.c:401
#14 0x4006efda in scm_handle_by_message (handler_data=0x0, tag=0x824ce60,
args=0x405070e0) at throw.c:452
#15 0x4006f234 in scm_ithrow (key=0x824ce60, args=0x405070e0, noreturn=1)
at throw.c:597
#16 0x4002c05d in scm_error (key=0x824ce60, subr=0x0, message=0x0,
args=0x40507118, rest=0x17c) at error.c:71
#17 0x4002d203 in error_unbound_variable (symbol=0x406e46f0) at eval.c:550
#18 0x4002d2e9 in scm_lookupcar1 (vloc=0x404d8308, genv=0x40507120, check=1)
at eval.c:691
#19 0x400369c1 in scm_deval (x=0x404d8308, env=0x40507120) at eval.c:3626
#20 0x400361ec in scm_deval (x=0x404da2d0, env=0x40507230) at eval.c:3936
#21 0x400362fc in scm_deval (x=0x404da2c8, env=0x40507230) at eval.c:3799
#22 0x40035389 in scm_deval (x=0x404da2b0, env=0x40507230) at eval.c:3244
#23 0x4003437c in scm_deval (x=0x404da2a8, env=0x40507230) at eval.c:2962
#24 0x4003437c in scm_deval (x=0x404dc788, env=0x404f4db8) at eval.c:2962
#25 0x40033967 in scm_i_eval (exp=0x167f, env=0x404f5090) at eval.c:5405
#26 0x40033a0a in scm_primitive_eval (exp=0x404f5270) at eval.c:5429
#27 0x080fd363 in internal_ly_parse_scm (ps=0xbfffe710) at parse-scm.cc:32
#28 0x080fd3d1 in catch_protected_parse_body (p=0xbfffe710) at parse-scm.cc:71
#29 0x4006ea85 in scm_internal_catch (tag=0x406dd1b0,
body=0x80fd3ba <catch_protected_parse_body>, body_data=0xbfffe710,
handler=0x80fd3d6 <parse_handler>, handler_data=0xbfffe710) at throw.c:172
#30 0x080fd4f1 in protected_ly_parse_scm (ps=0xbfffe710) at parse-scm.cc:108
#31 0x080fd53e in ly_parse_scm (
s=0x82f2a61 "(determine-split-list (car noticed) (cadr noticed))\n \n",
n=0xbfffe87c, i=
{defined_str0_ = 0x82f2a61 "(determine-split-list (car noticed) (cadr noticed))\n \n", source_file_ = 0x8356858}) at parse-scm.cc:127
#32 0x08175bfc in My_lily_lexer::yylex() (this=0x83558f8) at lexer.ll:294
#33 0x0817a4d5 in yylex (s=0xbffff118, v=0xbffff200) at parser.yy:230
#34 0x0817a73d in yyparse (my_lily_parser=0xbffff200) at out/parser.cc:2119
#35 0x08184857 in My_lily_parser::do_yyparse() (this=0xbffff200)
at parser.yy:2321
#36 0x080e5798 in My_lily_parser::parse_file(String, String, String) (
this=0xbffff200, init={strh_ = {data = 0x8354f50}}, in_file=
{strh_ = {data = 0x8354f68}}, out_file={strh_ = {data = 0x8354f38}})
at my-lily-parser.cc:49
#37 0x080b26a2 in Input_file_results (this=0xbffff290, init=
{strh_ = {data = 0x8354f50}}, in_file={strh_ = {data = 0x8354f68}},
out_file={strh_ = {data = 0x8354f38}}) at input-file-results.cc:142
#38 0x080b2ea9 in do_one_file (init={strh_ = {data = 0x8354f50}}, in_file=
{strh_ = {data = 0x8354f68}}, out_file={strh_ = {data = 0x8354f38}})
at input-file-results.cc:171
#39 0x080cb832 in main_prog () at main.cc:370
#40 0x40048d68 in invoke_main_func (body_data=0x167f) at init.c:600
#41 0x40048d23 in scm_boot_guile_1 (base=0xbffff43c, closure=0xbffff440)
at init.c:580
#42 0x40048a1b in scm_boot_guile (argc=5759, argv=0x167f, main_func=0x167f,
closure=0x167f) at init.c:392
#43 0x080cbff2 in main (argc=3, argv=0xbffff564) at main.cc:499
(gdb)
--
Han-Wen Nienhuys | hanwen@xs4all.nl | http://www.xs4all.nl/~hanwen
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-21 0:50 Han-Wen Nienhuys
@ 2004-01-21 21:49 ` Kevin Ryde
2004-01-22 12:31 ` Han-Wen Nienhuys
0 siblings, 1 reply; 11+ messages in thread
From: Kevin Ryde @ 2004-01-21 21:49 UTC (permalink / raw)
Cc: bug-guile
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> elapsed time: 0.01 secondsBacktrace:
> In c.ly:
> 2: 0* [determine-split-list #(# # # # ...) #(# # # #)]
> In unknown file:
> ?: 1
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1074493760 (LWP 27557)]
> 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> (gdb) bt
> #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> #1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x4050de58) at eval.c:2469
I've seen something like this when an error (an ordinary scheme level
error) occurs in code generated by a procedure->macro. Dunno if
that's what's happening here. Running without --debug normally avoids
the segv (though obviously one can't tell quite where it went wrong).
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* core dump.
@ 2004-01-22 11:36 Bill Schottstaedt
2004-01-22 22:49 ` Marius Vollmer
0 siblings, 1 reply; 11+ messages in thread
From: Bill Schottstaedt @ 2004-01-22 11:36 UTC (permalink / raw)
> 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> (gdb) bt
> #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
I've hit this so many times I've stopped using the CVS Guile -- there's
definitely a bug tickled by backtrace, but I haven't had time to try to
track it down (it's independent of GOOPS).
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-21 21:49 ` Kevin Ryde
@ 2004-01-22 12:31 ` Han-Wen Nienhuys
2004-01-22 16:20 ` Dirk Herrmann
2004-01-23 17:40 ` Neil Jerram
0 siblings, 2 replies; 11+ messages in thread
From: Han-Wen Nienhuys @ 2004-01-22 12:31 UTC (permalink / raw)
Cc: bug-guile, guile-devel
user42@zip.com.au writes:
> > [Switching to Thread 1074493760 (LWP 27557)]
> > 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> > (gdb) bt
> > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> > #1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x4050de58) at eval.c:2469
>
> I've seen something like this when an error (an ordinary scheme level
> error) occurs in code generated by a procedure->macro. Dunno if
> that's what's happening here. Running without --debug normally avoids
> the segv (though obviously one can't tell quite where it went wrong).
Yeah, I found out so far. Now I have to figure out what in my 10000
lines of Scheme code is causing
ERROR: In procedure car:
ERROR: Wrong type argument in position 1: ()
Does anyone actually know how the evaluator works?
--
Han-Wen Nienhuys | hanwen@xs4all.nl | http://www.xs4all.nl/~hanwen
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-22 12:31 ` Han-Wen Nienhuys
@ 2004-01-22 16:20 ` Dirk Herrmann
2004-01-23 17:40 ` Neil Jerram
1 sibling, 0 replies; 11+ messages in thread
From: Dirk Herrmann @ 2004-01-22 16:20 UTC (permalink / raw)
Cc: bug-guile, Kevin Ryde, guile-devel
Han-Wen Nienhuys wrote:
>user42@zip.com.au writes:
>
>
>>>[Switching to Thread 1074493760 (LWP 27557)]
>>>0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
>>>(gdb) bt
>>>#0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
>>>#1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x4050de58) at eval.c:2469
>>>
>>>
>>I've seen something like this when an error (an ordinary scheme level
>>error) occurs in code generated by a procedure->macro. Dunno if
>>that's what's happening here. Running without --debug normally avoids
>>the segv (though obviously one can't tell quite where it went wrong).
>>
>>
>
>Yeah, I found out so far. Now I have to figure out what in my 10000
>lines of Scheme code is causing
>
> ERROR: In procedure car:
> ERROR: Wrong type argument in position 1: ()
>
>Does anyone actually know how the evaluator works?
>
>
The error you describe could certainly be caused by the statement (car
'()), but this is not what you are referring to?
Best regards
Dirk
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-22 11:36 core dump Bill Schottstaedt
@ 2004-01-22 22:49 ` Marius Vollmer
2004-01-22 23:16 ` Han-Wen Nienhuys
2004-01-26 11:22 ` Bill Schottstaedt
0 siblings, 2 replies; 11+ messages in thread
From: Marius Vollmer @ 2004-01-22 22:49 UTC (permalink / raw)
Cc: bug-guile, hanwen
Bill Schottstaedt <bil@ccrma.Stanford.EDU> writes:
> > 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
> > (gdb) bt
> > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246
>
> I've hit this so many times I've stopped using the CVS Guile -- there's
> definitely a bug tickled by backtrace, but I haven't had time to try to
> track it down (it's independent of GOOPS).
Please try again, I think I have fixed it:
2004-01-22 Marius Vollmer <mvo@zagadka.de>
* eval.c (m_expand_body): Rewrite the expression in place (by
overwriting FORMS) also when a letrec is constructed, not only
when no definitions are found. Do not return rewritten expression
to emphasize the in-place rewriting. Changed all users.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-22 22:49 ` Marius Vollmer
@ 2004-01-22 23:16 ` Han-Wen Nienhuys
2004-01-22 23:26 ` Marius Vollmer
2004-01-26 11:22 ` Bill Schottstaedt
1 sibling, 1 reply; 11+ messages in thread
From: Han-Wen Nienhuys @ 2004-01-22 23:16 UTC (permalink / raw)
Cc: Bill Schottstaedt, bug-guile
mvo@zagadka.de writes:
> Please try again, I think I have fixed it:
Thanks for your quick reply.
It seems to be working. There was a stray variable in eval.c, though.
I fixed that.
BTW, how is GUILE 1.8 progressing? Have you considered switching to a
time-based release schedule, like GNOME and RedHat^H^H^H^H^H^H Fedora
do? I would really like to use rational support in LilyPond.
--
Han-Wen Nienhuys | hanwen@xs4all.nl | http://www.xs4all.nl/~hanwen
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-22 23:16 ` Han-Wen Nienhuys
@ 2004-01-22 23:26 ` Marius Vollmer
0 siblings, 0 replies; 11+ messages in thread
From: Marius Vollmer @ 2004-01-22 23:26 UTC (permalink / raw)
Cc: Bill Schottstaedt, bug-guile
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> It seems to be working. There was a stray variable in eval.c, though.
> I fixed that.
Yep, thanks.
> BTW, how is GUILE 1.8 progressing?
The two big things that need to be done are: GH replacement (including
docs of course) and finishing the thread stuff (which might not be
much, but I'm not really uptodate here.)
I'm currently working on the GH replacement; the frames stuff was the
first part.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-22 12:31 ` Han-Wen Nienhuys
2004-01-22 16:20 ` Dirk Herrmann
@ 2004-01-23 17:40 ` Neil Jerram
1 sibling, 0 replies; 11+ messages in thread
From: Neil Jerram @ 2004-01-23 17:40 UTC (permalink / raw)
Cc: bug-guile, Kevin Ryde, guile-devel
>>>>> "Han-Wen" == Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
Han-Wen> Yeah, I found out so far. Now I have to figure out what in my 10000
Han-Wen> lines of Scheme code is causing
Han-Wen> ERROR: In procedure car:
Han-Wen> ERROR: Wrong type argument in position 1: ()
Surely a backtrace would help you pinpoint the problem? Is there a
reason why you can't get a backtrace for this error?
Neil
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-22 22:49 ` Marius Vollmer
2004-01-22 23:16 ` Han-Wen Nienhuys
@ 2004-01-26 11:22 ` Bill Schottstaedt
2004-02-18 21:16 ` Marius Vollmer
1 sibling, 1 reply; 11+ messages in thread
From: Bill Schottstaedt @ 2004-01-26 11:22 UTC (permalink / raw)
Cc: bug-guile, hanwen
> Please try again, I think I have fixed it:
The backtrace problem seems to be fixed -- thanks!
In Friday's CVS guile there are two redundant declarations.
In gc.h (line 273):
SCM_API unsigned long scm_gc_cells_collected;
SCM_API unsigned long scm_gc_cells_collected;
net_db.h: SCM_API SCM scm_gethost (SCM host);
socket.h: SCM_API SCM scm_gethost (SCM name);
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: core dump.
2004-01-26 11:22 ` Bill Schottstaedt
@ 2004-02-18 21:16 ` Marius Vollmer
0 siblings, 0 replies; 11+ messages in thread
From: Marius Vollmer @ 2004-02-18 21:16 UTC (permalink / raw)
Cc: bug-guile, hanwen
Bill Schottstaedt <bil@ccrma.Stanford.EDU> writes:
> In Friday's CVS guile there are two redundant declarations.
Fixed, thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-02-18 21:16 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-22 11:36 core dump Bill Schottstaedt
2004-01-22 22:49 ` Marius Vollmer
2004-01-22 23:16 ` Han-Wen Nienhuys
2004-01-22 23:26 ` Marius Vollmer
2004-01-26 11:22 ` Bill Schottstaedt
2004-02-18 21:16 ` Marius Vollmer
-- strict thread matches above, loose matches on Subject: below --
2004-01-21 0:50 Han-Wen Nienhuys
2004-01-21 21:49 ` Kevin Ryde
2004-01-22 12:31 ` Han-Wen Nienhuys
2004-01-22 16:20 ` Dirk Herrmann
2004-01-23 17:40 ` Neil Jerram
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).