Bug 35578 - When WebGL(HWaccel) is activated, Firefox will Crash...
Summary: When WebGL(HWaccel) is activated, Firefox will Crash...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-22 19:50 UTC by Maximiliano Castañón
Modified: 2011-03-24 00:35 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
firefox dbg backtrace (18.13 KB, text/plain)
2011-03-22 19:50 UTC, Maximiliano Castañón
Details
traceback (33.20 KB, text/plain)
2011-03-23 21:41 UTC, Maximiliano Castañón
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maximiliano Castañón 2011-03-22 19:50:14 UTC
Created attachment 44744 [details]
firefox dbg backtrace

After the start of Firefox with WebGL enabled, it will crash, in my case my firefox have a master password, my FF seems to crash when it show me the master password window, if i cancel or put my password it will crash instantly.

actually i have updated Mesa from git, and i get the Firefox debug symbol,
as Mattwoodrow from #gfx irc.mozilla.org and Biotube from #radeon irc.freenode.net told me.


start Firefox with 
layers.acceleration.force-enabled true
MOZ_GLX_IGNORE_BLACKLIST=1 firefox

(now dbg and backtrace)
ps afx | grep firefox
gdb -p 24318 (this is the firefox PID)
continue
backtrace

I get:

Program received signal SIGSEGV, Segmentation fault.
0x00007f67e863854e in r600_bo (radeon=0x7f67e9c95d60, size=208, 
    alignment=4096, binding=32, usage=0) at r600_bo.c:43
43	r600_bo.c: No existe el fichero o el directorio.
	in r600_bo.c
(gdb) backtrace
#0  0x00007f67e863854e in r600_bo (radeon=0x7f67e9c95d60, size=208, 
    alignment=4096, binding=32, usage=0) at r600_bo.c:43
#1  0x00007f67e862d43a in r600_buffer_create (screen=0x7f67e94b3a20, 
    templ=0x7fffe88fdde0) at r600_buffer.c:62
#2  0x00007f67e87773c8 in pipe_buffer_create (st=0x7f67e68fe000, 
    params=0x7f67e53a14c0, shader_type=<value optimized out>)
    at ../../src/gallium/auxiliary/util/u_inlines.h:183
#3  st_upload_constants (st=0x7f67e68fe000, params=0x7f67e53a14c0, 
    shader_type=<value optimized out>) at state_tracker/st_atom_constbuf.c:80
#4  0x00007f67e8776a66 in st_validate_state (st=0x7f67e68fe000)
    at state_tracker/st_atom.c:172
#5  0x00007f67e877d2e7 in st_Clear (ctx=0x7f67e66cb000, mask=208)
    at state_tracker/st_cb_clear.c:464
#6  0x00007f680f28ddb7 in ?? ()
#7  0x000001ff00000400 in ?? ()
#8  0x00007f67f905d110 in ?? ()
#9  0x000000003f800000 in ?? ()
#10 0x0000053d00000000 in ?? ()
#11 0x3f80000000000000 in ?? ()
#12 0x0000000000000000 in ?? ()
Comment 1 Michel Dänzer 2011-03-23 01:47:44 UTC
(In reply to comment #1)
> actually i have updated Mesa from git, 

Which commit from which branch are you using?

> 0x00007f67e863854e in r600_bo (radeon=0x7f67e9c95d60, size=208, 
>     alignment=4096, binding=32, usage=0) at r600_bo.c:43

Would be interesting if you could provide the output from running

 p *radeon

at the gdb prompt here.
Comment 2 Henri Verbeet 2011-03-23 03:25:37 UTC
I don't think that's from the driver you built yourself, the line numbers don't match current git. By default the drivers will be installed in /usr/local/, so you would have to set LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" and LD_LIBRARY_PATH="/usr/local/lib/".
Comment 3 Nicolas Peninguy 2011-03-23 04:45:43 UTC
Mozilla only provides 32bits builds of Firefox I think, so you might need to build a i386 version of Mesa.
Comment 4 Henri Verbeet 2011-03-23 04:49:05 UTC
(In reply to comment #3)
> Mozilla only provides 32bits builds of Firefox I think,
The backtrace looks very much like a 64-bit build.
Comment 5 Maximiliano Castañón 2011-03-23 08:48:13 UTC
(In reply to comment #2)
> I don't think that's from the driver you built yourself, the line numbers don't
> match current git. By default the drivers will be installed in /usr/local/, so
> you would have to set LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" and
> LD_LIBRARY_PATH="/usr/local/lib/".

i will try it when i go to my house.

What means that of "p *radeon" ? i need to run it in the gdb?


And yes,i´m using the 64 bits version, it´s called x86_64

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/


Thank!
Comment 6 Maximiliano Castañón 2011-03-23 14:39:00 UTC
well, i ran FF with:

LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" LD_LIBRARY_PATH="/usr/local/lib/" MOZ_GLX_IGNORE_BLACKLIST=1 ./firefox

it show various messages of:

Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable


But it seems to work fine... the test of FPS with Mozilla gives me 4 FPS, but seems to work.

I'm running mesa e4b040c2b
Comment 7 Maximiliano Castañón 2011-03-23 21:39:07 UTC
Ok, got another crash:



Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fde18eff700 (LWP 16893)]
0x00007fde2b1ad57c in __libc_send (fd=72, buf=<value optimized out>, 
    n=<value optimized out>, flags=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/x86_64/send.c:32
32	../sysdeps/unix/sysv/linux/x86_64/send.c: No existe el fichero o el directorio.
	in ../sysdeps/unix/sysv/linux/x86_64/send.c
(gdb) traceback
Undefined command: "traceback".  Try "help".
(gdb) backtrace
#0  0x00007fde2b1ad57c in __libc_send (fd=72, buf=<value optimized out>, 
    n=<value optimized out>, flags=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/x86_64/send.c:32
#1  0x00007fde288d199d in ?? ()
#2  0x00007fdd5ed6f005 in ?? ()
#3  0x00007fde0a2ce6ba in ?? ()
#4  0x00007fddd5b01068 in ?? ()
#5  0x00007fddd5baf000 in ?? ()
#6  0x00007fde2b49c040 in ?? ()
#7  0x00007fddc1b3e6a0 in ?? ()
#8  0x0000001200000000 in ?? ()
#9  0x00007fdda54040f0 in ?? ()
#10 0x0000000000000000 in ?? ()
Comment 8 Maximiliano Castañón 2011-03-23 21:41:35 UTC
Created attachment 44773 [details]
traceback

when i try to login it crashed.
Comment 9 Michel Dänzer 2011-03-24 00:35:12 UTC
(In reply to comment #7)
> Program received signal SIGPIPE, Broken pipe.

SIGPIPE is usually handled by the application and thus harmless. You can tell gdb to ignore it with

 handle SIGPIPE nostop noprint

Anyway, the original problem seems fixed, probably by commit 63b9790a55038c262b57c846a5f7067ea33fc60f ('r600g: move user fence into base radeon structure').


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.