I asked these questions on the cmucl-help mailing list but I haven't had
much luck, so I thought I would ask them here also...
all of these questions apply to cmucl18c on FreeBSD
** Question 1:
(load-foreign) gives warnings like this when used to
load a foreign object file
Warning: "_etext" moved from #x08083c9c to #x0e06d35d
Warning: "__bss_start" moved from .....
Warning: "_end" moved from .....
These are apparently produced by the linker.
This happens for something as trivial as
--
int foo() {return 1;} /* compile with gcc -c foo.c */
--
(load-foreign "foo.o") ;; then load into lisp - gives above warnings
--
This problem is not seen on cmucl18c with Linux rather than FreeBSD.
Has anyone encountered it? Is it a serious problem? If so, can I compile
object files in a way that avoids it?
** Question 2:
I wrote a threaded app. It avoids SIGALRM thread swiches because
CMUCL is not interrupt safe. Instead, threads call (mp:process-yield)
to switch.
After a while, I get the following assertion error when I run (room):
'The assertion (system:sap= x:86::current
x86::end) failed'
It seems to happen in the function map-allocated-objects inside room.lisp
in the cmucl source tree. Apparently, it means that all of the objects
inside a scanned memory space did not fit inside the nominal bounds of that
space.
Sometimes cmucl recovers and subsequent (room) and (gc :full t)
commands work, and sometimes (gc :full t) causes cmucl to
grow to hundreds of megabytes and die.
Again, I've seen this on a FreeBSD machine, but not on a more lightly
loaded linux machine. Has anyone seen this problem before? Is FreeBSD
cmucl less stable than the linux version?
Many thanks in advance.
From: Vladimir Zolotykh
Subject: Re: two CMUCL problems - load-foreign, memory corruption
Date:
Message-ID: <3C738603.158F9620@eurocom.od.ua>
John Klein wrote:
>
> int foo() {return 1;} /* compile with gcc -c foo.c */
Not sure you're doing right thing here. Do you aware of .so
libraries ? In Linux they could be made with
$ gcc -fPIC -c *.c
$ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
(see GCC-HOWTO in /usr/doc/Linux-HOWTO)
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> wrote in message news:<·················@eurocom.od.ua>...
> John Klein wrote:
> >
> > int foo() {return 1;} /* compile with gcc -c foo.c */
>
> Not sure you're doing right thing here. Do you aware of .so
> libraries ? In Linux they could be made with
> $ gcc -fPIC -c *.c
> $ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
>
--------------------
Thanks for the hint. Loading both the foo.o file produced
by gcc -fPIC, and the libfoo.so.1.0 produced by the 2nd command
above both give the same linking errors as before.
After reading your post, I thought that my memory failures could
be caused by non-position-independent .o files, so I hoped
that your suggestion would stop the cmucl crashes, but no luck.
Is there anyone out there who uses threaded CMUCL apps on FreeBSD?
Is there anyone out there who has gotten long-lived threaded apps to
work robustly and steadily under Linux, at least?