Re: [Chicken-users] Some allocation and object-passing tests

[felix]

On Wed, 12 Nov 2003 21:43:49 +0000, Category 5 <address@hidden> 
wrote:

> > Hm. I'll find something. The problem is that C_gc_protect protects
> > variables pointing to values from GC, not the values themselves.
>
> I'd kind of thought at first that this was what C_alloc_in_heap was for.

No, a pointer into the heap still points to data that moves during GC.

> It would be neat to have a function that returned a pointer that was
> guaranteed to stay safe:
>
> p = C_make_safe_pointer(non_immediate_scheme_object)
>
> +---------+
> p --> | obj_ptr | --> <object header+data>
> +---------+
>
> ...so that when GC moves the object around it also updates the cell p
> points to to reflect the current location of the object.

Hmm.

> > That's NetBSD on Sparc64, right?
>
> Yup - Version 1, Build 22 - netbsd-gnu-ultrasparc.
>
> Backtrace doesn't look terribly useful...
> -------------------------------------------------------------------------
> % echo '(print "hello world")' > hello.ss
> % csc hello.ss -kv -O1
> /usr/local/chicken/bin/chicken hello.ss -output-file hello.c -quiet
> -optimize-level 1
> gcc hello.c -o hello.o -O3 -g -Wall -Wno-unused -Wno-uninitialized
> -fstrict-aliasing -DC_STACK_GROWS_DOWNWARD=1 "- 
> DC_INSTALL_LIB_HOME=\"/usr/local/chicken/lib/chicken\"" - 
> DC_USE_C_DEFAULTS -mflat -c -DC_NO_PIC_NO_DLL -I 
> /usr/local/chicken/include
> gcc -o hello hello.o -lchicken -lsrfi-chicken -lstuffed-chicken -Wl,- 
> R/usr/local/chicken/lib  -L/usr/local/chicken/lib -lm
> % ./hello
> zsh: bus error (core dumped)  ./hello
> % gdb hello hello.core
> [...]
> #0  0x10149c in C_toplevel (c=2, t0=30, t1=0) at hello.c:38
> 38      void C_toplevel(C_word c,C_word t0,C_word t1){
> (gdb) bt
> #0  0x10149c in C_toplevel (c=2, t0=30, t1=0) at hello.c:38
> #1  0x9007a7e74008355f in ?? ()
> #2  0x15000000d85dc010 in ?? ()
> #3  0x405419b8 in CHICKEN_main (argc=1, argv=0xffffffffffffd5f8, 
> toplevel=0x101498) at runtime.c:412
> #4  0x101c38 in main (argc=1, argv=0xffffffffffffd5f8) at hello.c:33
> #5  0x7474797030005350 in ?? ()
> (gdb)

Sorry, I have no idea.

> -------------------------------------------------------------------------
>
> P.S.  Still poking at the C_dload problem under OS X (10.1.5).  Doing a
> -g build now to see whether single-stepping shows anything useful...

Yes, that would be helpful. I apologize for all that mess. Unfortunately
I have only access to plain old x86 boxes (and those at hp's testdrive).


cheers,
felix