Bug 6450 - (int-148884) libglslcompiler crashes when fragment shader contains a for-loop
(int-148884)
: libglslcompiler crashes when fragment shader contains a for-loop
Status: RESOLVED FIXED
Product: Core
general
: 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:


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


Note

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
SOFTWARE VERSION:
(Settings > General > About product)

EXACT STEPS LEADING TO PROBLEM: 
(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

EXPECTED OUTCOME:
Shader code compiles or gives a proper error message.

ACTUAL OUTCOME:
Crash.

REPRODUCIBILITY:
Always.
(always, less than 1/10, 5/10, 9/10)

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:
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:1.9.1.5)
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
Confirmed.
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
application.
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
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
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).