Closed GoogleCodeExporter closed 9 years ago
More information? What's the symbolized stack trace when SetUp was called? Can
you
reduce the problem to a minimal repro that can be built outside of Chromium?
Original comment by zhanyong...@gmail.com
on 25 Sep 2009 at 7:46
#0 0x008f287f in WebCore::ChromiumBridge::suddenTerminationChanged at
ChromiumBridge.cpp:369
#1 0x01651162 in WebCore::enableSuddenTermination at
SuddenTerminationChromium.cpp:45
#2 0x015f0e60 in WebCore::removeAllUnloadEventListeners at
DOMWindow.cpp:149
#3 0x015f0ed1 in WebCore::DOMWindow::~DOMWindow at DOMWindow.cpp:367
#4 0x013f909b in WTF::RefCounted<WebCore::DOMWindow>::deref at
RefCounted.h:109
#5 0x01281ece in WebCore::DOMData::derefObject at DOMData.cpp:91
#6 0x0128297c in WebCore::DOMData::ensureDeref at DOMData.cpp:66
#7 0x01287319 in WebCore::DOMData::handleWeakObject<void> at
DOMData.h:111
#8 0x012840d6 in WebCore::DOMDataStore::weakDOMObjectCallback at
DOMDataStore.cpp:149
#9 0x00ecc4c4 in
v8::internal::GlobalHandles::Node::PostGarbageCollectionProcessing at global-
handles.cc:166
#10 0x00ecb82f in v8::internal::GlobalHandles::PostGarbageCollectionProcessing
at
global-handles.cc:290
#11 0x00edc914 in v8::internal::Heap::PostGarbageCollectionProcessing at
heap.cc:498
#12 0x00edcab1 in v8::internal::Heap::PerformGarbageCollection at heap.cc:478
#13 0x00edcf05 in v8::internal::Heap::CollectGarbage at heap.cc:378
#14 0x00edd10e in v8::internal::Heap::CollectAllGarbage at heap.cc:328
#15 0x00edd2bb in v8::internal::Heap::CollectAllGarbageIfContextDisposed at
heap.cc:340
#16 0x00e76809 in v8::Context::New at api.cc:2630
#17 0x00346c58 in V8UnitTest::SetUp at v8_unit_test.cc:14
#18 0x00337a5c in JsonSchemaTest::SetUp at json_schema_unittest.cc:23
#19 0x009b2d7d in testing::Test::Run at gtest.cc:2051
#20 0x009b6f69 in testing::internal::TestInfoImpl::Run at gtest.cc:2287
#21 0x009bc2ef in testing::internal::TestInfoImpl::RunTest at gtest-internal-
inl.h:655
#22 0x009b79a5 in testing::internal::List<testing::TestInfo*>::ForEach<void
(*)(testing::TestInfo*)> at gtest-internal-inl.h:397
#23 0x009b6e4e in testing::TestCase::Run at gtest.cc:2383
#24 0x009bc2d3 in testing::TestCase::RunTestCase at gtest-internal-inl.h:776
#25 0x009b77db in testing::internal::List<testing::TestCase*>::ForEach<void
(*)(testing::TestCase*)> at gtest-internal-inl.h:397
#26 0x009b6cad in testing::internal::UnitTestImpl::RunAllTests at gtest.cc:3670
#27 0x009b6da6 in testing::UnitTest::Run at gtest.cc:3404
#28 0x008daf33 in TestSuite::Run at test_suite.h:93
#29 0x008d96dc in main at run_all_unittests.cc:8
I don't have a reduction at the moment.
Original comment by jor...@chromium.org
on 25 Sep 2009 at 7:53
Jeremy -
Is there any chance that this test runs with --gtest_also_run_disabled_tests
flag
specified or with the GTEST_ALSO_RUN_DISABLED_TESTS env variable set?
Thanks,
Vlad
Original comment by vladlosev
on 20 Oct 2009 at 11:13
I was seeing it while running without these flags.
Are you not able to trivially reproduce it? If not, I can try reproducing it
the same way I
did before and then reducing it.
Original comment by jor...@chromium.org
on 21 Oct 2009 at 12:13
No, I am not able to reproduce it. Can you please tell if your test binary
prints 'YOU
HAVE nn DISABLED TESTS' at the end of its output and what is the output of your
test
binary run with the flag --gtest_list_tests? Thanks.
Original comment by vladlosev
on 21 Oct 2009 at 12:49
Original comment by vladlosev
on 21 Oct 2009 at 12:49
Closed as the reporter hasn't got back to us in 1.5 months. I suspect it's a
user
mistake. Please re-open it if you still have reason to think it's a bug in
gtest.
Thanks.
Original comment by w...@google.com
on 10 Dec 2009 at 6:21
Original issue reported on code.google.com by
jor...@chromium.org
on 25 Sep 2009 at 1:30