Segfault in CompiledMethod::is_unloading()
erik.osterlund at oracle.com
Fri Nov 16 12:51:24 UTC 2018
The assumption is that UnloadingBehaviour::_current should not need to
be called outside of safepoints (unless you have a concurrently
unloading collector), as the value of the computation should have been
computed when we release the safepoint, as all compiled methods should
have been walked during code cache unloading.
By the look of it, the fact that you are crashing there means that it
was not been visited for your AoT method, and when the sweeper tries
calling it, it needs to compute the value and has no means of doing that
any longer (it should already have been computed). I guess I must have
messed up the assumption that all compiled methods are walked during
code cache unloading in the case of AoT. Sorry about that.
On 2018-11-15 18:45, Andrew Haley wrote:
> I'm seeing a segfault at
> state_is_unloading = IsUnloadingBehaviour::current()->is_unloading(this);
> IsUnloadingBehaviour::_current == NULL
> I see IsUnloadingBehaviour::set_current called earlier by the VM thread
> with NULL as its argument.
> Should this segfault be impossible? If so, why?
> _is_unloading_state == 4 at this point.
> Surely we should check that sUnloadingBehaviour::_current != NULL
> before calling it?
> The method being processed by NMethodSweeper::process_compiled_method
> 755674 12888 aot[ 1] jdk.internal.reflect.Label.add(Ljdk/internal/reflect/ClassFileAssembler;SSI)V AOTCompiledMethod
> This is a complex and hard-to-reproduce test case, so if anyone
> can give me a clue about what's supposed to happen I'd appreciate
More information about the hotspot-gc-dev