[Ecls-list] sig11 in cl_boot()

[Juan Jose Garcia-Ripoll]

2007/1/16, Stanislaw Halik <sthalik at tehran.lain.pl>:
> On Tue, Jan 16, 2007, Juan Jose Garcia-Ripoll wrote:
> > I need more information:
>
> > * Flags you used to build ECL
>
> I didn't specify any flags myself for building the latest CVS, using the
> default of "-O2 -g". Stable 0.9i was built by a Debian maintainer, I
> believe no additional optimizations were being used.

That is not enough. Was ECL built with pthread support? If so...

> > * Procedure you use to link with ECL's library
>
> gcc -g -O0 -o epic5 [long, boring list of objects] words.o ecl.o info.o
> -Wl,-E -L/usr/local/lib /usr/lib/perl/5.8/auto/DynaLoader/DynaLoader.a
> -L/usr/lib/perl/5.8/CORE -lperl -ldl -lm -pthread -lc -lcrypt -lruby1.8
> -lpthread -ldl -lcrypt -lm -lncurses -lssl -lcrypto -lnsl -lresolv
> -lcrypt -lm -lrt -L/tmp/ecl/lib/ecl -lecl

...linking against pthread is not enough. All threads have to be
created by the routines in the garbage collector. This is so because
the garbage collector has to keep track of the stacks that are
created, static regions, etc.

>From your backtrace I see that for instance the routine intern() is
getting a value of package = NULL. That could happen if the garbage
collector has accidentally lost the current package.

Another important error is that ecl cannot be the last library you
link because it is using other libraries you already listed before.

I do not mean this is the problem, because I cannot tell from your
email whether your application or ECL are multithreaded. I just want
to emphasize the need to narrow the problem.

> This time it was built with Perl support, but crashes the same without
> it.
> [From previous email...]
> I thought that some library might be in conflict with ECL, but linking a
> test program with the same libraries doesn't make it crash.

It understand that if you link a stupid program
  int main(int narg, char **argv) { cl_boot(narg, argv);
cl_shutdown(); return 0; }
using something like
  gcc -o a.out foo.c <all_your_previous_libraries>
it does not crash.

However, the fact that it does not crash with all the libraries you
listed does not discard a name conflict: since _no_ symbol from those
libraries is referenced in the main program and since the libraries
themselves appear before ECL, they are simply ignored by the linker.

Other possibility is that either perl or ruby interfere with the
memory management in ECL.

Regards,

Juanjo

--
Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 2804 (Spain)
http://teorica.fis.ucm.es/~jjgarcia/