OK, if you have more or less reliable way to reproduce the problem, please
file a bug at https://github.com/jvm-profiling-tools/async-profiler/issues
BTW, obj_size + tlab_size does not make sense, since tlab_size already
includes all objects allocated in TLAB.
понедельник, 12 февраля 2018 г., 20:20:54 UTC+3 пользователь Maxim
> I doubt that is the case (rewrite libasyncProfiler.dylib while the library
> is already loaded into the target process) ... It happens on developer
> machines (Mac), not production (Linux) - at least we don't see it in
> Production :)
> Are you sure log https://pastebin.com/kJptx2nA is not complete?
> I will try to enable it again for developers and ask them to send me more
> On Monday, February 12, 2018 at 5:53:25 PM UTC+2, Andrei Pangin wrote:
>> Hi Maxim,
>> Does it also fail with original unmodified libasyncProfiler? I guess you
>> rewrite libasyncProfiler.dylib while the library is already loaded into the
>> target process - can it be the case?
>> The crash log seems incomplete, I can't tell for sure what's wrong.
>> воскресенье, 11 февраля 2018 г., 9:46:33 UTC+3 пользователь Maxim
>> Terletsky написал:
>>> @Andrei Pangin
>>> Sometimes we saw the following exception thrown
>>> RDI=0x000000015a4e7110: _ZN11AllocTracer13signalHandlerEiP9__siginfoPv+0
>>> in /Users/....../libasyncProfiler.dylib at 0x000000015a4e6000
>>> The code, probably very familiar to you :) , is
>>> https://pastebin.com/CPmysehe - the only diff with the original is
>>> 1. u64 tlab_size = frame.arg1();
>>> 2. Profiler::_instance.recordSample(ucontext, obj_size + tlab_size,
>>> BCI_KLASS, alloc_class);
>>> which I added as you suggested.
>>> Do you know what could be the issue?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.