Re: debugging guile test failure and segfault.

[Ludovic Courtès]

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.