Segfault in CompiledMethod::is_unloading()

[Erik Österlund]

Hi Andrew,

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.

Thanks,
/Erik

On 2018-11-15 18:45, Andrew Haley wrote:
> I'm seeing a segfault at
> 
>    state_is_unloading = IsUnloadingBehaviour::current()->is_unloading(this);
> 
> because
> 
>    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
> is:
> 
>   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
> it.
>