From: Godmar Back (gback@cs.utah.edu)
Date: Wed Jan 20 1999 - 13:43:11 EST
>
> When I test it with intrp engine, I found 2 new bugs:
> - lt_dlopen() need more stack (more than 8Ko).
I see. The allocate several 1k arrays on the stack.
Alexandre can fix that.
Should there be problems with relying on malloc/free, please
make it an #ifdef option.
>
> - fix ExecTest that don't read pipe result of /bin/ls, I use /bin/echo
You know, I don't understand why that always worked for me.
>
> Today, all work as before (with -ss 64K) with intrp and jit on i386.
Yes, we need to keep the stack size as small as possible with our
current stack allocation scheme. It's a scalability issue.
>
> 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 jit engine uses callMethod? much less often.
>
> 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.
Clearly, that's no good. Let's hope the libtool folks won't argue
that that's a serious problem.
>
> 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.
native() is also not thread safe in the intr either. It's in the todo list.
There may be a bootstrapping issue.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:47 EDT