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

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Hausmann 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 Simon Hausmann 2009-11-17 08:19:37 PST
This bug is also tracked by the internal Qt bug QT-2515
Comment 2 Simon Hausmann 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 Janne Koskinen 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 Simon Hausmann 2009-12-12 16:27:55 PST
Tracked in QtWebKit JIRA requirements at http://bugreports.qt.nokia.com/browse/QTWEBKIT-50
Comment 5 Yael 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 Laszlo Gombos 2010-02-20 09:30:26 PST
Created attachment 49127 [details]
Compile DumpRenderTree for Symbian
Comment 7 WebKit Commit Bot 2010-02-22 07:12:40 PST
Comment on attachment 49127 [details]
Compile DumpRenderTree for Symbian

Clearing flags on attachment: 49127

Committed r55082: <http://trac.webkit.org/changeset/55082>
Comment 8 WebKit Commit Bot 2010-02-22 07:12:45 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Simon Hausmann 2010-02-22 10:04:49 PST
Comment on attachment 49127 [details]
Compile DumpRenderTree for Symbian


> -#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 Laszlo Gombos 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.