So I'm having this issue where I turn on CPU Profiler and it eventually crashes the system with either *SEGV_MAPERR or SEGV_ACCERR. *I cannot seem to get past this or figure out where it's actually all going wrong. I've dived into the v8 profiling code and can't seem to find the issue.
Assumptions: First off, my assumption is that the CPU Profiler in V8 version 6+ is now at the Isolate level since I need an isolate to instantiate a CpuProfiler. So if I had, let's say, 20 isolates running and turned on CPU Profiler (StartProfiling) on all 20 at the same time I should get results from each isolate when turning off respectively (StopProfiling which returns the CpuProfile data). Obviously if I turn on --prof I'll get 20 log files, one for each isolate which also confirms this assumption. Details on Threading: Each isolate is running with a global locker on each. Each isolate is being entered by another, dedicated, thread. So Thread 1 enters Isolate 1 and that is the only thread that hits Isolate 1 so one global locker there. Thread 2 enters isolate 2..etc. This setup works like a charm with no issues...until I turn on profiling (StartProfiling)...then it all goes down in flames. With StartProfiling off the system is very stable. At first I thought it might be because I'm using a global locker upon entering the isolate for the first time (only one thread per isolate enters it throughout the life of the program) and it could be some kind of threading problem with lockers. Unfortunately that doesn't seem to make sense because if I run the app with 1 isolate only with CPU Profiling on it runs just fine. It's only when I spin up more isolates and turn on CPU Profiling that I get the issue. 20 isolates seem to be the sweet spot for guaranteed failure but it will definitely crash using 2. So I'm wondering if there is some kind of limitation to CPU Profiling at the isolate level for multiple isolates at the same time or if it's tripping over each other in the sampling process. I've tried running a core dump through GDB but it's just showing crashes at random areas depending on where the process was at when it crashed. So basically I'm picking up the functions the app was calling when it crashed but I suspect it's happening due to the sampling process elsewhere. I'm not all that great with GDB so I may be missing some vital clue here. FYI, I'm actually using code to start and stop the profiling but this also happens if I bypass that code and just use --prof flag (which turns on profiling and logs to a file for each isolate). Anybody else experience something like this or have a clue? I realize this is super broad but any help would be appreciated as always. Thanks! -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
