guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Help needed debugging segfault with Guile 1.8.7


From: Peter TB Brett
Subject: Help needed debugging segfault with Guile 1.8.7
Date: Wed, 10 Nov 2010 12:43:38 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi folks,

I've recently been working on greatly expanding the Guile Scheme API to
libgeda, the shared library in the gEDA suite [1].  Unfortunately, I
need your help.

I've added a testsuite for the libgeda Scheme API.  In one commit [2],
the testsuite succeeds.  In the following commit [3], a test which does
not touch any of the changed code starts causing a segfault in the Guile
interpreter.

I am using Guile 1.8.7 on Fedora Linux (guile-1.8.7-5.fc13.i686).  I've
recompiled the package from the official spec file with the
`--enable-debug' flag.  I can reliably reproduce the problem as
follows:


  git clone git://repo.or.cz/geda-gaf/peter-b.git
  cd peter-b
  git checkout -t origin/guile-scheme-api

  ./autogen.sh && ./configure
  make version.h             # This avoids building whole package

  (cd libgeda && make check) # Segfault in t0015-object-complex.scm

  git checkout HEAD^

  (cd libgeda && make check) # Succeeds


What I've tried so far:

1. Running the test under gdb:

     srcdir=libgeda/scheme \
     libtool --mode=execute gdb --args libgeda/shell/geda-shell -q \
       -L libgeda/scheme \
       -s libgeda/scheme/unit-tests/t0015-object-complex.scm

   Works perfectly.

2. Running the test under gdb in a different way:

     srcdir=libgeda/scheme \
     libtool --mode=execute gdb --args libgeda/shell/geda-shell -q \
       -L libgeda/scheme \
       -c '(load (cadr (command-line)))' \
       libgeda/scheme/unit-tests/t0015-object-complex.scm

   Also works perfectly.

2. Running the test under gdb in a third way (this is the same way it's
   run by `make check'):

     srcdir=libgeda/scheme \
     libtool --mode=execute gdb --args libgeda/shell/geda-shell -q \
     -L libgeda/scheme \
     -c '(use-modules (unit-test)) (load (cadr (command-line)))' \
     libgeda/scheme/unit-tests/t0015-object-complex.scm
 
   We can observe the segfault:

     Program received signal SIGSEGV, Segmentation fault.
     scm_cell (e1=0x404) at ../libguile/inline.h:127
     127           *freelist = SCM_FREE_CELL_CDR (*freelist);

   Unfortunately, I've been unable to interpret the backtrace
   (attached).  Can anyone help me out with this?

Valgrind / Memcheck wasn't very helpful either.  Is there a way to make
Guile zero each new heap page it requests before using it in order to
reduce the number of false positives the gc generates in Memcheck?

In fact, *none* of the ways I've found of running the test without the
segfault occurring have given me *any* clue as to how to fix it
"properly".

I'd really appreciate any suggestions that anyone might be able to give
me on figuring out how I've managed to break things.  At the moment, I'm
at a complete loss.

Thanks in advance for any help you can give!

Regards,

                                       Peter
   

[1] http://www.gpleda.org
[2] http://repo.or.cz/w/geda-gaf/peter-b.git/commit/f8b371c8732f
[3] http://repo.or.cz/w/geda-gaf/peter-b.git/commit/c7d44a2507ed

-- 
Peter Brett <address@hidden>
Remote Sensing Research Group
Surrey Space Centre

#0  scm_cell (e1=0x404) at ../libguile/inline.h:127
#1  scm_list_1 (e1=0x404) at list.c:47
#2  0x001b3ee0 in scm_eval_args (l=0xb7f574a0, env=0xb7ef33d0, proc=
    0xb7f5c5e0) at eval.c:2963
#3  0x001ac27a in ceval (x=0xb7f574a8, env=0xb7ef33d0) at eval.c:4597
#4  0x001b3ed6 in scm_eval_args (l=0xb7f57480, env=0xb7ef33d0, proc=
    0xb7f5c5e0) at eval.c:2961
#5  0x001ac27a in ceval (x=0xb7f574f0, env=0xb7ef33d0) at eval.c:4597
#6  0x001abe31 in ceval (x=0xb7f42830, env=0xb7ef3530) at eval.c:4212
#7  0x001b4727 in call_closure_1 (proc=0xb7ef44f8, arg1=0xb7ee9a70)
    at eval.c:5261
#8  0x001af297 in scm_map (proc=0xb7ef44f8, arg1=0xb7ef4638, args=
    0x404) at eval.c:5489
#9  0x001ac96c in ceval (x=0x404, env=0xb7ef4518) at eval.c:4367
#10 0x001abe8f in ceval (x=0xb7fb11b0, env=0xb7ef4518) at eval.c:4342
#11 0x001b4727 in call_closure_1 (proc=0xb7eee8d0, arg1=0xb7ee9aa8)
    at eval.c:5261
#12 0x001af297 in scm_map (proc=0xb7eee8d0, arg1=0xb7eefee8, args=
    0x404) at eval.c:5489
#13 0x001ac96c in ceval (x=0x404, env=0xb7eee8e0) at eval.c:4367
#14 0x001b3ed6 in scm_eval_args (l=0xb7f48b78, env=0xb7eee8e0, proc=
    0xb7f5b250) at eval.c:2961
#15 0x001ac27a in ceval (x=0xb7f48b78, env=0xb7eee8e0) at eval.c:4597
#16 0x001b4727 in call_closure_1 (proc=0xb7eee6d8, arg1=0xb7eee620)
    at eval.c:5261
#17 0x001af297 in scm_map (proc=0xb7eee6d8, arg1=0xb7eee618, args=
    0x404) at eval.c:5489
#18 0x001ac96c in ceval (x=0x404, env=0xb7eee6e8) at eval.c:4367
#19 0x001abe8f in ceval (x=0xb7fac660, env=0xb7eee6e8) at eval.c:4342
#20 0x001abe8f in ceval (x=0xb7faa7f0, env=0xb7eebed0) at eval.c:4342
#21 0x001b4727 in call_closure_1 (proc=0xb7eeaa08, arg1=0xb7eeb6c0)
    at eval.c:5261
#22 0x001af297 in scm_map (proc=0xb7eeaa08, arg1=0xb7eeab30, args=
    0x404) at eval.c:5489
#23 0x001ac96c in ceval (x=0x404, env=0xb7eeaa20) at eval.c:4367
#24 0x001abe8f in ceval (x=0xb7fb11b0, env=0xb7eeaa20) at eval.c:4342
#25 0x001acd40 in ceval (x=<value optimized out>, 
    env=<value optimized out>) at eval.c:3648
#26 0x001b3d0e in scm_call_0 (proc=0xb7ee9798) at eval.c:4666
#27 0x001b678e in apply_thunk (thunk=0xb7ee9798) at fluids.c:400
#28 0x001b696f in scm_c_with_fluid (fluid=0xb7f8f330, value=
    0xb7f53d80, cproc=0x1b6770 <apply_thunk>, cdata=0xb7ee9798)
    at fluids.c:463
#29 0x001b69c6 in scm_with_fluid (fluid=0xb7f8f330, value=
    0xb7f53d80, thunk=0xb7ee9798) at fluids.c:450
#30 0x001ac412 in ceval (x=<value optimized out>, env=0xb7ee97c0)
    at eval.c:4547
#31 0x001abf86 in ceval (x=0xb7ee9b78, env=0xb7ee97f0) at eval.c:4059
#32 0x001b438b in scm_primitive_eval_x (exp=0xb7ee9b78)
    at eval.c:5921
#33 0x001cee83 in scm_primitive_load (filename=0xb7f6d950)
    at load.c:109
#34 0x001acb4e in ceval (x=0x404, env=0xb7ee90e0) at eval.c:4232
#35 0x0019d8bc in scm_start_stack (id=0xb7f66070, exp=0xb7fc77b0, 
    env=0xb7ee90e0) at debug.c:457
#36 0x0019d954 in scm_m_start_stack (exp=<value optimized out>, env=
    0xb7ee90e0) at debug.c:473
#37 0x001ae8ad in scm_apply (proc=0xb7fcf1d0, arg1=0xb7fc77e8, 
    args=<value optimized out>) at eval.c:4882
#38 0x001abf86 in ceval (x=0xb7fc77e8, env=0xb7ee90e0) at eval.c:4059
#39 0x001b3d0e in scm_call_0 (proc=0xb7ee9118) at eval.c:4666
#40 0x001b678e in apply_thunk (thunk=0xb7ee9118) at fluids.c:400
#41 0x001b696f in scm_c_with_fluid (fluid=0x8053ff0, value=0x4, 
    cproc=0x1b6770 <apply_thunk>, cdata=0xb7ee9118) at fluids.c:463
#42 0x001b69c6 in scm_with_fluid (fluid=0x8053ff0, value=0x4, thunk=
    0xb7ee9118) at fluids.c:450
#43 0x001ac412 in ceval (x=<value optimized out>, env=0xb7ee9158)
    at eval.c:4547
#44 0x001b3d0e in scm_call_0 (proc=0xb7ee9298) at eval.c:4666
#45 0x001a241c in scm_dynamic_wind (in_guard=0xb7ee9250, thunk=
    0xb7ee9298, out_guard=0xb7ee9240) at dynwind.c:111
#46 0x001ac412 in ceval (x=<value optimized out>, env=0xb7ee9260)
    at eval.c:4547
#47 0x001b438b in scm_primitive_eval_x (exp=0xb7ee9338)
    at eval.c:5921
#48 0x0020d018 in inner_eval_string (data=0xb7f52178)
    at strports.c:500
#49 0x001b696f in scm_c_with_fluid (fluid=0x804f100, value=
    0xb7f6e5d0, cproc=0x20cff0 <inner_eval_string>, cdata=0xb7f52178)
    at fluids.c:463
#50 0x001d0746 in scm_c_call_with_current_module (module=0xb7f6e5d0, 
    func=0x20cff0 <inner_eval_string>, data=0xb7f52178)
    at modules.c:107
#51 0x0020d247 in scm_eval_string_in_module (string=0xb7f6d930, 
    module=0xb7f6e5d0) at strports.c:527
#52 0x001ac936 in ceval (x=0x404, env=0xb7f52188) at eval.c:4258
#53 0x001acf92 in ceval (x=<value optimized out>, env=0xb7f52188)
    at eval.c:3368
#54 0x001b438b in scm_primitive_eval_x (exp=0xb7f521b8)
    at eval.c:5921
#55 0x001b43e6 in scm_eval_x (exp=0xb7f521b8, module_or_state=
    0xb7f6e5d0) at eval.c:5956
#56 0x08048fdd in shell_main (data=0x0, argc=7, argv=0xbfffed24)
    at shell.c:222
#57 0x001cb3f7 in invoke_main_func (body_data=0xbfffec40)
    at init.c:367
#58 0x0019bf43 in c_body (d=0xbfffebb4) at continuations.c:349
#59 0x002135f4 in scm_c_catch (tag=0x104, body=0x19bf30 <c_body>, 
    body_data=0xbfffebb4, handler=0x19bf60 <c_handler>, handler_data=
    0xbfffebb4, pre_unwind_handler=
    0x212ab0 <scm_handle_by_message_noexit>, pre_unwind_handler_data=
    0x0) at throw.c:203
#60 0x0019c543 in scm_i_with_continuation_barrier (body=
    0x19bf30 <c_body>, body_data=0xbfffebb4, handler=
    0x19bf60 <c_handler>, handler_data=0xbfffebb4, 
    pre_unwind_handler=0x212ab0 <scm_handle_by_message_noexit>, 
    pre_unwind_handler_data=0x0) at continuations.c:325
#61 0x0019c624 in scm_c_with_continuation_barrier (func=
    0x1cb3b0 <invoke_main_func>, data=0xbfffec40)
    at continuations.c:367
#62 0x0021216a in scm_i_with_guile_and_parent (func=
    0x1cb3b0 <invoke_main_func>, data=0xbfffec40, parent=0x0)
    at threads.c:733
#63 0x0021225f in scm_with_guile (func=0x1cb3b0 <invoke_main_func>, 
    data=0xbfffec40) at threads.c:721
#64 0x001cb390 in scm_boot_guile (argc=7, argv=0xbfffed24, main_func=
    0x8048cf0 <shell_main>, closure=0x0) at init.c:350
#65 0x08048ccb in main (argc=7, argv=0xbfffed24) at shell.c:234

Attachment: pgpOOTLcRgjD5.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]