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

[Category 5]

felix <address@hidden> writes:

>> Unfortunately, in my real code, the dispatcher() function is opaque -
>> it's part of foreign library code that I'm trying to create bindings
>> for.  So I can't add C_gc_protect calls inside it.  Are there any
>> options left except for static memory or malloc?
>
> 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.
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.

>> Also, any idea why anything I compile with -O1 or -O2 on this platform
>> immediately dumps core on execution?  =)
>
> 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)
-------------------------------------------------------------------------

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...

--