Bug 31589 – [Qt] Add support for layout tests on Symbian

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Simon Hausmann]

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.

[Simon Hausmann]

This bug is also tracked by the internal Qt bug QT-2515

[Simon Hausmann]

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.

[Janne Koskinen]

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?

[Simon Hausmann]

Tracked in QtWebKit JIRA requirements at http://bugreports.qt.nokia.com/browse/QTWEBKIT-50

[Yael]

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 .

[Laszlo Gombos]

Created attachment 49127 [details]
Compile DumpRenderTree for Symbian

[WebKit Commit Bot]

Comment on attachment 49127 [details]
Compile DumpRenderTree for Symbian

Clearing flags on attachment: 49127

Committed r55082: <http://trac.webkit.org/changeset/55082>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Simon Hausmann]

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.

[Laszlo Gombos]

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