RE: Array data without GCC extension

Date view Thread view Subject view Author view

From: Parmelan, Edouard (EP510777@exchange.FRANCE.NCR.com)
Date: Wed Jan 20 1999 - 12:05:38 EST


Hi,

The following patch is the new version of my previous
kaffe-array.diff.

When I test it with intrp engine, I found 2 new bugs:
- lt_dlopen() need more stack (more than 8Ko).
- loadNativeLibrary() and libltdl are not thread safe.

What does kaffe-array.diff patch ?
- removes the usage of the GCC extension 'double align[0]' in
  the definition of all HArrayOfXXX.
- removes the struct Array.
- no longer use DEFINE_ARRAY_OF in Arrays.h.
- fix a 'const' warning for intrp engine.
- fix ExecTest that don't read pipe result of /bin/ls, I use /bin/echo

I don't send it yesterday because I was not able to:
- run Linux-2.2.0-pre8 [small bug with strstr()].
- run intrp engine [Again libtool :(].

Today, all work as before (with -ss 64K) with intrp and jit on i386.

Bugs reports

As I have change /usr/include/linux/* and /usr/include/asm/* with
the linux kernel patch, I had to found the broken stuff before thinking
to kaffe and I found it :).

The intrp engine work if I use a greater Thread Stack Size.
The jit engine don't need -ss 64K, may be it use less stack than intrp ?

The problem was with libtool again :(
In fact, lt_dlopen() need more stack-size than a direct call to dlopen().
- lt_dlopen() use 6 char[FILENAME_MAX], call file_find() or find_module()
  or tryall_dlopen() or find_library().
- find_file() use 2 char[FILENAME_MAX].
- find_module() use 1 char[FILENAME_MAX] and call tryall_dlopen().
- find_library() use 2 char[FILENAME_MAX] and call tryall_dlopen().
- ignore small stack usage of tryall_dlopen().
Total possible stack usage of lt_dlopen() 8 char[FILENAME_MAX] == 8 Ko
[without integer or pointers locals and stackframes].
Internaly with GNU/Linux libc5, dlopen() use an array of 2050 chars.

As UDPTest fail for me and Alice, I previouly think that lt_dlopen()
was called by two differents threads. It does not during my test, it fail
because of the lt_dlopen stack overflow in a thread stack.

In any case, loadNativeLibrary() COULD be called by two threads :(
It's not thread safe.

libltdl use a global list of all loaded modules that should also be
protected.

Happy hacking,
Edouard.

---
 <<kaffe-array.diff>> 



Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:47 EDT