Hello,
I'm trying to debug a native crash that regularly happens for one of our
customers.
It crashes somewhere amidst java interpreter code, with corrupted value
in CPU's RIP register. So it's quite complicated.
It would certainly help me a lot if I had access to jvm.pdb files for
Alan, thanks a lot for applying my patch!
Now, do I need to try and remove the magic from Unix process creation
code? Or you'd rather have it untouched?
I'm still puzzled by the Unix change. I completely agree with Martin
about CLOSEXEC but there is something fishy here that we need to get a
handle on. When we fork then we close >= 3 in the child so there
shouldn't be any magic with fd 3.
The current code closes >= 4. FD 3 is a special one
Please get Windows change applied. I'm mostly interested in this part,
because bug is currently hidden on Unix.
I'm still puzzled by the Unix change. I completely agree with Martin
about CLOSEXEC but there is something fishy here that we need to get a
handle on. When we fork then we close >=
I still need someone to get this patch applied. Please?
At this moment, it seems that patch is validated:
> Martin Buchholz
> But regardless of that, we should try to set the CLOEXEC bit on all
> our file descriptor
> Alan Bateman
> The update to osSupport_Windows.cpp looks okay.
> I'm hoping that JDK core libraries overall do a better job of reusing
> the code in e.g.
> src/hotspot/os/linux/os_linux:os::open
> somehow, that actually gets the CLOEXEC bit right.
os::open is exactly what was used in libjimage before the bug was
introduced. I already described it in my
I'm still only half paying attention, but I agree with Alexander that
the low-level infrastructure in libjimage is fishy. The rule should be
that file descriptors created by the JDK should have the CLOEXEC bit on.
But even if the CLOEXEC bit was forgotten, the subprocess code should
still
> The only surprise is that it doesn't close as it shouldn't need the
> file descriptor after it mmapped.
Indeed, both on Windows and Unix file descriptor can be closed after
mapping.
On the other hand, ImageFileReader is not prepared for that.
See
> STDERR_FILENO is 2 so I'm curious which error reporting pipe is bring
> discussed here.
We're discussing line 365 of childproc.c
http://hg.openjdk.java.net/jdk/jdk/file/8bdf2b5f472d/src/java.base/unix/native/libjava/childproc.c
> The update to osSupport_Windows.cpp looks okay. I think it would be
> useful to discuss the osSupport_unix.cpp change further as the
> childproc code is supported to close the file descriptors.
childproc code uses some dark magic to figure which files to close. At
the moment,
t it's a error pipe (FAIL_FILENO). Should the
bug in childProcess() be fixed, it can unearth currently fixed bug.
# HG changeset patch
# User Alexander Miloslavskiy <alexandr.miloslavs...@gmail.com>
# Date 1522703926 -10800
# Tue Apr 03 00:18:46 2018 +0300
# N
11 matches
Mail list logo
