(jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs

Thomas Stüfe thomas.stuefe at gmail.com
Mon Mar 27 08:24:10 UTC 2017


Hi Dmitry, David,

Alternative suggestion: We could fix it in vmError.cpp for all posix
platforms. In our codebase we have done this, surrounded by "#ifndef
_WIN32". That would fix the issue for error handling on all posix
platforms. If a platform needs to handle this elsewhere (probably in signal
handling), they can do it their own way in the platform-dependend signal
handler - like s390 does today already.

What do you think?

I originally did not suggest this because I know you guys hate "#ifdefs" in
shared coding.

Kind Regards, Thomas

On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff <
dmitry.samersoff at oracle.com> wrote:

> Thomas,
>
> Looks good to me,
>
> We may consider to always use info->si_addr.
>
> Nits:
>
> vmError_posix.cpp
>
> 118:
>   Please change uc ? ... to   (uc == NULL) ? ...
>
> 122: (and os_linux_s390.cpp:513)
>
>   Space missed after (address) ...
>
>
> -Dmitry
>
>
> On 2017-03-21 16:40, Thomas Stüfe wrote:
> > Hi all,
> >
> > please take a look at this tiny fix. It fixes the pc shown as faulting
> > address for SIGILL and SIGFPE in hs_err files.
> >
> > https://bugs.openjdk.java.net/browse/JDK-8176872
> > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-
> wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/
> >
> > When determining the crash pc, in all posix platform signal handlers pc
> is
> > taken from the context. However, context.pc on zlinux points to the
> > instruction *after* the faulting op. The correct way, according to POSIX,
> > would be to take the address from siginfo_t->si_addr for signals SIGILL,
> > SIGFPE.
> >
> > (actually, this patch would make sense for all POSIX platforms, but only
> > s390 seems to show this error, so I leave the patch local to s390.)
> >
> > Kind Regards, Thomas
> >
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
>


More information about the hotspot-runtime-dev mailing list