Bug 70524 – Possible REGRESSION(97879): NRWT fails when DumpRenderTree crashes

• Component: New Bugs
• Status: RESOLVED FIXED

[Raphael Kubo da Costa (:rakuco)]

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

[Eric Seidel (no email)]

Very easy to fix.  I should probably just remove that assert.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

Created attachment 111867 [details]
Patch

[Eric Seidel (no email)]

Committed r98040: <http://trac.webkit.org/changeset/98040>

[Raphael Kubo da Costa (:rakuco)]

(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).