Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
> On Apr 29, 2020, at 1:56 PM, Robert Swindells wrote: > > > On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: >> >> I think this commit broke lang/oracle8-jre: > > Linux Java doesn't crash now for me but doesn't do much, top(1) shows it > to be waiting on a futex. > > Tried doing "java -version" and running larger things. "java -version" fails very intermittently for me. Or, rather, it fails once (gets stuck), and then after killing it with SIGKILL it no longer gets stuck when I try it again. Investigating. -- thorpej
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: > > I think this commit broke lang/oracle8-jre: Linux Java doesn't crash now for me but doesn't do much, top(1) shows it to be waiting on a futex. Tried doing "java -version" and running larger things.
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
> On Apr 28, 2020, at 4:25 PM, Robert Swindells wrote: > > Jason Thorpe wrote: >>> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: >>> >>> I think this commit broke lang/oracle8-jre: >> >> This is a Linux binary running under COMPAT_LINUX? It would be strange >> if it broke it because it essentially makes the whole system do what the >> Linux emulation was already doing. > > Has anything changed around where the initial stack gets put in VM ? > > The Linux build of OpenJDK uses this to work out whether it is using > the initial thread or another one. No. There were actually a few problems: - A mistake I made in the compat_linux futex syscall stub that redirects to the native. - A difference in how process lookup works between NetBSD and Linux that was accidentally removed when the LWP ID overhaul changes were made. - Some latent bugs in argument handling in some of the scheduling-related Linux syscalls. I'll check in fixes for these tonight. -- thorpej
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
Jason Thorpe wrote: >> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote: >> >> I think this commit broke lang/oracle8-jre: > >This is a Linux binary running under COMPAT_LINUX? It would be strange >if it broke it because it essentially makes the whole system do what the >Linux emulation was already doing. Has anything changed around where the initial stack gets put in VM ? The Linux build of OpenJDK uses this to work out whether it is using the initial thread or another one.
Re: Problem with Linux emulation [was Re: CVS commit: src/sys]
> On Apr 27, 2020, at 8:50 AM, Thomas Klausner wrote:
>
> I think this commit broke lang/oracle8-jre:
This is a Linux binary running under COMPAT_LINUX? It would be strange if it
broke it because it essentially makes the whole system do what the Linux
emulation was already doing.
I'll take a look.
>
> My test case is:
> $ ftp https://webstart.buergerkarte.at/PDF-Over/setup_pdf-over_linux.jar
> ...
> $ oracle8-java -jar setup_pdf-over_linux.jar
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (os_linux_x86.cpp:730), pid=9919, tid=0x7f7ff5f2b700
> # fatal error: pthread_getattr_np failed with errno = 3
> #
> # JRE version: (8.0_202-b08) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode
> linux-amd64 compressed oops)
> # Core dump written. Default location: /home/wiz/core or core.9919
> #
> # An error report file with more information is saved as:
> # /home/wiz/hs_err_pid9919.log
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
> [1] Abort trap (core dumped) /usr/pkg/java/oracle-8/bin/java "${@}"
>
> Thomas
-- thorpej
Problem with Linux emulation [was Re: CVS commit: src/sys]
On Fri, Apr 24, 2020 at 03:22:06AM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Fri Apr 24 03:22:06 UTC 2020
>
> Modified Files:
> src/sys/compat/linux/common: linux_exec.c linux_sched.c
> src/sys/kern: kern_exec.c kern_exit.c kern_fork.c kern_lwp.c
> kern_proc.c sys_lwp.c
> src/sys/sys: lwp.h proc.h
>
> Log Message:
> Overhaul the way LWP IDs are allocated. Instead of each LWP having it's
> own LWP ID space, LWP IDs came from the same number space as PIDs. The
> lead LWP of a process gets the PID as its LID. If a multi-LWP process's
> lead LWP exits, the PID persists for the process.
>
> In addition to providing system-wide unique thread IDs, this also lets us
> eliminate the per-process LWP radix tree, and some associated locks.
>
> Remove the separate "global thread ID" map added previously; it is no longer
> needed to provide this functionality.
>
> Nudged in this direction by ad@ and chs@.
I think this commit broke lang/oracle8-jre:
My test case is:
$ ftp https://webstart.buergerkarte.at/PDF-Over/setup_pdf-over_linux.jar
...
$ oracle8-java -jar setup_pdf-over_linux.jar
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:730), pid=9919, tid=0x7f7ff5f2b700
# fatal error: pthread_getattr_np failed with errno = 3
#
# JRE version: (8.0_202-b08) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode linux-amd64
compressed oops)
# Core dump written. Default location: /home/wiz/core or core.9919
#
# An error report file with more information is saved as:
# /home/wiz/hs_err_pid9919.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
[1] Abort trap (core dumped) /usr/pkg/java/oracle-8/bin/java "${@}"
Thomas
