Crash occurs in kitkat (under opengl 2.0)

[tyomaa88]

Seems like updating from 3.5.0 to 3.5.5 solved an issue! But we were able to test it only on Samsung Galaxy Note 3

[Russel]

No, Version 3.5.5 solved not the issue. We have tested it with Samsung Galaxy S4. The Galaxy S4 crashed after a longer time.

[tyomaa88]

We've experienced this crash almost immediately when displaying our most complex gui screen on Note 3 and it's gone in 3.5.5 ngui. Maybe you've got another type of crash on S4, does it have absolutely the same trace? I'll try to play our game for a little bit more time then and see if it crashes on 3.5.5

[tyomaa88]

Yeah, we've crashed too on other screen, but it took a little bit more time than on 3.5.0

[Russel]

no solution?

[ArenMook]

Try this... UIDrawCall, line 406 is currently:

1. // If the number of vertices in the buffer is less than half of the full buffer, trim it
2. if (!trim && (verts.size << 1) < verts.buffer.Length) trim = true;

...change it to be simply:

1. trim = true;

I'm flying in the blind with this issue as it's a problem in Unity itself, and only Unity can fix it properly.

[tyomaa88]

Also didn't help. We are out of ideas =(

[ChrisPruett]

We have a bunch of users who are experiencing this as well, but haven't been able to reproduce it locally yet.

What we do know is that dynamic batching isn't related to this crash.  Same failure occurs on or off.  This is also not the same as the 32-bit depth buffer workaround.  Symptoms are that users are able to play for a while before the process suddenly dies without warning.

I'm agreed that the bug here is in the Adreno 320 driver, but if there's a way to workaround it I'd like to find it.

Aren, other than the UIDrawCall trimming, is there anything that changed between 3.0.8f4 and latest that might have something to do with VBO caching that I could poke at?  It's likely that nothing NGUI is doing is explicitly wrong, but if some subtle change in the way that vertex arrays are handled has caused this bug to surface, I might be able to work around it by changing that area of behavior.

Thanks.

[ChrisPruett]

I think I've found a workaround.

This is clearly not an NGUI bug.  It's not even a Unity bug.  The Adreno 320 / 330 GLES2 driver is at fault here.  Here's some folks who are not using Unity at all that have hit this crash:

https://github.com/opensciencemap/vtm/issues/52

Anyway, the crash callstack is proceeded by some spew from the driver like this:

04-11 13:41:21.927: W/Adreno-GSL(12206): <ioctl_kgsl_sharedmem_write:1668>: kgsl_sharedmem_write:invalid arg offset 49152 size 1536 memdesc size 4096

and the crash itself is in memcpy, so it looks like this has something to do with moving verts to a buffer that isn't sized correctly.  Or something.

On one of my test devices I was able to get the crash to occur at a particular point, and then by manipulating unrelated things, I actually moved the point of the crash about 2 seconds into the future (i.e. it took 2 seconds longer to occur than the normal trigger point).  This suggests to me that this might be some sort of cache buffer overflow in the driver; perhaps error accumulates until finally the crash occurs.

On the theory that reducing the number of vbo size changes might placate the driver, I commented out the line that Aren indicated above (setting trim if the number of verts is < 50% of the buffer in UIDrawCall).  This probably wastes some memory, as we have some VBOs that are allocated for many more verts than they need, but on the other hand if we have a case where the contents of the VBOs change rapidly, and if the driver dies because of an accumulated overflow, this might be sufficient to avoid the crash.

So far it appears to work.  I've run for about an hour on the Galaxy S4 with zero crashes (before this change I could repro in < 1 minute).  I need to do some more testing on other devices, but for now it seems like a pretty benign way to work around the crappy driver.

[ChrisPruett]

Update: commenting out the space-saving trim has indeed resolved 100% of our crashes on Adreno 320/330 devices.  It also significantly improved performance on one particular device (the Moto X, I think).

I suppose our use case, or possibly NGUI, causes VBO reallocations at high frequency.  At any rate, this is probably something to consider for anybody shipping an NGUI game on Android.

[ArenMook]

Thanks, Chris. So to confirm, you basically did this?

1. #if !UNITY_4_3 || !UNITY_ANDROID
2.                                 // If the number of vertices in the buffer is less than half of the full buffer, trim it
3.                                 if (!trim && (verts.size << 1) < verts.buffer.Length) trim = true;
4. #endif

[ChrisPruett]

I actually just commented out the entire line because I wanted to see if there would be side-effects in the editor.  I don't think the Unity version has much to do with the actual problem, although perhaps something under the hood masks the issue.  But yes, that change would have effectively solved it for me, as I wouldn't be trimming in this case on Android.

[SirCoolbeans]

I've also started to get this problem.

I'm on Unity 4.3.4 and NGUI 3.5.3. The device is a Galaxy S4.

Using a 32 bit buffer and/or the trim changes in UIDrawCall made no difference to me.

The issue appears to be related to OpenGL 2.0. Running my game using OpenGL 3.0 on Android clears things up.

Obviously that's not an ideal solution, it works for me right now as I can continue development.

If I find a proper solution I'll let you guys know. If anyone gets there first it would be awesome to share the knowledge. :-)

[JSorrentino]

1. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
2. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
3. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
4. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
5. W/qdhwcomposer(  281): Excessive delay reading vsync: took 382 ms
6. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
7. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
8. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
9. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
10. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
11. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
12. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
13. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
14. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
15. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
16. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
17. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192
18. W/Adreno-GSL(28962): <ioctl_kgsl_sharedmem_write:1605>: kgsl_sharedmem_write:invalid arg offset 98304 size 1152 memdesc size 8192

Same issue as ChrisPruett - exactly.

I've been trying to find this error for a while now and have been alleviating anything I can to narrow it down.  Disableing animations, textures, coroutines, removing switch statements - anything I could think of.

Commenting the line out resolved my issues.  Samsung Galaxy S4, also the new S5 had the same crash/anr pointing to a memcpy issue.

Chris, thanks for posting the details, it really helped.

[RogueRocket]

Just started noticing reports of this in our console.  Unfortunately, we're on NGUI 3.4.8 and that line that is being commented/#if'd out doesn't even exist yet in 3.4.8
I'm hesitant to update to a newer NGUI right now as I'm meant to be launching an app update this week.

Did this change need to be combined w/ setting to 32-bit buffer?