gcj seg fault in InetAddress.lookup

Jacob Gladish jake@gladish.info
Wed Jun 16 21:02:00 GMT 2004


It appears that the java.net.InetAddrsss.getLocalHost call is not thread
safe. The localhost var can be pass the null check while another thread
is about to set it. In my case that did not seem to be the issue. I
believe it's because I do not have gethostbyname_r installed on FreeBSD
5.2.1. But it looks as thought fixing the first race condition guards
the call to the non-re-entrant call to gethostbyname and fixes my
problem.
This is a patch I applied. I've also attached a sample test app that
will segfault immediately on FreeBSD gcj 3.3.1.
***************
*** 575,587 ****
 // Experimentation shows that JDK1.2 does cache the result.
 // However, if there is a security manager, and the cached result
 // is other than "localhost", we need to check again.
!
! synchronized (InetAddress.class) {
! if (localhost == null
! || (s != null && localhost.addr != localhostAddress))
! getLocalHost(s);
! }
!
 return localhost;
 }
--- 575,583 ----
 // Experimentation shows that JDK1.2 does cache the result.
 // However, if there is a security manager, and the cached result
 // is other than "localhost", we need to check again.
! if (localhost == null
! || (s != null && localhost.addr != localhostAddress))
! getLocalHost(s);
 return localhost;
 }
-----Original Message-----
From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf
Of Tom Tromey
Sent: Tuesday, June 15, 2004 11:47 PM
To: Jacob Gladish
Cc: java@gcc.gnu.org
Subject: Re: gcj seg fault in InetAddress.lookup
>>>>> "Jacob" == Jacob Gladish <jake@gladish.info> writes:

Jacob> Has anyone seen this segfault before? I'm running on freebsd 5.1,
gcj
Jacob> 3.3.1. The strange part is that if I write a small unit test that
just
Jacob> calls the same exact code, it works.
Jacob> InetAddress.getLocalHost().getHostName().
I don't really know this code, so I can't suggest something other
than just plain old debugging...
Jacob> The dereference of "bytes"
Jacob> seems to be causing it. Why didn't the call to elements fail? 
The compiler turns elements() into a simple addition, with no
dereference. It is just returning the address of a field in a
structure whose address you pass in.
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gethost.java
Type: application/octet-stream
Size: 654 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040616/fc0c5132/attachment.obj>


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /