8065585: Change ShouldNotReachHere() to never return (original) (raw)

Stefan Karlsson stefan.karlsson at oracle.com
Thu Apr 16 13:32:32 UTC 2015

On 2015-04-16 14:33, David Holmes wrote:

Hi Stefan,

trimming ... On 16/04/2015 10:07 PM, Stefan Karlsson wrote: On 2015-04-16 04:23, David Holmes wrote:

Second, more important question: have you examined how this attribute affects the ability to walk the stack? We have already seen issues on some platforms where library functions, like abort(), have the noreturn attribute and as a result the call is optimized in a way that prevents the stack from being walked - see eg:

https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276

though this: https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729 suggests that problem may have been addressed by the libc folk. But it still raises the question as to how our own noreturn functions will be handled and how they will affect stacktrace generation in hserr logs or via gdb. I added a call to fatal(...) in the GC code. I get correct stacktraces in gdb, but the stacktraces in the hserr files are broken with fastdebug and product builds: Which platforms?

On Linux x86 and x86_64.

Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0, free space=1019k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11db44a] VMError::reportanddie()+0x1ba V [libjvm.so+0x7efb80] reportvmerror(char const*, int, char const*, char const*)+0x90 V [libjvm.so+0x7efc49] reportvmerrornoreturn(char const*, int, char const*, char const*)+0x9 V [libjvm.so+0x7efc63] V [libjvm.so+0xfd7937] V [libjvm.so+0xfeec51] ... So what is the plan: try to get hserr working again? Or file this under "well it seemed like a good idea"? ;-)

I'm leaning towards "seemed like a good idea", unless someone has an easy fix for these problems.

Thanks, StefanK

Cheers, David

Thanks, StefanK

Thanks, David Thanks, StefanK

More information about the hotspot-dev mailing list