search

ValhallaTeam / angleproject

Automatically exported from code.google.com/p/angleproject
Other
0 stars 0 forks source link

Compiler crash in TOutputESSL::writeVariablePrecision on Android Honeycomb #219

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is forwarded from https://bugzilla.mozilla.org/show_bug.cgi?id=684863
Try asking there directly if you have specific questions.

Crash report with stack and everything:
https://crash-stats.mozilla.com/report/index/2d52bcd0-13cd-4d01-994f-15d32211090
5

Steps to repro on HoneyComb:
1. http://code.google.com/p/webglsamples/
2. open Aquarium link in a new tab

Expected: no content process crash
Actual: content process crash

Content process crash does not occur on Android 2.3

Original issue reported on code.google.com by jacob.be...@gmail.com on 29 Sep 2011 at 1:57

GoogleCodeExporter commented 9 years ago 
Hey, any news on this front? This is ranking 11th top crasher for Firefox 
Mobile 11, which is really concerning especially as it should affect only 
WebGL. This has to mean that WebGL is extremely crashy for many Firefox Mobile 
users.

Original comment by jacob.be...@gmail.com on 5 Dec 2011 at 1:29

GoogleCodeExporter commented 9 years ago 
I don't think there's been any progress on this. From the crash report does the 
symptom appear to be heap corruption? We haven't seen this on desktop platforms.

Original comment by kbr@chromium.org on 5 Dec 2011 at 8:03

GoogleCodeExporter commented 9 years ago 
We're seeing this only on Android, not on any desktop platform (not even on 
Windows where we are using the ESSL backend too, to feed to ANGLE's libGLESv2).

My understanding is that we're dying during some memory 
allocation/deallocation, whence the "_new.h" in the stack. I don't know the 
meaning of 0xdeadbaad in Bionic but it seems likely that we're crashing due to 
a double free() here, which is the primary way to die while doing memory 
allocation/deallocation.

Original comment by jacob.be...@gmail.com on 5 Dec 2011 at 9:33

GoogleCodeExporter commented 9 years ago 
I'm starting to wonder if this is related to the fact that Firefox uses a 
custom memory allocator (jemalloc).

This different but related crash shows us crashing inside of jemalloc:
https://crash-stats.mozilla.com/report/index/ec2a93d9-6307-4a8b-bc85-9aff4211112
9

Original comment by jacob.be...@gmail.com on 5 Dec 2011 at 9:35

GoogleCodeExporter commented 9 years ago 
This issue, and all other allocator-mismatch issues we reported, were all our 
fault (not properly wrapping malloc when we try to use jemalloc). Sorry for the 
noise.

Original comment by jacob.be...@gmail.com on 26 Oct 2012 at 7:56