Bug 31589 - [Qt] Add support for layout tests on Symbian
: [Qt] Add support for layout tests on Symbian
Status: RESOLVED FIXED
: WebKit
New Bugs
: 528+ (Nightly build)
: Other Mac OS X 10.5
: P3 Enhancement
Assigned To:
:
: Qt
:
: 27065
  Show dependency treegraph
 
Reported: 2009-11-17 08:19 PST by
Modified: 2010-02-22 10:46 PST (History)


Attachments
Compile DumpRenderTree for Symbian (3.28 KB, patch)
2010-02-20 09:30 PST, Laszlo Gombos
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-11-17 08:19:11 PST
In the long run it would be great to be able to run the layout tests on Symbian.

It may be difficult to run them on an actual device due to the memory requirements, but the simulator/emulator might be an option.
------- Comment #1 From 2009-11-17 08:19:37 PST -------
This bug is also tracked by the internal Qt bug QT-2515
------- Comment #2 From 2009-11-17 08:21:13 PST -------
One issue we'd have with running the DRT on Symbian is the maintenance of the test results. Tor Arne is looking into the use of SVG fonts for all text rendering to produce platform independent metrics for test results.
------- Comment #3 From 2009-11-17 14:02:08 PST -------
Problem with the x86 emulator is that it has even less memory than the actual hardware due to how it is ran in single process and emulator addressing space is allocated as a single continous chunk from Windows heap.

Qemu port of Symbian might come to rescue but it is in too early phase to run GUI apps on it. Then there is the upcoming platsim that would be interesting to see, but AFAIK that won't be free. Beagleboard and Zoom II are also alternatives, but they would need toned down version of tests due to memory limitations?
------- Comment #4 From 2009-12-12 16:27:55 PST -------
Tracked in QtWebKit JIRA requirements at http://bugreports.qt.nokia.com/browse/QTWEBKIT-50
------- Comment #5 From 2009-12-14 13:19:09 PST -------
Since Symbian does not have a perl interpreter, we could use a python version of the test driver instead. Chromium team is upstreaming their python script to webkit.org, see https://bugs.webkit.org/show_bug.cgi?id=31498 .
------- Comment #6 From 2010-02-20 09:30:26 PST -------
Created an attachment (id=49127) [details]
Compile DumpRenderTree for Symbian
------- Comment #7 From 2010-02-22 07:12:40 PST -------
(From update of attachment 49127 [details])
Clearing flags on attachment: 49127

Committed r55082: <http://trac.webkit.org/changeset/55082>
------- Comment #8 From 2010-02-22 07:12:45 PST -------
All reviewed patches have been landed.  Closing bug.
------- Comment #9 From 2010-02-22 10:04:49 PST -------
(From update of attachment 49127 [details])

> -#ifndef Q_OS_WIN
> +#if HAVE(SIGNAL_H)
>  static NO_RETURN void crashHandler(int sig)
>  {
>      fprintf(stderr, "%s\n", strsignal(sig));
> @@ -132,7 +132,7 @@ int main(int argc, char* argv[])
>      QX11Info::setAppDpiX(0, 96);
>  #endif
>  
> -#ifndef Q_OS_WIN
> +#if HAVE(SIGNAL_H)
>      signal(SIGILL, crashHandler);    /* 4:   illegal instruction (not reset when caught) */
>      signal(SIGTRAP, crashHandler);   /* 5:   trace trap (not reset when caught) */
>      signal(SIGFPE, crashHandler);    /* 8:   floating point exception */

I'm unsure about these two hunks. HAVE(SIGNAL_H) comes from the WTF includes that we should not use outside of JavaScriptCore/WebCore. Are you sure that the above HAVE macros evaluate to true on Linux, even though main.cpp isn't directly including config.h? I'm worried that they'll now always evaluate to false, which will make the code still compile and run, but we won't get crash detection.
------- Comment #10 From 2010-02-22 10:46:09 PST -------
> I'm unsure about these two hunks. HAVE(SIGNAL_H) comes from the WTF includes
> that we should not use outside of JavaScriptCore/WebCore.

I agree; filed a bug https://bugs.webkit.org/show_bug.cgi?id=35248.

> Are you sure that the
> above HAVE macros evaluate to true on Linux, even though main.cpp isn't
> directly including config.h? 

main.cpp includes wtf/AlwaysInline.h, which includes Platform.h.

> I'm worried that they'll now always evaluate to
> false, which will make the code still compile and run, but we won't get crash
> detection.

I double-checked and crash detection gets compiled on Linux.