unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* core dump.
@ 2004-01-21  0:50 Han-Wen Nienhuys
  2004-01-21 21:49 ` Kevin Ryde
  0 siblings, 1 reply; 14+ 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] 14+ messages in thread

* Re: core dump.
  2004-01-21  0:50 core dump Han-Wen Nienhuys
@ 2004-01-21 21:49 ` Kevin Ryde
  2004-01-22 12:31   ` Han-Wen Nienhuys
  0 siblings, 1 reply; 14+ 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] 14+ messages in thread

* core dump.
@ 2004-01-22 11:36 Bill Schottstaedt
  2004-01-22 22:49 ` Marius Vollmer
  0 siblings, 1 reply; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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
  2004-01-28 13:52       ` uniform-vector? gives true for list Roland Orre
  1 sibling, 1 reply; 14+ 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] 14+ 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; 14+ 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] 14+ messages in thread

* uniform-vector? gives true for list
  2004-01-23 17:40     ` Neil Jerram
@ 2004-01-28 13:52       ` Roland Orre
  2004-02-06 20:19         ` Roland Orre
  2004-02-18 22:12         ` Marius Vollmer
  0 siblings, 2 replies; 14+ messages in thread
From: Roland Orre @ 2004-01-28 13:52 UTC (permalink / raw)


guile-user> (uniform-vector? '(a b c))
#t

This in both 1.6.4 and 1.7

	Best regards
	Roland Orre




_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: uniform-vector? gives true for list
  2004-01-28 13:52       ` uniform-vector? gives true for list Roland Orre
@ 2004-02-06 20:19         ` Roland Orre
  2004-02-18 22:12         ` Marius Vollmer
  1 sibling, 0 replies; 14+ messages in thread
From: Roland Orre @ 2004-02-06 20:19 UTC (permalink / raw)
  Cc: guile-devel

Maybe I should mention that this is both for 1.6.* and for 1.7
and of course for (array? ..) as well.

It would of course be consistent if
(if (array? '(a b c))
    (array-ref '(a b c) 0))
would return 'a without errors, but this is not really
what we want I guess...
	Best regards
	Roland Orre

On Wed, 2004-01-28 at 14:52, Roland Orre wrote:
> guile-user> (uniform-vector? '(a b c))
> #t
> 
> This in both 1.6.4 and 1.7
> 
> 	Best regards
> 	Roland Orre
> 



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: core dump.
  2004-01-26 11:22   ` Bill Schottstaedt
@ 2004-02-18 21:16     ` Marius Vollmer
  0 siblings, 0 replies; 14+ 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] 14+ messages in thread

* Re: uniform-vector? gives true for list
  2004-01-28 13:52       ` uniform-vector? gives true for list Roland Orre
  2004-02-06 20:19         ` Roland Orre
@ 2004-02-18 22:12         ` Marius Vollmer
  1 sibling, 0 replies; 14+ messages in thread
From: Marius Vollmer @ 2004-02-18 22:12 UTC (permalink / raw)
  Cc: bug-guile

Roland Orre <orre@nada.kth.se> writes:

> guile-user> (uniform-vector? '(a b c))
> #t

Yeahh, and 

    (uniform-vector? 'foo)
    => #t

    (uniform-vector? (expt 2 60))
    => #t

    (uniform-vector? 1.0)
    => #t

    (uniform-vector? 1+i)
    => #t

unif.c is totally botched, I'd say.  We need to redo it completely.

-- 
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] 14+ messages in thread

end of thread, other threads:[~2004-02-18 22:12 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-21  0:50 core dump 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
2004-01-28 13:52       ` uniform-vector? gives true for list Roland Orre
2004-02-06 20:19         ` Roland Orre
2004-02-18 22:12         ` Marius Vollmer
  -- strict thread matches above, loose matches on Subject: below --
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

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