Updates:
Owner: joc...@chromium.org
Comment #2 on issue 3421 by mvstan...@chromium.org: Profiler issues on mac
http://code.google.com/p/v8/issues/detail?id=3421
Indeed. I managed to get an instructive call stack on the bot. It shows
that we are releasing the process-wide isolate mutex, and then get a signal
from the profiler, who then desires to take the mutex with
Mutex::TryLock(). This hangs because of the re-entrancy.
(gdb) bt
#0 0x00007fffffe00295 in __spin_lock ()
#1 0x00007fff86e20b41 in pthread_mutex_trylock ()
#2 0x0000000100a54dd8 in TryLockNativeHandle (mutex=0x1026ddb70) at
mutex.cc:71
#3 0x0000000100a54f02 in v8::base::Mutex::TryLock (this=0x1026ddb70) at
mutex.cc:140
#4 0x00000001008ddd32 in v8::internal::Isolate::UncheckedReentrantCurrent
() at isolate.h:474
#5 0x00000001008dbf16 in v8::internal::SignalHandler::HandleProfilerSignal
(signal=27, info=0x7fff5fbfdbb0, context=0x7fff5fbfdc18) at sampler.cc:334
#6 <signal handler called>
#7 0x00007fff86dec63d in pthread_mutex_unlock ()
#8 0x0000000100a54f70 in UnlockNativeHandle (mutex=0x1026ddb70) at
mutex.cc:64
#9 0x0000000100a55058 in v8::base::Mutex::Unlock (this=0x1026ddb70) at
mutex.cc:135
#10 0x00000001004009f3 in v8::base::LockGuard<v8::base::Mutex>::~LockGuard
(this=0x7fff5fbfdd60) at mutex.h:205
#11 0x00000001006720f4 in v8::internal::Isolate::EnsureInitialized () at
isolate.cc:159
#12 0x0000000100242b5d in v8::internal::Isolate::Current () at isolate.h:458
#13 0x000000010035c82c in v8::Value::Equals (this=0x104010768, that={val_ =
0x7fff5fbfe270}) at api.cc:2971
#14 0x00000001003cfd3f in CheckEqualsHelper
(file=0x10102b3f8 "/Volumes/data/b/build/slave/v8-mac-debug/build/v8/test/cctest/test-api.cc",
line=11956, expected_source=0x101045fa5 "args.This()->GetPrototype()",
expected={val_ = 0x104010768}, value_source=0x101045fc1 "args.Holder()",
value={val_ = 0x7fff5fbfe270}) at checks.cc:23
#15 0x00000001000e0c8b in FastApiCallback_SimpleSignature
(args=@0x7fff5fbfe110) at test-api.cc:11956
#16 0x00000001003871ad in v8::internal::FunctionCallbackArguments::Call
(this=0x7fff5fbfe258, f=0x1000e0af0 <FastApiCallback_SimpleSignature>) at
arguments.cc:33
#17 0x00000001003c7cc2 in HandleApiCallHelper<false>
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No data
fields>}, length_ = 3, arguments_ = 0x7fff5fbfe4e8}, <No data fields>},
isolate=0x103800000) at builtins.cc:1202
#18 0x00000001003c7e0b in Builtin_Impl_HandleApiCall
(args={<v8::internal::Arguments> = {<v8::internal::Embedded> = {<No data
fields>}, length_ = 3, arguments_ = 0x7fff5fbfe4e8}, <No data fields>},
isolate=0x103800000) at builtins.cc:1219
#19 0x00000001003c5904 in Builtin_HandleApiCall (args_length=3,
args_object=0x7fff5fbfe4e8, isolate=0x103800000) at builtins.cc:1218
#20 0x000007309eb066ee in ?? ()
From the indispensable "PThreads and Unix" book, following a list of safe
calls to make in signal handlers:
"But where are the Pthreads calls? They're not in either of these lists! In
fact, the Pthreads standard specifies that the behavior of all Pthreads
functions is undefined when the function is called from a signal handler.
If your handler needs to manipulate data that is shared with other
threads≈buffers, flags, or state variables≈it's out of luck. The Pthreads
mutex and condition variable synchronization calls are off limits."
Reverting r22167 for now and Jochen will find a better way.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
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.
