Trying the demo with

    $ midori --version
    Midori 0.4.6-585-gecfa79f

and Debian Sid/unstable with the following packages

    libgl1-mesa-dri:i386          8.0.4-2
    linux-image-3.2.0-3-686-pae   3.2.23-1

with

    01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200]

I can reproduce this crash.

#0  0x9cd2e6c7 in dst_register (index=35, file=PROGRAM_OUTPUT, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:3989
3989	state_tracker/st_glsl_to_tgsi.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x9cd2e6c7 in dst_register (index=35, file=PROGRAM_OUTPUT, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:3989
#1  translate_dst (saturate=false, dst_reg=0xba0cb12c, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:4066
#2  compile_tgsi_instruction (inst=0xba0cb120, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:4158
#3  st_translate_program (ctx=0xb9c62178, procType=procType@entry=1, ureg=ureg@entry=0xb96b00e0, program=0xa5dabd80, 
    proginfo=proginfo@entry=0xba0e6860, numInputs=3, inputMapping=inputMapping@entry=0xba0f6af8, 
    inputSemanticName=inputSemanticName@entry=0x0, inputSemanticIndex=inputSemanticIndex@entry=0x0, interpMode=interpMode@entry=0x0, 
    numOutputs=17, outputMapping=outputMapping@entry=0xba0f6c00, outputSemanticName=outputSemanticName@entry=0xba0f6c8c "", 
    outputSemanticIndex=outputSemanticIndex@entry=0xba0f6caf "", passthrough_edgeflags=0 '\000') at state_tracker/st_glsl_to_tgsi.cpp:4704
#4  0x9ccf8964 in st_translate_vertex_program (key=0xbf90d218, stvp=0xba0e6860, st=<optimized out>) at state_tracker/st_program.c:338
#5  st_get_vp_variant (st=st@entry=0xb9cb4d78, stvp=stvp@entry=0xba0e6860, key=key@entry=0xbf90d218) at state_tracker/st_program.c:426
#6  0x9cdc1a37 in update_vp (st=0xb9cb4d78) at state_tracker/st_atom_shader.c:144
#7  0x9cdbf116 in st_validate_state (st=st@entry=0xb9cb4d78) at state_tracker/st_atom.c:197
#8  0x9cdc5a58 in st_Clear (ctx=0xb9c62178, mask=272) at state_tracker/st_cb_clear.c:508
#9  0x9cd86c20 in _mesa_Clear (mask=16640) at main/clear.c:242
#10 0xb617ffa7 in WebCore::GraphicsContext3D::clear(unsigned int) () from /usr/lib/libwebkitgtk-1.0.so.0
#11 0xb615e1c7 in WebCore::WebGLRenderingContext::clearIfComposited(unsigned int) () from /usr/lib/libwebkitgtk-1.0.so.0
#12 0xb616a3e8 in WebCore::WebGLRenderingContext::clear(unsigned int) () from /usr/lib/libwebkitgtk-1.0.so.0
#13 0xb64aab2b in WebCore::jsWebGLRenderingContextPrototypeFunctionClear(JSC::ExecState*) () from /usr/lib/libwebkitgtk-1.0.so.0
#14 0xa868ef69 in ?? ()
#15 0xb52ac74a in JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /usr/lib/libjavascriptcoregtk-1.0.so.0
#16 0xb537b692 in JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) ()
   from /usr/lib/libjavascriptcoregtk-1.0.so.0
#17 0xb6b8a744 in WebCore::JSInspectorFrontendHost::port(JSC::ExecState*)::port () from /usr/lib/libwebkitgtk-1.0.so.0
---Type <return> to continue, or q <return> to quit---
#18 0xb580f097 in WebCore::ScheduledAction::executeFunctionInContext(JSC::JSGlobalObject*, JSC::JSValue, WebCore::ScriptExecutionContext*)
    () from /usr/lib/libwebkitgtk-1.0.so.0
#19 0xa9331090 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Please tell me if you need more information and if that is the same problem or if I should submit a separate report.

This is fixed for r600g by commit b3921e1f53833420e0a0fd581f741744e7957a05.

r300g cannot be fixed, because the demo uses more vertex shader outputs than the hardware supports.

(In reply to comment #2)
> This is fixed for r600g by commit b3921e1f53833420e0a0fd581f741744e7957a05.

Here is the URL.

http://cgit.freedesktop.org/mesa/mesa/commit/?id=b3921e1f53833420e0a0fd581f741744e7957a05

> r300g cannot be fixed, because the demo uses more vertex shader outputs than
> the hardware supports.

Is there a way, that the application can fail without a crash?

It shouldn't crash anymore. Does it crash?

The assertion is ignored with a non-debug build.

(In reply to comment #4)
> It shouldn't crash anymore. Does it crash?

Sorry, then I misunderstood your comment. I did not have time yet to test the patch on my system. Also I do not have a r300 based card lying around.

> The assertion is ignored with a non-debug build.

Ah. Thanks for the clarification.

I will comment, if something comes up. But I do not think it will, after reading your replies. Thanks!

r300g shouldn't crash, but it will print a lot of error messages to stderr.

Just for the record, r300g fails to assert this now:
firefox: r300_vs.c:73: r300_shader_read_vs_outputs: asserzione "index < 32" non riuscita.