JDK-8159700 : bigapps/Kitchensink/modulePostprocess fails in nightly run
Type:Bug
Component:hotspot
Sub-Component:compiler
Affected Version:9
Priority:P2
Status:Closed
Resolution:Duplicate
Submitted:2016-06-16
Updated:2016-08-02
Resolved:2016-08-02
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
bigapps/Kitchensink/modulePostprocess fails in hs-dev nightly run
Comments
I think all the older failures have been explained by other bugs.
The recent matches seem to be because of 8159257 and 8159760. Closing this as a duplicate.
02-08-2016
Some of the recent matches are caused by 8159257.
02-08-2016
Deadlock with JFR has been fixed.
Assigning this to compiler team if you want to follow up regarding compiler information.
02-08-2016
Hi Rahul, this is not an integration blocker anymore. Can you please keep track of this issue? Thanks! Best regards, Zoltan
30-06-2016
signal 6 is SIGABRT - the VM does not handle SIGABRT, so no hs-err file if that is generated externally. Internally we should not abort() until after hs_err log is dumped.
28-06-2016
Do these recent crashes contain the fix for JDK-8139379? For SIGSEGV crashes, I would suspect JDK-8139379 as the cause.
27-06-2016
This is not a dup of JDK-8159876. JDK-8159876 is just causing us to hit a deadlock when trying to produce the hs_err file. The real issue with this CR is the SIGILL.
27-06-2016
Is this run affected by the JFR shutdown deadlock problem?
24-06-2016
Is that showing a recursive call into the SR_handler? That would certainly be suspicious. Anything with the SR_handler involved is suspicious by definition :) It would be interesting to see the remainder of the stack for that thread.
24-06-2016
I checked the {NMT|Jrcmd}PickerModule.err files for ~15 of the failures that have appeared in June 2016. None of these files have the exceptions reported by you above (except the failure on 2016-06-14).
Regarding the older failures: The binaries are not available for them, so it's hard to decipher anything from the core files.
Yes, I've noticed JDK-8159760.
24-06-2016
The lack of a hs_err file is a new issue, only a week or two old (and fixed yesterday I believe), so I don't think those older failures are the same if they did not produce an hs_err file. Did you check to see if NMTPickerModule.err and JrcmdPickerModule.err have the exceptions listed in the 3rd comment above? I think you should look verify that at least one of the older core files is the same type of crash, and the .err files have the same exception, before making the determination that this is not a new problem.
BTW, JDK-8159760 also matches this same failure. I think the "Unknown failures: JfrExternal Jrcmd NMT" failure rule is somewhat generic, and any number of failures can result in this message.
23-06-2016
Hi Rahul, Can you please keep track of this issue? It would be interested to see if the problem appears again, and if yes, does it appear on other machines as well or it appears only on the machine where it originally appears. Thank you! Best regards, Zoltan
22-06-2016
There is another thread getting a SEGV on that address, and that thread is doing a GC poll, so I think it's a stale value and SIGILL doesn't bother to clear the fault_address field. info->si_addr contains the PC as expected.
21-06-2016
Do you think the fault_address field is a clue? I can't find any info on what it suppose to contain. For a SIGILL, I would expect it is the address of the illegal instruction, but that does not seem to be the case here. It's not an accessible address. If you run pmap from jhsdb, it shows it to be an address just above all the dlls.
21-06-2016
The deadlock risk associated with the fix for JDK-8158033 was raised during the code review.
20-06-2016
From the kitchensink process:
[stress.process.err] # [ timer expired, abort... ]