From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Mon Feb 08 1999 - 01:06:54 EST
On Feb 7, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>> One of the questions that remain unanswered is whether something
>> really screws up the function table or if it's just partially fixed
>> up.
> If you think about the fact that the signal handler is in a shared
> library, then it appears that simply invoking the handler has the
> potential to reenter some of the functions doing the relocation or
> whatever.
Yep. And your patches appear to have fixed it completely. I haven't
been able to reproduce any of those crashes on Solaris2.[56]/sparc nor
on GNU/Linux/x86! Great!
Unfortunately, the GCTest failure on Solaris 2.5 remains, and
SoTimeout always fails with the following output:
Success 1.
Failure java.io.IOException: Transport endpoint is already connected
Success 2.
Success 3.
java.io.InterruptedIOException: Read timed out or was interrupted
at java.net.SocketInputStream.read(SocketInputStream.java:32)
at java.io.InputStreamReader.read(InputStreamReader.java:53)
at java.io.BufferedReader.refillBuffer(BufferedReader.java:164)
at java.io.BufferedReader.readLine(BufferedReader.java:130)
at java.io.LineNumberReader.readLine(LineNumberReader.java:80)
at SoTimeout.main(SoTimeout.java:53)
Strangely, it passes on Solaris 2.6... I'll investigate it.
> Along those lines, I should probably pull the DNS functions into the
> jsyscall interface.
Sounds reasonable.
> The alternative is to spawn a new process (or steal a DNS impl in
> Java).
Methinks a DNS impl in Java would have trouble when running within an
applet. We'd probably need a native implementation of DNS. Maybe we
just shouldn't care about that, and get Kaffe working with native
threading systems.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:00 EDT