Re: devel/jdk status?

[Niklas Hallqvist <niklas@copper.appli.se>]

I am pretty sure I know the reason for jdk-1.3.1 failing with redhat 8
libs.  It's quite a bit involved to explain so suffice to say that to
fix this correctly we need to perfect our Linux emulation somewhat.

My guess is that NetBSD has alreday done this, but I have not checked.

What needs to be done is very likely to fix the brk(2) syscall to
return the actual break-value coming from userland in all cases.  Now
we instead return a page-aligned variant when brk(2) is called with a
an erroneous argument.  This confuses java's internal malloc routine,
which goes into some fence-posting codepath, as it suspects foreign
sbrk calls (w.r.t. the malloc implementation) to have happened, which
does recursive malloc/free calls, which is checked for by another
sanity feature :-).  I'd say that the malloc implementation is buggy,
but we cannot change that in this scenario.

This is all just figured out by reading code, but a similar problem
crept up in NetBSD/ppc some time ago, I found out after figuring it
all out and got to know what to google for :-) On NetBSD/ppc it
happened to result in unaligned memory-references which caused a more
immediate death, easier to debug.

Right now I am quite stressed out so if anyone wants to jump the gun in
providing a fix, please do.  what needs to be done is to introduce an
opaque emulation data pointer in struct proc, struct mdproc or struct
vmspace.  The linux specific structure this will point to, will need
to have a cached break value, as given by the user at the last break
call.  Of course fork(2) will need to call an emulation hook unless
there is already one there, as will exit(2).

Good start for a kernel hacker wannabe.  Send me your proposed fix and
I'll review and test it for free ;-)

Niklas

PS, check NetBSD if there is any prior art...