750650 - WebGL crash with Shader Toy (Mesa Radeon driver)

Status: RESOLVED WONTFIX

(Core :: Graphics: CanvasWebGL, defect)

Description

[Erno Kuusela]

Attachment: gdb-sessions.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19

Steps to reproduce:

Tried out the Red preset at http://www.iquilezles.org/apps/shadertoy/



Actual results:

Firefox crashed, gdb output is attached for 2 runs, for Mesa 7.11 (which runs WebGL much better on my config) and Mesa 8.0.2 (which is newer) respectively.

Config is self compiled Mesa, Linux 3.1.0, Radeon HD 4250 hardware, Ubuntu 10.10 amd64,
firefox-trunk nightly dated 2012-04-28 from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

Also, my X session just froze for a moment (while typing this up, firefox no longer running) and
dmesg shows

[2544888.272103] radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec
[2544888.272115] GPU lockup (waiting for 0x0579EE21 last fence id 0x0579EE20)
[2544888.273319] radeon 0000:01:05.0: GPU softreset 
[2544888.273326] radeon 0000:01:05.0:   R_008010_GRBM_STATUS=0xE7730030
[2544888.273333] radeon 0000:01:05.0:   R_008014_GRBM_STATUS2=0x00110103
[2544888.273340] radeon 0000:01:05.0:   R_000E50_SRBM_STATUS=0x20000040
[2544888.273351] radeon 0000:01:05.0:   R_008020_GRBM_SOFT_RESET=0x00007FEE
[2544888.288244] radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00000001
[2544888.304126] radeon 0000:01:05.0:   R_008010_GRBM_STATUS=0xA0003030
[2544888.304133] radeon 0000:01:05.0:   R_008014_GRBM_STATUS2=0x00000003
[2544888.304139] radeon 0000:01:05.0:   R_000E50_SRBM_STATUS=0x20008040
[2544888.305138] radeon 0000:01:05.0: GPU reset succeed
[2544888.320492] [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
[2544888.320555] radeon 0000:01:05.0: WB enabled
[2544888.352623] [drm] ring test succeeded in 0 usecs
[2544888.352638] [drm] ib test succeeded in 1 usecs





Expected results:

No crash, and working Shader Toy.

Comment 1

[Al Billings [:abillings - ex-MoCo]]

I'm not seeing this in nightly builds on OS X.

Do you get this crash on a downloaded nightly build from ftp.mozilla.org on your system?

Comment 2

[Kelsey Gilbert [:jgilbert]]

These are crashes in:
Mesa 7.11:
fLinkProgram

Mesa 8.0.2:
raw_fClear:

Comment 3

[Erno Kuusela]

The Red crash reproduces only with Mesa 7.11 with the ftp.mozilla.org nightly,
8.0.2 just shows blank in the render area. But the Disco preset hangs the entire machine with Mesa 8.0.2 (didn't try 7.11).

Comment 4

[Joe Drew (not getting mail)]

It looks to me to be a dereference of an arbitrary pointer, which we tend to mark as critical.

Erno, if you could link us to a crash report in about:crashes on an ftp.mozilla.org nightly, that'd help!

Comment 5

[Erno Kuusela]

Here you go:
https://crash-stats.mozilla.com/report/index/bp-1cca4ab4-6f72-45f1-a49e-f34402120502

That's with Mesa 7.11.

Comment 6

[Joe Drew (not getting mail)]

Oh! It's actually a null dereference. Good.

Comment 7

[Erno Kuusela]

Both 7.11 and 8.0.2 still crash with 2012-05-02 nightly from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa.

To summarise the crashes so far, the 7.11 crash looks like this on
all(?) occasions
=> 0x00007fffd4e762ed <_mesa_remove_dead_code_global+269>:	movb   $0x1,-0x4000(%rdx,%rdi,1)


(gdb) p $rdi
$1 = 140754668180448

and the 8.0.2 crash with the 2012-04-28 nightly from ppa i reported had
=> 0x00007f2fdf5c7a02 <st_translate_program[...])+4594>:    mov    (%rax,%r14,4),%eax

rax            0x7fff99f47fb0   140735776325552

r14            0xffffffff       4294967295


the 2012-05-02 nightly from ppa + 8.0.2 crashed like this

Dump of assembler code from 0x7f7f725c78b7 to 0x7f7f725c78c1:
=> 0x00007f7f725c78b7 <st_translate_program([...])+4263>:	movzwl 0x4(%rax),%r9d

(gdb) p $rax
$1 = 140236856071732
(gdb) p *$rax
Cannot access memory at address 0x7f8b6ffd9634

Comment 8

[Erno Kuusela]

Aha, now I got the 8.0.2 mesa to build with the ftp.mozilla.org nightly too.

(gdb) disas $pc,+10
Dump of assembler code from 0x7fffd09c7a02 to 0x7fffd09c7a0c:
=> 0x00007fffd09c7a02 <st_translate_program([...])+4594>:	mov    (%rax,%r14,4),%eax


(gdb) print $rax
$1 = 140737488332592
(gdb) print $r14
$2 = 4294967295

I was running under gdb and hit "continue" after the SIGSEGV so also had
a crash report, but it didn't make it intact:
https://crash-stats.mozilla.com/report/index/bp-7851117f-b50b-47c0-beab-be8102120503

Comment 9

[Erno Kuusela]

s/build/crash/ :)

Comment 10

[Erno Kuusela]

I noticed in some other webgl bugs people have been using the apitrace
tool. I gave it a shot with the ftp.mozilla.org nightly and mesa 8.0.2.
The following happens when replaying a (non-crashing)
trace recorded with Shader Toy's Red preset.

Program received signal SIGSEGV, Segmentation fault.
type_size (type=0x60) at state_tracker/st_glsl_to_tgsi.cpp:938
938	   switch (type->base_type) {

This seems repeatable (capture trace, replay trace, crash every time and
in same place). So it's crashing in the vicinity of the one I saw in comment #8.

Comment 11

[Erno Kuusela]

Scatch that, it's not repeatable re the trace recording, I was mistakenly running glretrace on the same file after making each new recording.. but the
crash repeats on replay of the file in question every time.

I other news I managed to get a 8.0.2 crash with the ftp.mozilla.org nightly
outside a debugger, so got you a crash dump for that.
It's https://crash-stats.mozilla.com/report/index/bp-68d6c0e6-7c69-4da1-871d-c8fa12120503 and also shows "crash address" as 0. I'm getting a little
skeptical about those (assuming that's what made you think it's a null deref)
now that I look at the "Raw dump" tab on the crash reporter page. The last
column on those is always 0 (for every stack frame) even though
in https://bugzilla.mozilla.org/show_bug.cgi?id=466026 it says it's supposed
to be the instruction pointer/offset or thereabouts.

Comment 12

[Erno Kuusela]

I got a friend to test with the radeon driver on his setup and
there it also flipped with shader toy,
this crashdump has a non-0 crash address: https://crash-stats.mozilla.com/report/index/ace08c67-86cc-408f-af5e-2991f2120504

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

Can this crash still be reproduced in today's Nightly build? Some important bug work-arounds for this driver have landed since this was reported.

Comment 14

[Erno Kuusela]

I don't have the machine setup anymore. With current latest Ubuntu and nightly
it doesn't happen.

Comment 15

[Erno Kuusela]

I spoke too soon, crashed on another attempt.
https://crash-stats.mozilla.com/report/index/bp-a3fa1c66-b956-48e6-bd8c-9cca52120914

Comment 16

[Benoit Jacob [:bjacob] (mostly away)]

Since this is a null-pointer dereference (hence not sec-sensitive) in Mesa and we're apparently not getting too many of these crash reports, it's unlikely that we'll prioritize it at this point.

The more useful thing to do would be to file a Mesa drivers/DRI/radeon bug at bugs.freedesktop.org.