When running NRWT with --debug --platform=efl --no-http -p --tolerance=1, it runs until about 50% and fails with the following messages: worker/4 raised AssertionError('Unprocessed error output: ASSERTION FAILED: cairo_image_surface_get_format(surface) == CAIRO_FORMAT_ARGB32 /home/profusion/webkit/Tools/DumpRenderTree/cairo/PixelDumpSupportCairo.cpp(69) : void computeMD5HashStringForBitmapContext(BitmapContext*, char*) 1 0x42cd61 computeMD5HashStringForBitmapContext(BitmapContext*, char*) 2 0x42b9b4 dumpWebViewAsPixelsAndCompareWithExpected(std::string const&) 3 0x430645 dump() 4 0x4326b6 DumpRenderTreeChrome::onLoadFinished(void*, _Evas_Object*, void*) 5 0x7f0cd82905c3 evas_object_smart_callback_call 6 0x7f0cd68b9b24 ewk_view_load_finished 7 0x7f0cd688cb78 ewk_frame_load_finished 8 0x7f0cd68796f8 WebCore::FrameLoaderClientEfl::postProgressFinishedNotification() 9 0x7f0cd2fb7570 WebCore::ProgressTracker::finalProgressComplete() 10 0x7f0cd2fb741e WebCore::ProgressTracker::progressCompleted(WebCore::Frame*) 11 0x7f0cd2f9ecf6 WebCore::FrameLoader::checkLoadCompleteForThisFrame() 12 0x7f0cd2f9f509 WebCore::FrameLoader::checkLoadComplete() 13 0x7f0cd2f9e26a WebCore::FrameLoader::finishedLoading() 14 0x7f0cd2fb225c WebCore::MainResourceLoader::didFinishLoading(double) 15 0x7f0cd2fc4a13 WebCore::ResourceLoader::didFinishLoading(WebCore::ResourceHandle*, double) 16 0x7f0cd393d8aa 17 0x7f0cd76c2e19 18 0x7f0cd76d2cc8 19 0x7f0cd6b5fbcd g_main_context_dispatch 20 0x7f0cd8033600 21 0x7f0cd802d65d 22 0x7f0cd802e005 23 0x7f0cd802e31f ecore_main_loop_begin 24 0x430065 25 0x430199 26 0x4307e9 main 27 0x7f0ccd5abeff __libc_start_main 28 0x41db89 '): layout_tests/controllers/worker.py:91 (in run) self._worker_connection.run_message_loop() layout_tests/controllers/message_broker.py:191 (in run_message_loop) self._broker.run_message_loop(self._run_topic, self._client, delay_secs) layout_tests/controllers/message_broker.py:127 (in run_message_loop) self._run_loop(topic_name, client, block=True, delay_secs=delay_secs) layout_tests/controllers/message_broker.py:141 (in _run_loop) self._dispatch_message(msg, client) layout_tests/controllers/message_broker.py:150 (in _dispatch_message) message_handler(message.src, *optargs) layout_tests/controllers/worker.py:111 (in handle_test_list) self._run_test(test_input) layout_tests/controllers/worker.py:126 (in _run_test) result = self.run_test_with_timeout(test_input, test_timeout_sec) layout_tests/controllers/worker.py:165 (in run_test_with_timeout) return self._run_test_in_this_thread(test_input) layout_tests/controllers/worker.py:250 (in _run_test_in_this_thread) return self.run_single_test(self._driver, test_input) layout_tests/controllers/worker.py:254 (in run_single_test) test_input, driver, self._name) layout_tests/controllers/single_test_runner.py:45 (in run_single_test) return runner.run() layout_tests/controllers/single_test_runner.py:124 (in run) return self._run_compare_test() layout_tests/controllers/single_test_runner.py:127 (in _run_compare_test) driver_output = self._driver.run_test(self._driver_input()) layout_tests/port/webkit.py:532 (in run_test) assert not self._server_process._error, "Unprocessed error output: %s" % self._server_process._error
Very easy to fix. I should probably just remove that assert.
So what's DRT's expected behavior on EFL when it crashes? It crashes and dumps the stack trace to stderr? Is there any sort of indication after the stacktrace that it's done dumping? I worry that I could remove the assert and replace it with just adding any remaining buffered error into the recordded error. But that might end up not reading the entire stack trace.
Created attachment 111867 [details] Patch
Committed r98040: <http://trac.webkit.org/changeset/98040>
(In reply to comment #2) > So what's DRT's expected behavior on EFL when it crashes? It crashes and dumps the stack trace to stderr? Is there any sort of indication after the stacktrace that it's done dumping? > > I worry that I could remove the assert and replace it with just adding any remaining buffered error into the recordded error. But that might end up not reading the entire stack trace. Well, that's just wtf's ASSERT, which calls WTFReportAssertionFailure and WTFReportBacktrace, so it just depends on that (it doesn't look like there's any indication that dumping is finished).