On Wed, Oct 18, 2017 at 5:04 PM, <brandon.e.jon...@gmail.com> wrote:
> Hello All,
>
> I have a multi-threaded application that embeds v8 and starts up quite a few
> isolates. Each isolate is locked by a global locker (not the same global
> locker, each has it's own) that works without issues...until I start
> profiling. When profiling is turned on it will eventually crash (at
> random-ish times) with either SEGV_ACCERR or SEGV_MAPERR. GDB has been
> virtually useless to find the exact problem (could just be my lack of
> understanding of GDB) but my instinct was telling me it had to do something
> with threading/lock issues. I've traced it all the way down to this line of
> code in Sampler.cc's DoSample function.
>
> void Sampler::DoSample() {
> if (!SignalHandler::Installed()) return;
> if (!IsActive() && !IsRegistered()) {
> SamplerManager::instance()->AddSampler(this);
> SetRegistered(true);
> }
> pthread_kill(platform_data()->vm_tid(), SIGPROF); //This line right here
> is causing me grief
> }
>
> This is as far as I traced it. If I comment out that one line, compile and
> run the application everything is stable again and it appears that the
> profiling is running smoothly on all isolates. I understand that the line is
> sending a signal to that vm_tid() thread (timeout?) but what is it actually
> trying to accomplish? What kind of hell did I open myself up to by
> commenting out that line? Would there be another alternative to this line
> that would make this more stable in a multi-threaded/multi-isolate
> environment?
>
> Looking for help from the pros here to understand.
>
> As a note I'm compiling using x64-release (and sometimes debug) on linux
> (Ubuntu 16.x).
>
> Thank You!
> -Brandon-
The CPU profiler works by sending SIGPROF signals at fixed intervals
from a helper thread to the thread executing JS code. The signal
handler then collects and stores the stack trace in that thread.
Is platform_data() a bad pointer? Did vm_tid() get corrupted somehow?
Or does the process crash in the JS thread? A backtrace and
disassembly + `info registers` of the offending code would be helpful.
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
