[plt-scheme] in need for a hint to debug a crash

It's difficult to guess what could be going wrong. It certainly sounds
like memory corruption, though possibly not at the site of the 128-byte
allocation. It may be, for example, that allocating a 1025-byte block
shifts the allocation of other values, so that memory corruption
doesn't lead to a crash.

You might try compiling with --enable-sgc, and then turn on
PAD_BOUNDARY_BYTES in "src/mzscheme/sgc/sgc.c". Maybe the checks in SGC
will help, or maybe just using a difficult allocator will turn up
useful information.

Matthew

At Tue, 22 Jan 2008 06:30:55 +0100, "Marco Maggi" wrote:
> I am  using PLT 372 on a  i686-pc-linux-gnu, Slackware Linux
> 12.0.0, GCC 4.1.2, built and installed from source with:
> 
> | configure \
> |   --enable-shared --enable-cgcdefault \
> |   CFLAGS="-O3 -march=i686 -mtune=i686 \
> |           -I/opt/gnome-2.20/include -L/opt/gnome-2.20/lib"
> 
> and I get the same behaviour with PLT 371 (I was not able to
> install PLT 3.99).  I am  coding a module implemented by a C
> shared library built with:
> 
> | configure CFLAGS="-O3 -g -march=i686 -mtune=i686"
> 
> In it I  define my own MzScheme primitive  types as wrappers
> of "Scheme_Object".  One of the types I am allocating, has a
> block of memory of less than  128 bytes and I get crashes in
> the process when allocating with:
> 
> | scheme_malloc_fail_ok(scheme_malloc, block_size);
> 
> the crash always happens when  I run my test suite, but when
> I change something in the code the point of crash changes.
> 
> The  crash happens  in the  MzScheme code,  and it  seems to
> reliably go away  if I arbitrarily change the  block size to
> more than 1024 bytes; that is I get the crash with:
> 
> | scheme_malloc_fail_ok(scheme_malloc, 1024);
> 
> but I do not get it with:
> 
> | scheme_malloc_fail_ok(scheme_malloc, 1025);
> 
> What  the hell?   When I  alloc  1025 bytes  the test  suite
> completes with no errors, and to the best of my knowledge so
> far that means that the structures are not corrupted because
> the purpose of the suite  is exactly to test manipulation of
> their  fields,   including  validation  of   SCHEME_TYPE  of
> "Scheme_Object".
> 
> Program received signal SIGSEGV, Segmentation fault.
> do_clear_symbols (t=0x8aefe10, start=0, offset=8,
> addr=145686528, clearing=0) at ./codetab.inc:227
> 227	      if (!*(Scheme_Type *)val) {
> #0  do_clear_symbols (t=0x8aefe10, start=0, offset=8,
> addr=145686528, clearing=0) at ./codetab.inc:227
> #1  0x400892f9 in do_clear_symbols (t=0x8aefe60, start=0,
> offset=12, addr=145686528, clearing=0) at ./codetab.inc:229
> #2  0x400892f9 in do_clear_symbols (t=0x8aadf50, start=0,
> offset=16, addr=144703488, clearing=0) at ./codetab.inc:229
> #3  0x400892f9 in do_clear_symbols (t=0x811b2d0, start=0,
> offset=20, addr=134217728, clearing=0) at ./codetab.inc:229
> #4  0x400892f9 in do_clear_symbols (t=0x811b320, start=0,
> offset=24, addr=0, clearing=0) at ./codetab.inc:229
> #5  0x400892f9 in do_clear_symbols (t=0x811b370, start=0,
> offset=28, addr=0, clearing=0) at ./codetab.inc:229
> #6  0x40089425 in scheme_clean_native_symtab () at
> ./codetab.inc:262
> #7  0x4012c948 in clean_symbol_table () at ./symbol.c:242
> #8  0x401ce4f6 in GC_finalize () at ./finalize.c:882
> #9  0x401c4420 in GC_finish_collection () at ./alloc.c:681
> #10 0x401c4f85 in GC_try_to_collect_inner
> (stop_func=0x401c3f50 <GC_never_stop_func>) at ./alloc.c:395
> #11 0x401c552b in GC_collect_or_expand (needed_blocks=1,
> ignore_off_page=0) at ./alloc.c:1051
> #12 0x401c569c in GC_allocobj (sz=4, kind=1) at ./alloc.c:1106
> #13 0x401d0de7 in GC_generic_malloc_inner (lb=12, k=1) at
> ./malloc.c:138
> #14 0x401d0ea5 in GC_generic_malloc (lb=12, k=1) at
> ./malloc.c:194
> #15 0x401d1056 in GC_malloc (lb=12) at ./malloc.c:319
> #16 0x40098b3e in scheme_make_pair (car=0x8b38b70,
> cdr=0x8b3fbb0) at ./list.c:561
> #17 0x401244d3 in scheme_add_rename (o=0x8b3e000,
> rename=0x8b38b70) at ./stxobj.c:1375
> #18 0x40124909 in propagate_wraps (o=0x8b3e000, len=4,
> _ml=0xbfc6ffec, owner_wraps=0x8b41170) at ./stxobj.c:1801
> #19 0x40124a8f in scheme_stx_content (o=0x8b43fe0) at
> ./stxobj.c:2182
> #20 0x400533a0 in scheme_compile_expand_expr (form=<value
> optimized out>, env=<value optimized out>, rec=0xbfc70108, 
>     drec=0, app_position=0) at ./eval.c:4247
> #21 0x40053be8 in scheme_expand_list (form=0x8b42160,
> env=0x8a7b5b0, erec=0xbfc70398, drec=0) at ./eval.c:5390
> #22 0x40057830 in compile_expand_app (forms=0x8b43ee0,
> env=0x8a7b5b0, rec=0xbfc70398, drec=0) at ./eval.c:4685
> #23 0x400537fa in scheme_compile_expand_expr (form=<value
> optimized out>, env=<value optimized out>, rec=0xbfc70398, 
>     drec=0, app_position=0) at ./eval.c:4426
> #24 0x401321f3 in do_let_expand (form=0x8b42380,
> origenv=0x8a7b620, erec=0xbfc704f8, drec=0, 
>     formname=0x40156699 "letrec-values", letrec=1, multi=1,
> letstar=0, env_already=0x0) at ./syntax.c:4086
> #25 0x401327ba in letrec_values_expand (form=0x8b42380,
> env=0x8a7b620, erec=0xbfc704f8, drec=0) at ./syntax.c:4141
> #26 0x400538ae in scheme_compile_expand_expr (form=<value
> optimized out>, env=<value optimized out>, rec=0xbfc704f8, 
>     drec=0, app_position=0) at ./eval.c:4308
> #27 0x40053be8 in scheme_expand_list (form=0x8b41360,
> env=0x8a7b620, erec=0xbfc706f8, drec=0) at ./eval.c:5390
> #28 0x40055d65 in scheme_compile_expand_block (forms=<value
> optimized out>, env=0x8a7b620, rec=0xbfc706f8, drec=0)
>     at ./eval.c:5271
> #29 0x4013250a in do_let_expand (form=0x8b3e4a0,
> origenv=0x8a7b9a0, erec=0xbfc70858, drec=0, 
>     formname=0x401566a7 "let-values", letrec=0, multi=1,
> letstar=0, env_already=0x0) at ./syntax.c:4114
> 
> -- 
> Marco Maggi
> 
> "Now feel the funk blast!"
> Rage Against the Machine - "Calm like a bomb"
> 
> 
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme