From thomas.stuefe at gmail.com Mon Apr 3 17:54:13 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Apr 2017 19:54:13 +0200 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> Message-ID: Hi Dmitry, David, sorry for dropping the ball on this one. Here the latest version - I only fixed the cosmetics Dmitry requested: http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ Thanks for reviewing! 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. > From david.holmes at oracle.com Tue Apr 4 07:25:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Apr 2017 17:25:20 +1000 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> Message-ID: Hi Thomas, On 4/04/2017 3:54 AM, Thomas St?fe wrote: > Hi Dmitry, David, > > sorry for dropping the ball on this one. Here the latest version - I > only fixed the cosmetics Dmitry requested: > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ Looks okay. I'm a little unsure about only fixing this in the shared code for non-s390. But I guess we can deal with other platforms later. Thanks, David ----- > Thanks for reviewing! > > Kind Regards, Thomas > > On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff > > 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. > > From thomas.stuefe at gmail.com Tue Apr 4 07:32:55 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Apr 2017 09:32:55 +0200 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> Message-ID: Hi David, On Tue, Apr 4, 2017 at 9:25 AM, David Holmes wrote: > Hi Thomas, > > On 4/04/2017 3:54 AM, Thomas St?fe wrote: > >> Hi Dmitry, David, >> >> sorry for dropping the ball on this one. Here the latest version - I >> only fixed the cosmetics Dmitry requested: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wron >> g-pc-in-errorlogs/jdk10-webrev.02/webrev/ >> > > Looks okay. I'm a little unsure about only fixing this in the shared code > for non-s390. But I guess we can deal with other platforms later. > > Not sure what you mean, but a common solution for all posix platforms would be even easier. Instead of fixing the s390 signal handler and the secondary signal handler for all posix platforms, one could adjust the pc at the entry of error reporting, in VMError::report_and_die(). But that would require an #ifndef WIN32 and you guys frown upon ifdefs, so that is why I avoided this solution. But lets commit this solution, and if other platforms should ever have the same problem, we can modify the code. ..Thomas > Thanks, > David > ----- > > Thanks for reviewing! >> >> Kind Regards, Thomas >> >> On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff >> > 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-wron >> g-pc-in-errorlogs/jdk10-webrev.00/webrev/ >> > ng-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. >> >> >> From david.holmes at oracle.com Tue Apr 4 10:04:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Apr 2017 20:04:22 +1000 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> Message-ID: <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> On 4/04/2017 5:32 PM, Thomas St?fe wrote: > Hi David, > > On Tue, Apr 4, 2017 at 9:25 AM, David Holmes > wrote: > > Hi Thomas, > > On 4/04/2017 3:54 AM, Thomas St?fe wrote: > > Hi Dmitry, David, > > sorry for dropping the ball on this one. Here the latest version - I > only fixed the cosmetics Dmitry requested: > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > > > Looks okay. I'm a little unsure about only fixing this in the shared > code for non-s390. But I guess we can deal with other platforms later. > > > Not sure what you mean, but a common solution for all posix platforms > would be even easier. Instead of fixing the s390 signal handler and the > secondary signal handler for all posix platforms, one could adjust the > pc at the entry of error reporting, in VMError::report_and_die(). But > that would require an #ifndef WIN32 and you guys frown upon ifdefs, so > that is why I avoided this solution. Well there are frowns and there are frowns :) I don't like that the other platforms don't use si_addr too - seems the "right" way to get the pc and what would be done if writing the signal handler today. But then I also don't understand why handle_linux_signal is duplicated across CPU specific files! Maybe there are some subtle differences but it should be pretty OS specific rather than CPU specific. Anyway ... > But lets commit this solution, and if other platforms should ever have > the same problem, we can modify the code. ... lets proceed as is. Thanks, David > ..Thomas > > > Thanks, > David > ----- > > Thanks for reviewing! > > Kind Regards, Thomas > > On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff > > >> 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. > > > From thomas.stuefe at gmail.com Tue Apr 4 12:16:36 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Apr 2017 14:16:36 +0200 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> Message-ID: On Tue, Apr 4, 2017 at 12:04 PM, David Holmes wrote: > On 4/04/2017 5:32 PM, Thomas St?fe wrote: > >> Hi David, >> >> On Tue, Apr 4, 2017 at 9:25 AM, David Holmes > > wrote: >> >> Hi Thomas, >> >> On 4/04/2017 3:54 AM, Thomas St?fe wrote: >> >> Hi Dmitry, David, >> >> sorry for dropping the ball on this one. Here the latest version >> - I >> only fixed the cosmetics Dmitry requested: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wron >> g-pc-in-errorlogs/jdk10-webrev.02/webrev/ >> > ng-pc-in-errorlogs/jdk10-webrev.02/webrev/> >> >> >> Looks okay. I'm a little unsure about only fixing this in the shared >> code for non-s390. But I guess we can deal with other platforms later. >> >> >> Not sure what you mean, but a common solution for all posix platforms >> would be even easier. Instead of fixing the s390 signal handler and the >> secondary signal handler for all posix platforms, one could adjust the >> pc at the entry of error reporting, in VMError::report_and_die(). But >> that would require an #ifndef WIN32 and you guys frown upon ifdefs, so >> that is why I avoided this solution. >> > > Well there are frowns and there are frowns :) I don't like that the other > platforms don't use si_addr too - seems the "right" way to get the pc and > what would be done if writing the signal handler today. But then I also > don't understand why handle_linux_signal is duplicated across CPU specific > files! Maybe there are some subtle differences but it should be pretty OS > specific rather than CPU specific. > I agree. Would be a good subject for cleanup. > > Anyway ... > > But lets commit this solution, and if other platforms should ever have >> the same problem, we can modify the code. >> > > ... lets proceed as is. > Thanks! Could you please sponsor this? Thanks, Thomas > > Thanks, > David > > ..Thomas >> >> >> Thanks, >> David >> ----- >> >> Thanks for reviewing! >> >> Kind Regards, Thomas >> >> On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff >> > >> > >> >> 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-wron >> g-pc-in-errorlogs/jdk10-webrev.00/webrev/ >> > ng-pc-in-errorlogs/jdk10-webrev.00/webrev/> >> >> > ng-pc-in-errorlogs/jdk10-webrev.00/webrev/ >> > ng-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. >> >> >> >> From david.holmes at oracle.com Tue Apr 4 12:20:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Apr 2017 22:20:16 +1000 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> Message-ID: <2cfd86eb-b58d-9645-d105-ba688dd72288@oracle.com> Hi Thomas, Yes I can sponsor this. Cheers, David On 4/04/2017 10:16 PM, Thomas St?fe wrote: > > > On Tue, Apr 4, 2017 at 12:04 PM, David Holmes > wrote: > > On 4/04/2017 5:32 PM, Thomas St?fe wrote: > > Hi David, > > On Tue, Apr 4, 2017 at 9:25 AM, David Holmes > > >> wrote: > > Hi Thomas, > > On 4/04/2017 3:54 AM, Thomas St?fe wrote: > > Hi Dmitry, David, > > sorry for dropping the ball on this one. Here the latest > version - I > only fixed the cosmetics Dmitry requested: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > > > > > > Looks okay. I'm a little unsure about only fixing this in > the shared > code for non-s390. But I guess we can deal with other > platforms later. > > > Not sure what you mean, but a common solution for all posix > platforms > would be even easier. Instead of fixing the s390 signal handler > and the > secondary signal handler for all posix platforms, one could > adjust the > pc at the entry of error reporting, in > VMError::report_and_die(). But > that would require an #ifndef WIN32 and you guys frown upon > ifdefs, so > that is why I avoided this solution. > > > Well there are frowns and there are frowns :) I don't like that the > other platforms don't use si_addr too - seems the "right" way to get > the pc and what would be done if writing the signal handler today. > But then I also don't understand why handle_linux_signal is > duplicated across CPU specific files! Maybe there are some subtle > differences but it should be pretty OS specific rather than CPU > specific. > > > I agree. Would be a good subject for cleanup. > > > > Anyway ... > > But lets commit this solution, and if other platforms should > ever have > the same problem, we can modify the code. > > > ... lets proceed as is. > > > Thanks! Could you please sponsor this? > > Thanks, Thomas > > > > Thanks, > David > > ..Thomas > > > Thanks, > David > ----- > > Thanks for reviewing! > > Kind Regards, Thomas > > On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff > > > > > > >>> 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. > > > > From david.holmes at oracle.com Tue Apr 4 12:54:48 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Apr 2017 22:54:48 +1000 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: <2cfd86eb-b58d-9645-d105-ba688dd72288@oracle.com> References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> <2cfd86eb-b58d-9645-d105-ba688dd72288@oracle.com> Message-ID: Sorry Thomas but I'm seeing a test failure on linux-x64 in the runtime/ErrorHandling/SafeFetchInErrorHandlingTest Seems safefetch is not working: # # A fatal error has been detected by the Java Runtime Environment: Will test SafeFetch... [error occurred during error reporting (test safefetch in error handler), id 0xb] # # SIGSEGV (0xb) at pc=0x00007f078dd58582, pid=603, tid=604 I don't see this with a JDK9 build. Can you test it? I have to call it a night now. David On 4/04/2017 10:20 PM, David Holmes wrote: > Hi Thomas, > > Yes I can sponsor this. > > Cheers, > David > > On 4/04/2017 10:16 PM, Thomas St?fe wrote: >> >> >> On Tue, Apr 4, 2017 at 12:04 PM, David Holmes > > wrote: >> >> On 4/04/2017 5:32 PM, Thomas St?fe wrote: >> >> Hi David, >> >> On Tue, Apr 4, 2017 at 9:25 AM, David Holmes >> >> > >> wrote: >> >> Hi Thomas, >> >> On 4/04/2017 3:54 AM, Thomas St?fe wrote: >> >> Hi Dmitry, David, >> >> sorry for dropping the ball on this one. Here the latest >> version - I >> only fixed the cosmetics Dmitry requested: >> >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ >> >> >> >> >> >> >> > >> >> > >> >> >> >> Looks okay. I'm a little unsure about only fixing this in >> the shared >> code for non-s390. But I guess we can deal with other >> platforms later. >> >> >> Not sure what you mean, but a common solution for all posix >> platforms >> would be even easier. Instead of fixing the s390 signal handler >> and the >> secondary signal handler for all posix platforms, one could >> adjust the >> pc at the entry of error reporting, in >> VMError::report_and_die(). But >> that would require an #ifndef WIN32 and you guys frown upon >> ifdefs, so >> that is why I avoided this solution. >> >> >> Well there are frowns and there are frowns :) I don't like that the >> other platforms don't use si_addr too - seems the "right" way to get >> the pc and what would be done if writing the signal handler today. >> But then I also don't understand why handle_linux_signal is >> duplicated across CPU specific files! Maybe there are some subtle >> differences but it should be pretty OS specific rather than CPU >> specific. >> >> >> I agree. Would be a good subject for cleanup. >> >> >> >> Anyway ... >> >> But lets commit this solution, and if other platforms should >> ever have >> the same problem, we can modify the code. >> >> >> ... lets proceed as is. >> >> >> Thanks! Could you please sponsor this? >> >> Thanks, Thomas >> >> >> >> Thanks, >> David >> >> ..Thomas >> >> >> Thanks, >> David >> ----- >> >> Thanks for reviewing! >> >> Kind Regards, Thomas >> >> On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff >> > >> > > >> > >> >> > >>> 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. >> >> >> >> From thomas.stuefe at gmail.com Tue Apr 4 13:06:46 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Apr 2017 15:06:46 +0200 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> <2cfd86eb-b58d-9645-d105-ba688dd72288@oracle.com> Message-ID: On Tue, Apr 4, 2017 at 2:54 PM, David Holmes wrote: > Sorry Thomas but I'm seeing a test failure on linux-x64 in the > runtime/ErrorHandling/SafeFetchInErrorHandlingTest > > Seems safefetch is not working: > > # > # A fatal error has been detected by the Java Runtime Environment: > Will test SafeFetch... > > [error occurred during error reporting (test safefetch in error handler), > id 0xb] > > # > # SIGSEGV (0xb) at pc=0x00007f078dd58582, pid=603, tid=604 > > > I don't see this with a JDK9 build. Can you test it? > > Oops. Yes, sure! .. Thomas > I have to call it a night now. > > David > > > On 4/04/2017 10:20 PM, David Holmes wrote: > >> Hi Thomas, >> >> Yes I can sponsor this. >> >> Cheers, >> David >> >> On 4/04/2017 10:16 PM, Thomas St?fe wrote: >> >>> >>> >>> On Tue, Apr 4, 2017 at 12:04 PM, David Holmes >> > wrote: >>> >>> On 4/04/2017 5:32 PM, Thomas St?fe wrote: >>> >>> Hi David, >>> >>> On Tue, Apr 4, 2017 at 9:25 AM, David Holmes >>> >>> >> >> wrote: >>> >>> Hi Thomas, >>> >>> On 4/04/2017 3:54 AM, Thomas St?fe wrote: >>> >>> Hi Dmitry, David, >>> >>> sorry for dropping the ball on this one. Here the latest >>> version - I >>> only fixed the cosmetics Dmitry requested: >>> >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wron >>> g-pc-in-errorlogs/jdk10-webrev.02/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.02/webrev/> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.02/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.02/webrev/>> >>> >>> >>> >>> Looks okay. I'm a little unsure about only fixing this in >>> the shared >>> code for non-s390. But I guess we can deal with other >>> platforms later. >>> >>> >>> Not sure what you mean, but a common solution for all posix >>> platforms >>> would be even easier. Instead of fixing the s390 signal handler >>> and the >>> secondary signal handler for all posix platforms, one could >>> adjust the >>> pc at the entry of error reporting, in >>> VMError::report_and_die(). But >>> that would require an #ifndef WIN32 and you guys frown upon >>> ifdefs, so >>> that is why I avoided this solution. >>> >>> >>> Well there are frowns and there are frowns :) I don't like that the >>> other platforms don't use si_addr too - seems the "right" way to get >>> the pc and what would be done if writing the signal handler today. >>> But then I also don't understand why handle_linux_signal is >>> duplicated across CPU specific files! Maybe there are some subtle >>> differences but it should be pretty OS specific rather than CPU >>> specific. >>> >>> >>> I agree. Would be a good subject for cleanup. >>> >>> >>> >>> Anyway ... >>> >>> But lets commit this solution, and if other platforms should >>> ever have >>> the same problem, we can modify the code. >>> >>> >>> ... lets proceed as is. >>> >>> >>> Thanks! Could you please sponsor this? >>> >>> Thanks, Thomas >>> >>> >>> >>> Thanks, >>> David >>> >>> ..Thomas >>> >>> >>> Thanks, >>> David >>> ----- >>> >>> Thanks for reviewing! >>> >>> Kind Regards, Thomas >>> >>> On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff >>> >> >>> >> > >>> >> >>> >>> >> >>> 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-wron >>> g-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/>> >>> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-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. >>> >>> >>> >>> >>> From thomas.stuefe at gmail.com Tue Apr 4 14:03:16 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 4 Apr 2017 16:03:16 +0200 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> <2cfd86eb-b58d-9645-d105-ba688dd72288@oracle.com> Message-ID: Hi David, what a stupid bug! I think I must have accidentally tested an older version. // support safefetch faults in error handling ucontext_t* const uc = (ucontext_t*) ucVoid; - address pc = (uc == NULL) ? os::Posix::ucontext_get_pc(uc) : NULL; + address pc = (uc != NULL) ? os::Posix::ucontext_get_pc(uc) : NULL; :-/ http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.03/webrev/ Kind Regards, Thomas On Tue, Apr 4, 2017 at 2:54 PM, David Holmes wrote: > Sorry Thomas but I'm seeing a test failure on linux-x64 in the > runtime/ErrorHandling/SafeFetchInErrorHandlingTest > > Seems safefetch is not working: > > # > # A fatal error has been detected by the Java Runtime Environment: > Will test SafeFetch... > > [error occurred during error reporting (test safefetch in error handler), > id 0xb] > > # > # SIGSEGV (0xb) at pc=0x00007f078dd58582, pid=603, tid=604 > > > I don't see this with a JDK9 build. Can you test it? > > I have to call it a night now. > > David > > > On 4/04/2017 10:20 PM, David Holmes wrote: > >> Hi Thomas, >> >> Yes I can sponsor this. >> >> Cheers, >> David >> >> On 4/04/2017 10:16 PM, Thomas St?fe wrote: >> >>> >>> >>> On Tue, Apr 4, 2017 at 12:04 PM, David Holmes >> > wrote: >>> >>> On 4/04/2017 5:32 PM, Thomas St?fe wrote: >>> >>> Hi David, >>> >>> On Tue, Apr 4, 2017 at 9:25 AM, David Holmes >>> >>> >> >> wrote: >>> >>> Hi Thomas, >>> >>> On 4/04/2017 3:54 AM, Thomas St?fe wrote: >>> >>> Hi Dmitry, David, >>> >>> sorry for dropping the ball on this one. Here the latest >>> version - I >>> only fixed the cosmetics Dmitry requested: >>> >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wron >>> g-pc-in-errorlogs/jdk10-webrev.02/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.02/webrev/> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.02/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.02/webrev/>> >>> >>> >>> >>> Looks okay. I'm a little unsure about only fixing this in >>> the shared >>> code for non-s390. But I guess we can deal with other >>> platforms later. >>> >>> >>> Not sure what you mean, but a common solution for all posix >>> platforms >>> would be even easier. Instead of fixing the s390 signal handler >>> and the >>> secondary signal handler for all posix platforms, one could >>> adjust the >>> pc at the entry of error reporting, in >>> VMError::report_and_die(). But >>> that would require an #ifndef WIN32 and you guys frown upon >>> ifdefs, so >>> that is why I avoided this solution. >>> >>> >>> Well there are frowns and there are frowns :) I don't like that the >>> other platforms don't use si_addr too - seems the "right" way to get >>> the pc and what would be done if writing the signal handler today. >>> But then I also don't understand why handle_linux_signal is >>> duplicated across CPU specific files! Maybe there are some subtle >>> differences but it should be pretty OS specific rather than CPU >>> specific. >>> >>> >>> I agree. Would be a good subject for cleanup. >>> >>> >>> >>> Anyway ... >>> >>> But lets commit this solution, and if other platforms should >>> ever have >>> the same problem, we can modify the code. >>> >>> >>> ... lets proceed as is. >>> >>> >>> Thanks! Could you please sponsor this? >>> >>> Thanks, Thomas >>> >>> >>> >>> Thanks, >>> David >>> >>> ..Thomas >>> >>> >>> Thanks, >>> David >>> ----- >>> >>> Thanks for reviewing! >>> >>> Kind Regards, Thomas >>> >>> On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff >>> >> >>> >> > >>> >> >>> >>> >> >>> 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-wron >>> g-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/>> >>> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/> >>> >>> >>> >>> >> ng-pc-in-errorlogs/jdk10-webrev.00/webrev/ >>> >>> >>> >> ng-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. >>> >>> >>> >>> >>> From david.holmes at oracle.com Tue Apr 4 20:33:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Apr 2017 06:33:09 +1000 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> <2cfd86eb-b58d-9645-d105-ba688dd72288@oracle.com> Message-ID: <68e7eb57-d346-84fc-a62f-d9ee449ecca4@oracle.com> On 5/04/2017 12:03 AM, Thomas St?fe wrote: > Hi David, > > what a stupid bug! I think I must have accidentally tested an older version. > > // support safefetch faults in error handling > ucontext_t* const uc = (ucontext_t*) ucVoid; > - address pc = (uc == NULL) ? os::Posix::ucontext_get_pc(uc) : NULL; > + address pc = (uc != NULL) ? os::Posix::ucontext_get_pc(uc) : NULL; > > :-/ > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.03/webrev/ Ouch! Three sets of eyes missed that :( Pushing changes now. Thanks, David > Kind Regards, Thomas > > > On Tue, Apr 4, 2017 at 2:54 PM, David Holmes > wrote: > > Sorry Thomas but I'm seeing a test failure on linux-x64 in the > runtime/ErrorHandling/SafeFetchInErrorHandlingTest > > Seems safefetch is not working: > > # > # A fatal error has been detected by the Java Runtime Environment: > Will test SafeFetch... > > [error occurred during error reporting (test safefetch in error > handler), id 0xb] > > # > # SIGSEGV (0xb) at pc=0x00007f078dd58582, pid=603, tid=604 > > > I don't see this with a JDK9 build. Can you test it? > > I have to call it a night now. > > David > > > On 4/04/2017 10:20 PM, David Holmes wrote: > > Hi Thomas, > > Yes I can sponsor this. > > Cheers, > David > > On 4/04/2017 10:16 PM, Thomas St?fe wrote: > > > > On Tue, Apr 4, 2017 at 12:04 PM, David Holmes > > >> wrote: > > On 4/04/2017 5:32 PM, Thomas St?fe wrote: > > Hi David, > > On Tue, Apr 4, 2017 at 9:25 AM, David Holmes > > > > > >>> wrote: > > Hi Thomas, > > On 4/04/2017 3:54 AM, Thomas St?fe wrote: > > Hi Dmitry, David, > > sorry for dropping the ball on this one. > Here the latest > version - I > only fixed the cosmetics Dmitry requested: > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > > > > > > > > > > > >> > > > > Looks okay. I'm a little unsure about only > fixing this in > the shared > code for non-s390. But I guess we can deal with > other > platforms later. > > > Not sure what you mean, but a common solution for > all posix > platforms > would be even easier. Instead of fixing the s390 > signal handler > and the > secondary signal handler for all posix platforms, > one could > adjust the > pc at the entry of error reporting, in > VMError::report_and_die(). But > that would require an #ifndef WIN32 and you guys > frown upon > ifdefs, so > that is why I avoided this solution. > > > Well there are frowns and there are frowns :) I don't > like that the > other platforms don't use si_addr too - seems the > "right" way to get > the pc and what would be done if writing the signal > handler today. > But then I also don't understand why handle_linux_signal is > duplicated across CPU specific files! Maybe there are > some subtle > differences but it should be pretty OS specific rather > than CPU > specific. > > > I agree. Would be a good subject for cleanup. > > > > Anyway ... > > But lets commit this solution, and if other > platforms should > ever have > the same problem, we can modify the code. > > > ... lets proceed as is. > > > Thanks! Could you please sponsor this? > > Thanks, Thomas > > > > Thanks, > David > > ..Thomas > > > Thanks, > David > ----- > > Thanks for reviewing! > > Kind Regards, Thomas > > On Sun, Mar 26, 2017 at 12:22 PM, Dmitry > Samersoff > > > > > >> > > > > > > >>>> 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. > > > > > From thomas.stuefe at gmail.com Wed Apr 5 00:13:43 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 05 Apr 2017 00:13:43 +0000 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: <68e7eb57-d346-84fc-a62f-d9ee449ecca4@oracle.com> References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> <93c05d2b-a207-eafc-17ba-28fe32084b55@oracle.com> <2cfd86eb-b58d-9645-d105-ba688dd72288@oracle.com> <68e7eb57-d346-84fc-a62f-d9ee449ecca4@oracle.com> Message-ID: On Tue, 4 Apr 2017 at 22:33, David Holmes wrote: > On 5/04/2017 12:03 AM, Thomas St?fe wrote: > > Hi David, > > > > what a stupid bug! I think I must have accidentally tested an older > version. > > > > // support safefetch faults in error handling > > ucontext_t* const uc = (ucontext_t*) ucVoid; > > - address pc = (uc == NULL) ? os::Posix::ucontext_get_pc(uc) : NULL; > > + address pc = (uc != NULL) ? os::Posix::ucontext_get_pc(uc) : NULL; > > > > :-/ > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.03/webrev/ > > Ouch! Three sets of eyes missed that :( > > Pushing changes now. > > Thanks, > David > Thanks, David! > > Kind Regards, Thomas > > > > > > On Tue, Apr 4, 2017 at 2:54 PM, David Holmes > > wrote: > > > > Sorry Thomas but I'm seeing a test failure on linux-x64 in the > > runtime/ErrorHandling/SafeFetchInErrorHandlingTest > > > > Seems safefetch is not working: > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > Will test SafeFetch... > > > > [error occurred during error reporting (test safefetch in error > > handler), id 0xb] > > > > # > > # SIGSEGV (0xb) at pc=0x00007f078dd58582, pid=603, tid=604 > > > > > > I don't see this with a JDK9 build. Can you test it? > > > > I have to call it a night now. > > > > David > > > > > > On 4/04/2017 10:20 PM, David Holmes wrote: > > > > Hi Thomas, > > > > Yes I can sponsor this. > > > > Cheers, > > David > > > > On 4/04/2017 10:16 PM, Thomas St?fe wrote: > > > > > > > > On Tue, Apr 4, 2017 at 12:04 PM, David Holmes > > > > > >> wrote: > > > > On 4/04/2017 5:32 PM, Thomas St?fe wrote: > > > > Hi David, > > > > On Tue, Apr 4, 2017 at 9:25 AM, David Holmes > > > > > > > > > > > > > >>> wrote: > > > > Hi Thomas, > > > > On 4/04/2017 3:54 AM, Thomas St?fe wrote: > > > > Hi Dmitry, David, > > > > sorry for dropping the ball on this one. > > Here the latest > > version - I > > only fixed the cosmetics Dmitry requested: > > > > > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > >> > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > >>> > > > > > > > > Looks okay. I'm a little unsure about only > > fixing this in > > the shared > > code for non-s390. But I guess we can deal with > > other > > platforms later. > > > > > > Not sure what you mean, but a common solution for > > all posix > > platforms > > would be even easier. Instead of fixing the s390 > > signal handler > > and the > > secondary signal handler for all posix platforms, > > one could > > adjust the > > pc at the entry of error reporting, in > > VMError::report_and_die(). But > > that would require an #ifndef WIN32 and you guys > > frown upon > > ifdefs, so > > that is why I avoided this solution. > > > > > > Well there are frowns and there are frowns :) I don't > > like that the > > other platforms don't use si_addr too - seems the > > "right" way to get > > the pc and what would be done if writing the signal > > handler today. > > But then I also don't understand why handle_linux_signal > is > > duplicated across CPU specific files! Maybe there are > > some subtle > > differences but it should be pretty OS specific rather > > than CPU > > specific. > > > > > > I agree. Would be a good subject for cleanup. > > > > > > > > Anyway ... > > > > But lets commit this solution, and if other > > platforms should > > ever have > > the same problem, we can modify the code. > > > > > > ... lets proceed as is. > > > > > > Thanks! Could you please sponsor this? > > > > Thanks, Thomas > > > > > > > > Thanks, > > David > > > > ..Thomas > > > > > > Thanks, > > David > > ----- > > > > Thanks for reviewing! > > > > Kind Regards, Thomas > > > > On Sun, Mar 26, 2017 at 12:22 PM, Dmitry > > Samersoff > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >>>> 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/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > >> > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > >>> > > > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > >> > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > > > > > > > < > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.00/webrev/ > > < > 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. > > > > > > > > > > > From dmitry.samersoff at oracle.com Tue Apr 4 07:56:25 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 04 Apr 2017 07:56:25 -0000 Subject: (jdk10) RFR(xxs): 8176872: [s390] wrong pc shown in error logs In-Reply-To: References: <65206847-05fb-0d37-2594-a301320055b9@oracle.com> Message-ID: <3befa8ce-84cf-e19b-9464-f8100dca5218@oracle.com> Thomas, Looks good to me! -Dmitry On 2017-04-03 20:54, Thomas St?fe wrote: > Hi Dmitry, David, > > sorry for dropping the ball on this one. Here the latest version - I > only fixed the cosmetics Dmitry requested: > > http://cr.openjdk.java.net/~stuefe/webrevs/8176872-s390-wrong-pc-in-errorlogs/jdk10-webrev.02/webrev/ > > Thanks for reviewing! > > Kind Regards, Thomas > > On Sun, Mar 26, 2017 at 12:22 PM, Dmitry Samersoff > > 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. > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.