WebPositive crashes on overuse of Date.getMilliseconds()

[thebuck]

To reproduce: Call the getMilliseconds method of Date regularly (JavaScript).

This will crash WebPositive reliably after a number of calls with the number heavily depending on the call frequency employed.

[thebuck]

For me, on hrev56334 x86_64, this crashes it after about 60 calls. Feel free to adjust the for-loop iterations (10 by now).

[thebuck]

Besides, the maximum reachable frequency when using setInterval() callbacks was at roughly 30 per second for me, even for pure calculation tasks without drawing. Pretty slow.

[thebuck]

Oops, just tried on Linux in a WebKit-based browser: same result, exactly 60! Generic WebKit bug!

[pulkomandy]

The low precision is intentional on webkit side, to prevent javascript gode to perform spectre/meltdown type of attacks that rely on precise timing measurements.

If the crash is generic webkit, maybe report it in the webkit bugtracker instead?

[thebuck]

If the crash is generic webkit, maybe report it in the webkit bugtracker instead?

Rather not. I now suspect it to be machine/CPU-dependant:

• could not reproduce on any other machine
• GLTeapot demo fires crash reporter up instantly, but continues to rotate... That app repeatedly measures time, right?

I will try to find out which time measurement function it calls and write a little while(1) get_the_time(); test.

[waddlesplash]

GLTeapot is known to be unstable, that is almost certainly totally unrelated to timekeeping. Plenty of other applications fetch the time rapidly.

[thebuck]

Got nothing unusual when testing on hrev56334 and hrev56475.

[thebuck]

GLTeapot is known to be unstable

GLTeapot is already stable in hrev56334, my comment:4 were older memories, sorry. Maybe the crashes occurred with an older radeon_hd or GLTeapot version...