RFR: JDK-8059586: hs_err report should treat redirected core pattern.

[Yasumasa Suenaga]

Hi Thomas, David,

Sorry, I didn't think about async signal safety.

> That would work, VmError::report_and_die() is singlethreaded. At least the part which dumps out the core file name.

I think that signal handler (in this case) may run concurrency with
other thread.
If another thread calls malloc(3) in JNI, C Heap corruption may occur.

I want to rewrite a patch as below:

  - Use async signal safety functions.
    fopen -> open, fgets -> read, etc.

  - Use O_BUFLEN for buffer size.
    O_BUFLEN is defined to 2000 in ostream.hpp .
    This macro is used in various points. VMError::coredump_message is
    also defined with this value.

What do you think about this plan?


Thanks,

Yasumasa


(2014/12/01 16:53), Thomas Stüfe wrote:
>
>
> On Mon, Dec 1, 2014 at 8:26 AM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>     On 1/12/2014 5:18 PM, Thomas Stüfe wrote:
>
>         David, Yasumasa,
>
>              Thanks. The formatting needs fixing up though, the p should line up
>              with buffer.
>
>              I'm concerned by the changes in os_linux.cpp and os_posix.cpp to use
>              os::malloc. If this is being called from a signal handler there's a
>              real risk of deadlock if we try to use malloc/free. I know Thomas
>              suggested this (and sorry I didn't notice it then) but I don't think
>              it is a good idea for the crash handler.
>
>
>         Correct. Sorry, my fault, I was not clear enough. I meant for you to use
>         the pure malloc(3), not os::malloc.
>
>
>     I was thinking both may be undesirable. I think my conservatism dial is up higher than yours :) Let's see what Staffan (or others) thinks. Perhaps a static buffer rather than either malloc or stack based?
>
>
> That would work, VmError::report_and_die() is singlethreaded. At least the part which dumps out the core file name.
>
> Another way would be to pre-calc the path at startup, in os::init() maybe. You run the risk of the pattern changing during the lifetime of the process though, but I guess that does not happen often.
>
> But lets others decide. Too many ways to do this :)
>
> Kind Regards, Thomas
>