Bug 6450 - (int-148884) libglslcompiler crashes when fragment shader contains a for-loop
: libglslcompiler crashes when fragment shader contains a for-loop
Product: Core
: 5.0/(2.2009.51-1)
: All Linux
: Low critical (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: core-general-bugs
: crash
  Show dependency tree
Reported: 2009-11-30 13:05 UTC by Jarkko Sakkinen
Modified: 2010-03-15 20:53 UTC (History)
2 users (show)

See Also:

Produces libglslcompiler crash (1.87 KB, application/zip)
2009-11-30 18:04 UTC, Jarkko Sakkinen


You need to log in before you can comment on or make changes to this bug.

Description Jarkko Sakkinen (reporter) 2009-11-30 13:05:31 UTC
(Settings > General > About product)

(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Create a application that loops through array with integer index in
fragment shader.
2. Run it on maemo device.
3. Application crashes in libglslcompiler.so

Shader code compiles or gives a proper error message.


(always, less than 1/10, 5/10, 9/10)


I don't have any small example and I cannot reveal the source code that I'm
working on. Sorry about not having small test app with this report. I'll attach
one if I have some extra time at some point.

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:
Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Comment 1 Jarkko Sakkinen (reporter) 2009-11-30 16:59:00 UTC
Similar crashing problem applied also for structs but haven't tested this yet
on the latest FW.
Comment 2 Andre Klapper maemo.org 2009-11-30 17:38:42 UTC
Hi Jarkko,
you are really using the latest public version 1.2009.42-11, I assume? Or do
you have access to something internal and newer?

Any option to post something stacktracish, without revealing too much info?
(Note to myself: core:sgx, int-143961)

Yeah, a small testcase would be really cool. I don't know how secret your
product is, but if I could at least share it with Nokians internally feel free
to send me a private email...
Or if you could at least provide some example code for "Create a application
that loops through array with integer index in fragment shader." :-/
Comment 3 Jarkko Sakkinen (reporter) 2009-11-30 17:44:46 UTC
Yes, latest public release. I'll try to find some time to do a simple test
program ASAP.
Comment 4 Jarkko Sakkinen (reporter) 2009-11-30 18:04:25 UTC
Created an attachment (id=1644) [details]
Produces libglslcompiler crash
Comment 5 Jarkko Sakkinen (reporter) 2009-11-30 18:05:11 UTC
Ok, create really quickly a crude test app that reproduces the bug:

Program received signal SIGSEGV, Segmentation fault.
0x43feb3ec in ?? () from /usr/lib/libglslcompiler.so
0x43feb3ec:    ldm    r1, {r2, r3}
(gdb) backtrace
#0  0x43feb3ec in ?? () from /usr/lib/libglslcompiler.so
#1  0x00000000 in ?? ()

See the attachment (fshcrasher).
Comment 6 Jarkko Sakkinen (reporter) 2009-11-30 18:06:10 UTC
NOTE: I used x11-maemo gitorious qt with test application but I don't think
this is a QT issue..
Comment 7 Andre Klapper maemo.org 2009-12-01 00:27:05 UTC
Thanks a lot!
Comment 8 Andre Klapper maemo.org 2009-12-02 14:51:31 UTC
Comment 9 Andre Klapper maemo.org 2009-12-04 18:16:27 UTC
"Can you confirm that the path to the shader files is correct? We see the same
crash regardless of whether or not the shaders are present on the device."
Comment 10 Andre Klapper maemo.org 2009-12-17 13:08:46 UTC
This is being investigated currently.
Comment 11 Andre Klapper maemo.org 2010-02-12 13:33:43 UTC
Forwarding internal comment:

"I am unable to reproduce this crash with the internal version 2010.05-13
either with the supplied Qt-based test application nor an internal GLES
We do not think this problem exists anymore with the latest SW images."

Hence a future public update will include the fix. (This is not always already
the next public update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
Comment 12 Andre Klapper maemo.org 2010-03-15 20:53:50 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).