On Mon, 19 Jul 2021 07:07:04 GMT, Ludovic Henry wrote:
>> Hi Ludovic,
>>
>> Thank you for working on this long-standing bug.
>> I like the idea of the proposed solution, but unfortunately it cannot be
>> applied as is. Since the stack walking code runs inside a signal handler, it
>> is very li
On Wed, 30 Jun 2021 09:17:42 GMT, Serguei Spitsyn wrote:
>> Ludovic Henry has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix comments
>
> Hi Ludovic,
> You need two reviews including one (R)eviewer before integration of your fix.
> Than
On Sun, 11 Jul 2021 22:21:31 GMT, Andrei Pangin wrote:
>> Ludovic Henry has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix comments
>
> Hi Ludovic,
>
> Thank you for working on this long-standing bug.
> I like the idea of the proposed
On Fri, 18 Jun 2021 08:56:32 GMT, Ludovic Henry wrote:
>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime
>> stub (like arraycopy), a vtable stub, or the prolog of a compiled method,
>> it wouldn't be able to detect the sender (caller) frame for multiple
>> reasons.
On Fri, 18 Jun 2021 08:56:32 GMT, Ludovic Henry wrote:
>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime
>> stub (like arraycopy), a vtable stub, or the prolog of a compiled method,
>> it wouldn't be able to detect the sender (caller) frame for multiple
>> reasons.
> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime
> stub (like arraycopy), a vtable stub, or the prolog of a compiled method, it
> wouldn't be able to detect the sender (caller) frame for multiple reasons.
> This patch fixes these cases through adding CodeBlob-specific
