[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: gnetlist ERROR: Stack overflow
(eval-options (list 'stack 200000))
did not prevent the error. However,
(debug-options (list 'stack 200000))
did fix the problem when I added it to the beginning of the .scm backend file.
Since there seems to be two stack limits (eval which defaults to 22000 machine
words and debug which defaults to 20000 machine words), I've added the following
two lines to my copy of gnet-pads.scm:
(debug-options (list 'stack 200000))
(eval-options (list 'stack 220000))
I no longer get the stack overflow error with the example schematic that I sent to
the list on Saturday. So we probably should add those lines to the beginning of
backends that had a problem with that schematic.
The example schematic that I sent was simplified from the original (proprietary)
schematic that I started having problems with. My original schematic causes
gnetlist to core dump with or without those lines added. However, a simple change
to that original schematic prevents the core dump and now successfully generates a
netlist with the guile stack limits increased. Thanks to everyone who helped track
this problem down!
I am now up and running with the simple work-around to my schematic, but I thought
somebody might be interested in the details of the core dump. The core is 63Meg
(about 7 Meg compressed) so I'm not going to send it to the mailing list. I will
send the backtrace from the core dump and a description of what I did to prevent
the crash.
Because I wanted to leave the option open to isolate grounds on three parts of the
board, I defined two extra ground symbols and nets, DGND and RFGND (in addition to
the default GND). I attached them all to one mounting hole, because for now, I
don't think I need isolated grounds. In this configuration, gnetlist crashes. If
I edit the DGND and RFGND symbols and change the nets from DGND and RFGND to just
GND, gnetlist no longer crashes. So I have the netlist that I need, but I'm afraid
there is a latent bug in gnetlist.?
If I have time, I will try to make a non-proprietary schematic that causes the core
dump. For now, all I can provide is the debugger backtrace, which is below.
Thanks again for all of the feedback.
Cheers...
Dave
#0 scm_gc_mark (p=196947160) at gc.c:928
928 gc.c: No such file or directory.
(gdb) bt
#0 scm_gc_mark (p=196947160) at gc.c:928
#1 0x400a006f in scm_gc_mark (p=1076204384) at gc.c:1046
#2 0x400a01cd in scm_gc_mark (p=1076341656) at gc.c:1030
#3 0x400a006f in scm_gc_mark (p=1076187184) at gc.c:1046
#4 0x400a03bc in scm_mark_locations (x=0xbfffd4d4, n=846) at gc.c:1265
#5 0x4009faf9 in scm_igc (what=0x400ea174 "scm_makstr") at gc.c:861
#6 0x400a0dff in scm_must_malloc (size=6, what=0x400ea174 "scm_makstr")
at gc.c:1694
#7 0x400c62ef in scm_makstr (len=5, slots=0) at strings.c:127
#8 0x400c64c5 in scm_makfromstr (src=0x8846a10 "D6AL2", len=5, slots=0)
at strings.c:190
#9 0x400a2461 in gh_str2scm (s=0x8846a10 "D6AL2", len=5) at gh_data.c:96
#10 0x804a629 in g_get_all_unique_nets (scm_level=1076334352)
at g_netlist.c:242
#11 0x40094b44 in scm_ceval (x=10612, env=1076334328) at eval.c:2749
#12 0x4009123b in scm_eval_car (pair=1076334336, env=1076334328) at eval.c:436
#13 0x40092077 in scm_m_define (x=1076334336, env=1076334328) at eval.c:883
#14 0x400973be in scm_apply (proc=1076223032, arg1=1076334400, args=1076334320)
at eval.c:3356
#15 0x40096be6 in scm_ceval (x=1076334400, env=1076334328) at eval.c:2551
#16 0x40098062 in scm_eval_3 (obj=1076334400, copyp=0, env=1076334328)
at eval.c:3833
#17 0x40098138 in scm_eval_x (obj=1076334400) at eval.c:3866
#18 0x40021fb2 in load (data=0x4026f5f8) at ../noweb/g_basic.nw:101
#19 0x400cc376 in scm_internal_catch (tag=9076, body=0x40021f70 <load>,
body_data=0x4026f5f8, handler=0x40021fe0 <load_error_handler>,
handler_data=0x4026f5f8) at throw.c:207
#20 0x400a3deb in gh_catch (tag=9076, body=0x40021f70 <load>,
body_data=0x4026f5f8, handler=0x40021fe0 <load_error_handler>,
handler_data=0x4026f5f8) at gh_init.c:93
#21 0x400221e3 in g_read_file (
filename=0xbfffd910 "/apps/gnu/geda/share/gEDA/scheme/gnetlist.scm")
---Type <return> to continue, or q <return> to quit---
at ../noweb/g_basic.nw:188
#22 0x804c5d8 in main_prog (argc=7, argv=0xbfffe2dc) at gnetlist.c:181
#23 0x400a3d3d in gh_launch_pad (closure=0x804c3d0, argc=7, argv=0xbfffe2dc)
at gh_init.c:60
#24 0x400a7739 in invoke_main_func (body_data=0xbfffe210) at init.c:625
#25 0x400cc4c2 in scm_internal_lazy_catch (tag=9076,
body=0x400a7710 <invoke_main_func>, body_data=0xbfffe210,
handler=0x400cc860 <scm_handle_by_message>, handler_data=0x0)
at throw.c:283
#26 0x400a74ef in scm_boot_guile_1 (base=0xbfffe20c, closure=0xbfffe210)
at init.c:600
#27 0x400a73eb in scm_boot_guile (argc=7, argv=0xbfffe2dc,
main_func=0x400a3d20 <gh_launch_pad>, closure=0x804c3d0) at init.c:443
#28 0x400a3d7a in gh_enter (argc=7, argv=0xbfffe2dc,
c_main_prog=0x804c3d0 <main_prog>) at gh_init.c:70
#29 0x804c8ae in main (argc=7, argv=0xbfffe2dc) at gnetlist.c:225
#30 0x4013cf31 in __libc_start_main (main=0x804c890 <main>, argc=7,
ubp_av=0xbfffe2dc, init=0x804983c <_init>, fini=0x804fabc <_fini>,
rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbfffe2d4)
at ../sysdeps/generic/libc-start.c:129
Steve Tell wrote:
> On Sun, 6 Jan 2002, Dave Lawrence wrote:
>
> > my problem goes away. Can we set the guile stack limit from the backend files
> > instead of recompiling guile??
>
> perhaps try:
> (eval-options (list 'stack 200000))
>
> This form is also mentioned in the manual, but doesn't seem to work:
> (eval-set! 'stack 200000)
>
> --
> Steve Tell tell@telltronics.org
--
+---------------------------------------------------------------------+
| David Lawrence (650)833-7847 (W) |
| IntegriNautics Corporation (650)833-5601 (Fax) |
| 1505 Adams Drive |
| Menlo Park, CA 94025 (650)960-6864 (H) |
| mailto:dgl@IntegriNautics.com |
+---------------------------------------------------------------------+