RE: gcj and UDP datagrams under freebsd

["Boehm, Hans" <hans_boehm at hp dot com>]

We had discussed dropping the three low order bits on some platforms instead
of just checking them in an assertion.  Apparently that never made it into
the code though?  That would be safe if you can guarantee that you never
acquire locks on addresses that aren't at least 8 bytes apart.

This problem should only occur if you are trying to synchronize on something
that isn't a heap allocated object.  Heap allocated objects should be 8-byte
aligned to start with.

Hans

> -----Original Message-----
> From: Loren James Rittle [mailto:rittle@latour.rsch.comm.mot.com]
> Sent: Friday, April 05, 2002 3:28 PM
> To: java@gcc.gnu.org
> Cc: mallman@grc.nasa.gov
> Subject: Re: gcj and UDP datagrams under freebsd
> 
> 
> Hi Mark,
> 
> [...]
> > % ./snd guns
> > assertion "!(addr & FLAGS)" failed: file
> > "/home/mallman/GCC/libjava/java/lang/natObject.cc", line 772
> > Bus error (core dumped) 
> 
> > This is on a freebsd 4.4 machine.
> 
> A few comments.  FYI, you will experience random GC deadlocks on
> FreeBSD 4.4 and all previous releases (unless you disable threads
> entirely when bootstrapping gcc).  Please upgrade to
> FreeBSD-4.5-RELEASE or FreeBSD-4.5-STABLE to use gcj.
> 
> However, that is not your problem here.
> 
> > I tried to same thing on my redhat 6.2 laptop (same version of gcc
> > that I grabbed from CVS a couple days ago) and it all worked as I
> > had envisioned.  (The difference is the I don't have to use
> > "-pthread" when compiling on the linux box.)
> 
> > Anyone have a guess about what is going on?  Any help would be
> > appreciated.
> 
> Yes, dear lord, this code is doing something *very* nasty with the low
> bits of pointers.  Luckily, it had this nice assert() instead of
> crashing wildly. ;-)
> 
> Compiling your code and running it, I see the same crash:
> 
> #2  0x2830b105 in _Jv_MonitorEnter (obj=0x285a8b8c)
> 
> with FLAGS == 7 and addr == obj, assert(!(addr & FLAGS));
> 
> Yup, that doesn't fly on this platform unless some care is used for
> all memory allocations.  Until we figure out how to fully address the
> situation, you could disable the hash synchronization code.  Drop this
> line:
> 
> enable_hash_synchronization_default=no
> 
> into the *-*-freebsd* section of the second case in
> libjava/configure.host and completely rebuild libjava (merely
> rerunning make after a reconfigure doesn't work in this case).
> 
> Since I doubt I will be able to fix this before 3.1 release, I think
> this should be disabled on the branch.  Funny that there were zero
> test cases to catch it.  I will try to work up such a case.
> 
> Regards,
> Loren
>