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

David Holmes david.holmes at oracle.com
Thu Apr 16 12:33:44 UTC 2015

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?

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 hs_err working again? Or file this under "well it seemed like a good idea"? ;-)

Cheers, David

Thanks, StefanK

Thanks, David

Thanks, StefanK

More information about the hotspot-dev mailing list