[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: debugging guile test failure and segfault.
From: |
Ludovic Courtès |
Subject: |
Re: debugging guile test failure and segfault. |
Date: |
Thu, 07 Jun 2007 10:57:40 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Hi,
Dan McMahill <address@hidden> writes:
> a back trace showed that around line 834 of libguile/posix.c there is
> a call to ttyname() which is returning NULL. Unfortunately that NULL
> pointer is used a few lines later by some functions which try to run
> strlen() on it. Thats where the segfault is.
Good catch! I committed a patch similar to yours along with a test case
in CVS.
> Running r4rs.test
> ERROR: In procedure ttyname:
> ERROR: No such file or directory
I can't see what's causing this in `r4rs.test'. Could you try running
that test from the prompt and enter the debugger when the error is
raised so that we get a Scheme stack trace? Roughly:
$ ./pre-inst-guile
guile> (module-set! (resolve-module '(test-suite guile-test))
'test-suite \"$PWD/test-suite/tests\")
guile> (module-set! (resolve-module '(test-suite guile-test))
'tmp-dir "/tmp\)
guile> (load "test-suite/tests/r4rs.test")
[...]
ERROR: ...
guile> (debug)
debug> bt
> Running regexp.test
> Segmentation fault (core dumped)
>
>
> #0 0x00000001600d6bb4 in scm_is_pair (x=0x10001202cbd60) at inline.h:272
> #1 0x0000000160086434 in scm_sloppy_assq (key=0x1200673a0,
> alist=0x10001202cbd60) at alist.c:53
> #2 0x00000001600d2a58 in scm_hash_fn_get_handle (table=0x120321ac0,
> obj=0x1200673a0, hash_fn=0x1600d15ec <scm_ihashq>,
> assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:428
> #3 0x00000001600d2e20 in scm_hash_fn_ref (table=0x12009aba0,
> obj=0x1200673a0, dflt=0x4, hash_fn=0x1600d15ec <scm_ihashq>,
> assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:500
> #4 0x00000001600d3304 in scm_hashq_ref (table=0x12009aba0,
> key=0x1200673a0, dflt=0x4) at hashtab.c:613
> #5 0x00000001600dc904 in module_variable (module=0x12009ab40,
> sym=0x1200673a0) at modules.c:289
> #6 0x00000001600dcabc in scm_eval_closure_lookup (eclo=0x1200f56d0,
> sym=0x1200673a0, definep=0x4) at modules.c:337
> #7 0x00000001600dcf38 in scm_sym2var (sym=0x1200673a0,
> proc=0x1200f56d0, definep=0x4) at modules.c:461
> #8 0x00000001600a2d6c in scm_lookupcar1 (vloc=0x12071b1e0,
> genv=0x120228620, check=1) at eval.c:2861
> #9 0x00000001600a73b0 in ceval (x=0x12071b1e0, env=0x120228620) at
> eval.c:4027
> #10 0x00000001600a4d54 in ceval (x=0x1202286d0, env=0x120228620) at
> eval.c:3557
> #11 0x00000001600a3cb4 in ceval (x=0x12071adc0, env=0x12071aa10) at
> eval.c:3384
> #12 0x00000001600aa168 in scm_apply (proc=0x1201522c0, arg1=0x404,
> args=0x12071aa30) at eval.c:4997
> #13 0x00000001600a90b0 in scm_call_0 (proc=0x12071aaa0) at eval.c:4651
This one is certainly trickier. The stack trace above is that of a
variable lookup (i.e., not related to regexps). Can you try running
`regexp.test' alone just to make sure?
Address X is 8-byte aligned, which corresponds to a non-immediate.
Could you try printing (from the debugger) `* ((SCM *) x)' and
`* ((SCM *) x + 1)'?
I'm afraid it'll be quite hard to find out what's going wrong...
Thanks for debugging!
Ludovic.
- debugging guile test failure and segfault., Dan McMahill, 2007/06/04
- Re: debugging guile test failure and segfault., Ludovic Courtès, 2007/06/06
- Re: debugging guile test failure and segfault., Dan McMahill, 2007/06/07
- Re: debugging guile test failure and segfault.,
Ludovic Courtès <=
- Re: debugging guile test failure and segfault., Dan McMahill, 2007/06/08
- Re: debugging guile test failure and segfault., Ludovic Courtès, 2007/06/10
- Re: debugging guile test failure and segfault., Dan McMahill, 2007/06/10
- Re: debugging guile test failure and segfault., Ludovic Courtès, 2007/06/11
- Re: debugging guile test failure and segfault., Ludovic Courtès, 2007/06/11
- Re: debugging guile test failure and segfault., Dan McMahill, 2007/06/11
Re: debugging guile test failure and segfault., Dan McMahill, 2007/06/09