RFR (S): 8237777 "Dumping core ..." is shown despite claiming that "# No core dump will be written."

David Holmes david.holmes at oracle.com
Tue Apr 21 02:12:43 UTC 2020

Hi Gerard,

On 21/04/2020 4:33 am, gerard ziemski wrote:
> hi all,
> Please review this fix, where we use the knowledge available to us, like 
> whether the ulimit is set, before deciding whether to tell the user in 
> hs_err crash log that we dumped the core file, to match what actually 
> happens.
> Before this fix, we often assumed that the core file would be created, 
> when in actuality that might not be the case.

General approach seems fine but some comments below ...

> I also extend an existing test to go with this fix.
> bug: https://bugs.openjdk.java.net/browse/JDK-8237777
> webrev: http://cr.openjdk.java.net/~gziemski/8237777_rev1
> tests:  tested with Mach5 tier-hs1,2,3,4,5

I'm not quite following all of the changes in relation to what gets printed:


-                             "\"%s\" (or dumping to %s/core.%d)",
-                             &core_pattern[1], p, current_process_id());
+                             "\"%s\", or dumping to %s/core",
+                             &core_pattern[1], p);

why did you change the pattern? I get core files of the form core.<pid> 
on my linux box.


Why did you move the ifdef linux case? What if I don't have infinite 
stack limit?

The printing logic was examined in detail under JDK-8059586: hs_err 
report should treat redirected core pattern:




Typo: core_dump_ppossible  (double p)



!     public static void main(String[] args) throws Exception, Throwable {

Exception is redundant now you have added Throwable. But if you change 
runTest() to throws Exception then you don't need Throwable. But the 
overload of runTest() seems a bit awkward. I'd just add the new tests 
directly to main.


> cheers

More information about the hotspot-runtime-dev mailing list