Re: [Chicken-users] Problems loading extensions on some platforms

[felix]

On 04 Nov 2003 11:40:09 +1300, Bruce Hoult <address@hidden> wrote:

> On Tue, 2003-11-04 at 00:19, Felix Winkelmann wrote:
> > BTW, can someone confirm the same problem under other SPARC platforms?
> > (Sven?)
>
> I haven't seen this one, but the compiler (version 1.21) has been
> coredumping on me on code that works fine in 1.19.
>
>
> bash-2.05$ make build
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/bin/csc -O2
> -disable-interrupts -c++ -o
> acs.cpp -t acs.scm
> Segmentation Fault - core dumped
> *** Shell command terminated with exit status 139:
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/bin/chicken acs.scm
> -output-file acs.cpp -quiet -optimize-level 2 -disable-interrupts
> make: *** [acs.cpp] Error 139
> bash-2.05$ gdb ../../../THIRD_PARTY/bin/chicken core
> GNU gdb 5.3
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "sparc-sun-solaris2.9"...
> Core was generated by
> `/volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/bin/chicken acs.scm
> -output-file ac'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/lib/libchicken.so.0...done.
> Loaded symbols for
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/lib/libchicken.so.0
> Reading symbols from
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/lib/libstuffed- 
> chicken.so.0...done.
> Loaded symbols for
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/lib/libstuffed-chicken.so.0
> Reading symbols from
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/lib/libsrfi- 
> chicken.so.0...done.
> Loaded symbols for
> /volA/DEV_BASE/TNZ_DEV/nondebug/THIRD_PARTY/lib/libsrfi-chicken.so.0
> Reading symbols from /usr/lib/librt.so.1...done.
> Loaded symbols for /usr/lib/librt.so.1
> Reading symbols from /usr/lib/libsocket.so.1...done.
> Loaded symbols for /usr/lib/libsocket.so.1
> Reading symbols from /usr/lib/libnsl.so.1...done.
> Loaded symbols for /usr/lib/libnsl.so.1
> Reading symbols from /usr/lib/libdl.so.1...done.
> Loaded symbols for /usr/lib/libdl.so.1
> Reading symbols from /usr/lib/libm.so.1...done.
> Loaded symbols for /usr/lib/libm.so.1
> Reading symbols from /usr/lib/libc.so.1...done.
> Loaded symbols for /usr/lib/libc.so.1
> Reading symbols from /opt/gcc-3.2.3/lib/libgcc_s.so.1...done.
> Loaded symbols for /opt/gcc-3.2.3/lib/libgcc_s.so.1
> Reading symbols from /usr/lib/libaio.so.1...done.
> Loaded symbols for /usr/lib/libaio.so.1
> Reading symbols from /usr/lib/libmd5.so.1...done.
> Loaded symbols for /usr/lib/libmd5.so.1
> Reading symbols from /usr/lib/libmp.so.2...done.
> Loaded symbols for /usr/lib/libmp.so.2
> Reading symbols from
> /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1...done.
> Loaded symbols for /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1
> #0  0xff21861c in C_reclaim (trampoline=0x0, proc=0x1) at runtime.c:1863
> 1863        if(gc_mode == GC_REALLOC) {
> (gdb) bt
> #0  0xff21861c in C_reclaim (trampoline=0x0, proc=0x1) at runtime.c:1863
> #1  0xff218520 in C_save_and_reclaim (trampoline=0x3434352f,
> proc=0x75736167,
> n=1694564351) at runtime.c:1828
> #2  0xffbc09f4 in ?? ()
> Cannot access memory at address 0x2400003b
> (gdb)
>
>
> The really strange thing is that if I take out a few lines of code from
> almost any function -- or even from the middle of a "here" string
> constant containing inline C -- then the compiler no longer crashes!
>
> I'm going to try the latest version now, and if that dosn't work then
> I'm reverting to 1.19.

Christ! What is happening here? The one Solaris specific change
that can possibly be the reason here, is that alloca.h is included by 
default.

Bruce: is it possible that you try to rebuild the whole system with the 
#include
 in chicken.h (line 60) disabled? IIRC this is needed for compiling in C++ 
mode,
 but perhaps we can at least localize the problem.

Sven/Category 5: can you try the same? Just make sure alloca.h is not 
included.

Can someone mail be a complete build-log from the 1.22 tarball on a Solaris
system?


cheers,
felix