www.jpct.net

jPCT-AE - a 3d engine for Android => Support => Topic started by: AeroShark333 on July 10, 2017, 07:29:06 pm

Title: Crash (native)
Post by: AeroShark333 on July 10, 2017, 07:29:06 pm

Hello,


There are some issues with my app on some devices and I don't really know what's causing it...

Code: [Select]

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'motorola/surnia_retbr_dstv/surnia_udstv:6.0/MPI24.65-39-4/3:user/release-keys'
Revision: 'p30d'
ABI: 'arm'
pid: 4182, tid: 4448, name: GLThread 17896  >>> com.aeroshark333.artofearthify <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xa336f000
    r0 a336dab0  r1 a336dd10  r2 00000190  r3 a336efec
    r4 00000654  r5 9daa3d00  r6 a336e9b8  r7 a336e364
    r8 00000208  r9 00000000  sl 00000004  fp 00000000
    ip 00000020  sp a1c05528  lr a336edac  pc ac7a5396  cpsr 200f0030

backtrace:
    #00 pc 000bc396  /system/vendor/lib/egl/libRBGLESv2_adreno.so (oxili_tile_texture+637)
    #01 pc 000917a3  /system/vendor/lib/egl/libRBGLESv2_adreno.so
    #02 pc 000935c9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_update_hw_subimage+4204)
    #03 pc 000949d7  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_loadimage+224)
    #04 pc 0006e6b9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (TexImageLoad+216)
    #05 pc 0006e933  /system/vendor/lib/egl/libRBGLESv2_adreno.so (core_glTexImage2D+234)
    #06 pc 0004cd3b  /system/vendor/lib/egl/libRBGLESv2_adreno.so (glTexImage2D+50)
    #07 pc 0006b5cf  /system/lib/libandroid_runtime.so
    #08 pc 02d6f84d  /system/framework/arm/boot.oat (offset 0x1feb000)

Code: [Select]

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'motorola/surnia_retbr_dstv/surnia_udstv:6.0/MPI24.65-39-4/3:user/release-keys'
Revision: 'p30d'
ABI: 'arm'
pid: 3892, tid: 4136, name: GLThread 17925  >>> com.aeroshark333.artofearthify <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x9fa331a8
    r0 9fa32500  r1 9fa32520  r2 00000190  r3 9fa337fc
    r4 00000654  r5 9f386e00  r6 9fa331a8  r7 9fa32b74
    r8 0000014c  r9 00000000  sl 00000004  fp 00000000
    ip 00000032  sp a02ff528  lr 9fa337fc  pc ac7a538e  cpsr 800f0030

backtrace:
    #00 pc 000bc38e  /system/vendor/lib/egl/libRBGLESv2_adreno.so (oxili_tile_texture+629)
    #01 pc 000917a3  /system/vendor/lib/egl/libRBGLESv2_adreno.so
    #02 pc 000935c9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_update_hw_subimage+4204)
    #03 pc 000949d7  /system/vendor/lib/egl/libRBGLESv2_adreno.so (rb_texture_loadimage+224)
    #04 pc 0006e6b9  /system/vendor/lib/egl/libRBGLESv2_adreno.so (TexImageLoad+216)
    #05 pc 0006e933  /system/vendor/lib/egl/libRBGLESv2_adreno.so (core_glTexImage2D+234)
    #06 pc 0004cd3b  /system/vendor/lib/egl/libRBGLESv2_adreno.so (glTexImage2D+50)
    #07 pc 0006b5cf  /system/lib/libandroid_runtime.so
    #08 pc 02d6f84d  /system/framework/arm/boot.oat (offset 0x1feb000)
The device is a Motorola Moto E with 4G (2nd Gen) running Android 6.0.
I can't reproduce this crash myself on any of my devices.

Title: Re: Crash (native)
Post by: AeroShark333 on July 11, 2017, 12:29:50 am

Code: [Select]

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/a5xeltexx/a5xelte:7.0/NRD90M/A510FXXU4CQDJ:user/release-keys'
Revision: '4'
ABI: 'arm'
pid: 32192, tid: 32357, name: GLThread 53616  >>> com.aeroshark333.artofearthify <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xcb181538
    r0 c43f7c00  r1 cb180890  r2 00000ca8  r3 cb181538
    r4 cb180890  r5 f0f2d008  r6 cb1808d0  r7 c43f7c00
    r8 00000400  r9 c43f8000  sl 00000001  fp 0000002d
    ip 0000005a  sp cce7e5cc  lr cfabc58c  pc cfabc5b8  cpsr 800a0010

backtrace:
    #00 pc 003075b8  /system/vendor/lib/egl/libGLES_mali.soOn Samsung Galaxy A5 2016 running Android 7.0

Title: Re: Crash (native)
Post by: EgonOlsen on July 11, 2017, 07:16:00 pm

Maybe a kind of out of memory? The strange thing of, that it happens in Mali and on Adreno, which makes it look like an app related problem rather than an engine related. How often does it happen?

Title: Re: Crash (native)
Post by: AeroShark333 on July 12, 2017, 03:48:59 am

Apparently this happens a lot and I managed to find a device with this issue myself (dad's phone).

Hmmm, I tried to mess around a bit and I'm starting to suspect the render target(s) or the blitting fragment shaders that I'm using.
The blitting shader is used for both rendertargets (in the blitting shader the shader is split for the two rendertargets)
In the heavy shader, render target 1 will do light operations and render target 1 will do heavy operations (probably too heavy for this phone).
In the light shader, render target 1 will do light operations and render target 2 will do even lighter operations.

One render target with a heavy blitting shader:
-> 4bpp enabled on render target (16-bit): Works. Works. Works. Works. Works.
-> 4bpp disabled on render target (32-bit): Works. Works.

Two render targets with a heavy blitting shader:
-> 4bpp enabled on render target (16-bit): Hangs. Hangs.
-> 4bpp disabled on render target (32-bit): Hangs. Hangs.

One render target with a light shader:
-> 4bpp enabled on render target (16-bit): SIGSEGV. SIGSEGV. Works. Works. SIGSEGV. Works.
-> 4bpp disabled on render target (32-bit): Works. Works.

Two render targets with a light shader:
-> 4bpp enabled on render target (16-bit): SIGSEGV. SIGSEGV. Works. SIGSEGV. SIGSEGV. Works.
-> 4bpp disabled on render target (32-bit): Works. Works. Works.

Or maybe it's not related to any of this at all...
I really have no clue...
Changing Config.blittingMode from 8 to 1 doesn't prevent the SIGSEGV from happening either.
This SIGSEGV doesn't happen on my own phone (which is more high-end...)

Title: Re: Crash (native)
Post by: EgonOlsen on July 12, 2017, 06:51:27 pm

How large is the render target?

Title: Re: Crash (native)
Post by: AeroShark333 on July 13, 2017, 01:10:18 am

On the phone I tried this on?
320x420 if I remember correctly (just the resolution of the screen in pixels)
I tried downscaling as well for the render texture (160x210 for example) but that didn't really change anything...

Title: Re: Crash (native)
Post by: EgonOlsen on July 13, 2017, 10:33:03 am

Can't be an OOM of some kind then. How does your pipeline (setting targets, blitting etc.) looks exactly?

Title: Re: Crash (native)
Post by: AeroShark333 on July 13, 2017, 12:42:51 pm

Something like this:

Code: [Select]

if (hasRenderTexture) {
this.frameBuffer.setRenderTarget(this.renderTexture);
if (hasBlitShader) {
this.frameBuffer.setBlittingShader(blitShader);
}
}
frameBuffer.clear();~World render + draw~

Code: [Select]

if (this.hasRenderTexture) {
frameBuffer.display();
this.frameBuffer.removeRenderTarget();
if (settings.renderer_blit_shader_two_pass) {
this.frameBuffer.setRenderTarget(renderTexture2);
}
if (hasBlitShader) {
blitShader.setUniform(
EarthifyShader.SHADER_UNIFORM_TWO_PASS, 0.0f);
}
frameBuffer.blit(renderTexture, 0, renderTexture.getHeight(),
0, 0, renderTexture.getWidth(),
-renderTexture.getHeight(), frameBuffer.getWidth(),
frameBuffer.getHeight(), -1, false);

if (settings.renderer_blit_shader_two_pass) {
frameBuffer.display();
this.frameBuffer.removeRenderTarget();

// seconds pass
if (hasBlitShader) {
blitShader.setUniform(
EarthifyShader.SHADER_UNIFORM_TWO_PASS, 1.0f);
}
frameBuffer.blit(renderTexture2, 0,
renderTexture2.getHeight(), 0, 0,
renderTexture2.getWidth(),
-renderTexture2.getHeight(),
frameBuffer.getWidth(), frameBuffer.getHeight(),
-1, false);
}
if (hasBlitShader) {
this.frameBuffer.setBlittingShader(null);
}
}
~Lens flare blits~

Code: [Select]

frameBuffer.display();

Title: Re: Crash (native)
Post by: EgonOlsen on July 13, 2017, 06:22:26 pm

Hard to track this one down...could be almost everything. Have you tried without VBOs? I doubt that it's related as this is clearly a texture thing, but one never knows...

Title: Re: Crash (native)
Post by: AeroShark333 on July 13, 2017, 09:11:48 pm

I tried that with Config.useVBO = false; but no luck there...

I tried to get some more logs (yeah, the screen resolution is bigger than I thought initially... I still don't think this would cause an OOM issue however):
Not working w/ Render texture @ 4bpp

Code: [Select]

07-13 21:01:47.373: I/jPCT-AE(5038): glClearColor(0.1137255, 0.1137255, 0.1137255, 1.0) took 31000ns
07-13 21:01:47.374: I/jPCT-AE(5038): glClear(16640) took 700385ns
07-13 21:01:47.374: I/jPCT-AE(5038): glDisable(2929) took 21461ns
07-13 21:01:47.375: I/jPCT-AE(5038): glVertexPointer(3, 5132, 12, java.nio.ByteBufferAsIntBuffer[position=0,limit=5400,capacity=5400]) took 49538ns
07-13 21:01:47.375: I/jPCT-AE(5038): glEnableClientState(32884) took 14539ns
07-13 21:01:47.375: I/jPCT-AE(5038): glDisableClientState(32885) took 9077ns
07-13 21:01:47.375: I/jPCT-AE(5038): glClientActiveTexture(33984) took 12308ns
07-13 21:01:47.375: I/jPCT-AE(5038): glEnableClientState(32888) took 11230ns
07-13 21:01:47.376: I/jPCT-AE(5038): glTexCoordPointer(2, 5132, 8, java.nio.ByteBufferAsIntBuffer[position=0,limit=3600,capacity=3600]) took 37308ns
07-13 21:01:47.376: I/jPCT-AE(5038): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 26077ns
07-13 21:01:47.376: I/jPCT-AE(5038): glEnableClientState(32886) took 15462ns
07-13 21:01:47.376: I/jPCT-AE(5038): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 151308ns
07-13 21:01:47.377: I/jPCT-AE(5038): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 47153ns
07-13 21:01:47.378: I/jPCT-AE(5038): glEnableClientState(32886) took 20538ns
07-13 21:01:47.378: I/jPCT-AE(5038): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 148923ns
07-13 21:01:47.379: I/jPCT-AE(5038): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 50846ns
07-13 21:01:47.379: I/jPCT-AE(5038): glEnableClientState(32886) took 20615ns
07-13 21:01:47.379: I/jPCT-AE(5038): glDrawElements(4, 438, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 142769ns
07-13 21:01:47.379: I/jPCT-AE(5038): glEnable(2929) took 13692ns
07-13 21:01:47.385: D/jPCT-AE(5038): FBO id is -1, render buffer is -1, buffersBuffer is false(0/0/)
07-13 21:01:47.387: I/jPCT-AE(5038): glGetString(7939) took 62000ns
07-13 21:01:47.387: I/jPCT-AE(5038): return value: GL_EXT_debug_marker GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_compressed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_vertex_half_float GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_ARM_mali_program_binary GL_EXT_shader_texture_lod GL_EXT_robustness GL_OES_depth_texture_cube_map GL_KHR_debug GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_OES_mapbuffer
07-13 21:01:47.388: W/jPCT-AE(5038): [ 1499972507388 ] - WARNING: Texture's size is 360/600, but textures should be square for OpenGL ES2.0! This may result in a black texture!
07-13 21:01:47.388: D/jPCT-AE(5038): Allocating native memory for 360*600 texture(false/false/false/false/): 432000 bytes!
07-13 21:01:47.389: I/jPCT-AE(5038): glGenTextures(1, java.nio.ByteBufferAsIntBuffer[position=0,limit=1,capacity=1]) took 67846ns
07-13 21:01:47.389: D/jPCT-AE(5038): New texture's id is: 11
07-13 21:01:47.390: I/jPCT-AE(5038): glActiveTexture(33984) took 18308ns
07-13 21:01:47.390: I/jPCT-AE(5038): glBindTexture(3553, 11) took 58307ns
07-13 21:01:47.390: I/jPCT-AE(5038): glTexParameterx(3553, 10241, 9729) took 23693ns
07-13 21:01:47.390: I/jPCT-AE(5038): glTexParameterx(3553, 10240, 9728) took 17615ns
07-13 21:01:47.391: I/jPCT-AE(5038): glTexParameterx(3553, 10242, 33071) took 14615ns
07-13 21:01:47.391: I/jPCT-AE(5038): glTexParameterx(3553, 10243, 33071) took 23923ns
07-13 21:01:47.391: I/jPCT-AE(5038): --------- beginning of crash
07-13 21:01:47.673: W/google-breakpad(5038): ### ### ### ### ### ### ### ### ### ### ### ### ###
07-13 21:01:47.674: W/google-breakpad(5038): Chrome build fingerprint:
07-13 21:01:47.674: W/google-breakpad(5038): 1.1.2
07-13 21:01:47.674: W/google-breakpad(5038): 8
07-13 21:01:47.674: W/google-breakpad(5038): ### ### ### ### ### ### ### ### ### ### ### ### ###
07-13 21:01:47.674: A/libc(5038): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xa4103690 in tid 5312 (GLThread 588)

Working w/ Render texture @ non-4bpp

Code: [Select]

07-13 21:09:05.024: I/jPCT-AE(8876): glClearColor(0.5803922, 0.5803922, 0.5803922, 1.0) took 46615ns
07-13 21:09:05.025: I/jPCT-AE(8876): glClear(16640) took 663231ns
07-13 21:09:05.026: I/jPCT-AE(8876): glDisable(2929) took 28000ns
07-13 21:09:05.027: I/jPCT-AE(8876): glVertexPointer(3, 5132, 12, java.nio.ByteBufferAsIntBuffer[position=0,limit=5400,capacity=5400]) took 135692ns
07-13 21:09:05.027: I/jPCT-AE(8876): glEnableClientState(32884) took 26000ns
07-13 21:09:05.027: I/jPCT-AE(8876): glDisableClientState(32885) took 17385ns
07-13 21:09:05.028: I/jPCT-AE(8876): glClientActiveTexture(33984) took 17692ns
07-13 21:09:05.028: I/jPCT-AE(8876): glEnableClientState(32888) took 20077ns
07-13 21:09:05.028: I/jPCT-AE(8876): glTexCoordPointer(2, 5132, 8, java.nio.ByteBufferAsIntBuffer[position=0,limit=3600,capacity=3600]) took 62846ns
07-13 21:09:05.029: I/jPCT-AE(8876): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 52308ns
07-13 21:09:05.029: I/jPCT-AE(8876): glEnableClientState(32886) took 29461ns
07-13 21:09:05.029: I/jPCT-AE(8876): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 197615ns
07-13 21:09:05.030: I/jPCT-AE(8876): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 77538ns
07-13 21:09:05.031: I/jPCT-AE(8876): glEnableClientState(32886) took 26385ns
07-13 21:09:05.031: I/jPCT-AE(8876): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 180769ns
07-13 21:09:05.040: I/jPCT-AE(8876): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 64077ns
07-13 21:09:05.040: I/jPCT-AE(8876): glEnableClientState(32886) took 28461ns
07-13 21:09:05.041: I/jPCT-AE(8876): glDrawElements(4, 438, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 189770ns
07-13 21:09:05.041: I/jPCT-AE(8876): glEnable(2929) took 26154ns
07-13 21:09:05.045: D/jPCT-AE(8876): FBO id is -1, render buffer is -1, buffersBuffer is false(0/0/)
07-13 21:09:05.048: I/jPCT-AE(8876): glGetString(7939) took 104077ns
07-13 21:09:05.049: I/jPCT-AE(8876): return value: GL_EXT_debug_marker GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_compressed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_vertex_half_float GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_ARM_mali_program_binary GL_EXT_shader_texture_lod GL_EXT_robustness GL_OES_depth_texture_cube_map GL_KHR_debug GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_OES_mapbuffer
07-13 21:09:05.049: W/jPCT-AE(8876): [ 1499972945049 ] - WARNING: Texture's size is 360/600, but textures should be square for OpenGL ES2.0! This may result in a black texture!
07-13 21:09:05.049: D/jPCT-AE(8876): Allocating native memory for 360*600 texture(false/false/false/false/): 864000 bytes!
07-13 21:09:05.052: I/jPCT-AE(8876): glGenTextures(1, java.nio.ByteBufferAsIntBuffer[position=0,limit=1,capacity=1]) took 70847ns
07-13 21:09:05.052: D/jPCT-AE(8876): New texture's id is: 11
07-13 21:09:05.052: I/jPCT-AE(8876): glActiveTexture(33984) took 17615ns
07-13 21:09:05.052: I/jPCT-AE(8876): glBindTexture(3553, 11) took 36154ns
07-13 21:09:05.053: I/jPCT-AE(8876): glTexParameterx(3553, 10241, 9729) took 21538ns
07-13 21:09:05.053: I/jPCT-AE(8876): glTexParameterx(3553, 10240, 9728) took 17154ns
07-13 21:09:05.053: I/jPCT-AE(8876): glTexParameterx(3553, 10242, 33071) took 18000ns
07-13 21:09:05.053: I/jPCT-AE(8876): glTexParameterx(3553, 10243, 33071) took 15000ns
07-13 21:09:05.058: I/jPCT-AE(8876): glTexImage2D(3553, 0, 6408, 360, 600, 0, 6408, 5121, java.nio.DirectByteBuffer[position=0,limit=864000,capacity=864000]) took 4440692ns
07-13 21:09:05.058: I/jPCT-AE(8876): glBindTexture(3553, 1) took 27923ns
07-13 21:09:05.059: D/jPCT-AE(8876): New texture uploaded: com.threed.jpct.NPOTTexture@cd69d1f in thread Thread[GLThread 1121,5,main]
07-13 21:09:05.059: I/jPCT-AE(8876): glBindTexture(3553, 11) took 20231ns
07-13 21:09:05.061: D/jPCT-AE(8876): Creating render buffer in depth mode!
07-13 21:09:05.064: D/jPCT-AE(8876): Render buffer created: 1

I wasn't really able to reproduce this error on a non-4bpp render texture (maybe it never crashed then...) but on a 4bpp render texture it crashes about 90% of the time with this phone. (On my higher-end phone it does not crash with 4bpp enabled for the render texture).
So I initially thought the having 4bpp enabled on the render texture was the problem, though strangely... it does work sometimes (this 10%).
For now, I published the application with 4bpp disabled on the render texture and many users (who first got the crash) reported to me that it's working fine now...  ???

Working w/ Render texture @ 4bpp

Code: [Select]

07-13 21:24:52.367: I/jPCT-AE(14416): glClearColor(0.6313726, 0.6313726, 0.6313726, 1.0) took 37000ns
07-13 21:24:52.367: I/jPCT-AE(14416): glClear(16640) took 173077ns
07-13 21:24:52.368: I/jPCT-AE(14416): glDisable(2929) took 24462ns
07-13 21:24:52.368: I/jPCT-AE(14416): glActiveTexture(33984) took 18615ns
07-13 21:24:52.369: I/jPCT-AE(14416): glBindTexture(3553, 1) took 23385ns
07-13 21:24:52.371: I/jPCT-AE(14416): glVertexPointer(3, 5132, 12, java.nio.ByteBufferAsIntBuffer[position=0,limit=5400,capacity=5400]) took 68000ns
07-13 21:24:52.371: I/jPCT-AE(14416): glEnableClientState(32884) took 19846ns
07-13 21:24:52.372: I/jPCT-AE(14416): glDisableClientState(32885) took 19461ns
07-13 21:24:52.372: I/jPCT-AE(14416): glClientActiveTexture(33984) took 18000ns
07-13 21:24:52.373: I/jPCT-AE(14416): glEnableClientState(32888) took 20462ns
07-13 21:24:52.373: I/jPCT-AE(14416): glTexCoordPointer(2, 5132, 8, java.nio.ByteBufferAsIntBuffer[position=0,limit=3600,capacity=3600]) took 58000ns
07-13 21:24:52.374: I/jPCT-AE(14416): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 45693ns
07-13 21:24:52.374: I/jPCT-AE(14416): glEnableClientState(32886) took 25385ns
07-13 21:24:52.375: I/jPCT-AE(14416): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 498692ns
07-13 21:24:52.377: I/jPCT-AE(14416): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 63077ns
07-13 21:24:52.378: I/jPCT-AE(14416): glEnableClientState(32886) took 48308ns
07-13 21:24:52.379: I/jPCT-AE(14416): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 279308ns
07-13 21:24:52.381: I/jPCT-AE(14416): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 60154ns
07-13 21:24:52.381: I/jPCT-AE(14416): glEnableClientState(32886) took 22077ns
07-13 21:24:52.382: I/jPCT-AE(14416): glDrawElements(4, 438, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 266770ns
07-13 21:24:52.383: I/jPCT-AE(14416): glEnable(2929) took 24230ns
07-13 21:24:52.388: I/jPCT-AE(14416): Normal vectors calculated in 2ms!
07-13 21:24:52.390: I/jPCT-AE(14416): Tangent vectors calculated in 1ms!
07-13 21:24:52.392: I/jPCT-AE(14416): Normal vectors calculated in 2ms!
07-13 21:24:52.393: I/jPCT-AE(14416): Memory usage before compacting: 5303 KB used out of 6982 KB. Max. memory available to the VM is 262144 KB.
07-13 21:24:52.593: I/jPCT-AE(14416): Memory usage after compacting: 5250 KB used out of 6995 KB. Max. memory available to the VM is 262144 KB.
07-13 21:24:52.593: I/jPCT-AE(14416): glClearColor(0.53333336, 0.53333336, 0.53333336, 1.0) took 36153ns
07-13 21:24:52.595: I/jPCT-AE(14416): glClear(16640) took 1345231ns
07-13 21:24:52.596: I/jPCT-AE(14416): glDisable(2929) took 84231ns
07-13 21:24:52.598: I/jPCT-AE(14416): glVertexPointer(3, 5132, 12, java.nio.ByteBufferAsIntBuffer[position=0,limit=5400,capacity=5400]) took 69769ns
07-13 21:24:52.598: I/jPCT-AE(14416): glEnableClientState(32884) took 20692ns
07-13 21:24:52.599: I/jPCT-AE(14416): glDisableClientState(32885) took 398308ns
07-13 21:24:52.600: I/jPCT-AE(14416): glClientActiveTexture(33984) took 18077ns
07-13 21:24:52.600: I/jPCT-AE(14416): glEnableClientState(32888) took 19154ns
07-13 21:24:52.601: I/jPCT-AE(14416): glTexCoordPointer(2, 5132, 8, java.nio.ByteBufferAsIntBuffer[position=0,limit=3600,capacity=3600]) took 63615ns
07-13 21:24:52.601: I/jPCT-AE(14416): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 45923ns
07-13 21:24:52.602: I/jPCT-AE(14416): glEnableClientState(32886) took 70308ns
07-13 21:24:52.603: I/jPCT-AE(14416): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 586846ns
07-13 21:24:52.605: I/jPCT-AE(14416): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 61154ns
07-13 21:24:52.606: I/jPCT-AE(14416): glEnableClientState(32886) took 24077ns
07-13 21:24:52.607: I/jPCT-AE(14416): glDrawElements(4, 594, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 236231ns
07-13 21:24:52.609: I/jPCT-AE(14416): glColorPointer(4, 5132, 16, java.nio.ByteBufferAsIntBuffer[position=0,limit=7200,capacity=7200]) took 60616ns
07-13 21:24:52.609: I/jPCT-AE(14416): glEnableClientState(32886) took 24077ns
07-13 21:24:52.610: I/jPCT-AE(14416): glDrawElements(4, 438, 5123, java.nio.ByteBufferAsShortBuffer[position=0,limit=3600,capacity=3600]) took 267770ns
07-13 21:24:52.611: I/jPCT-AE(14416): glEnable(2929) took 24693ns
07-13 21:24:52.613: D/jPCT-AE(14416): FBO id is -1, render buffer is -1, buffersBuffer is false(0/0/)
07-13 21:24:52.614: I/jPCT-AE(14416): glGetString(7939) took 70769ns
07-13 21:24:52.615: I/jPCT-AE(14416): return value: GL_EXT_debug_marker GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_compressed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_vertex_half_float GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_ARM_mali_program_binary GL_EXT_shader_texture_lod GL_EXT_robustness GL_OES_depth_texture_cube_map GL_KHR_debug GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_OES_mapbuffer
07-13 21:24:52.615: W/jPCT-AE(14416): [ 1499973892615 ] - WARNING: Texture's size is 360/600, but textures should be square for OpenGL ES2.0! This may result in a black texture!
07-13 21:24:52.616: D/jPCT-AE(14416): Allocating native memory for 360*600 texture(false/false/false/false/): 432000 bytes!
07-13 21:24:52.621: I/jPCT-AE(14416): glGenTextures(1, java.nio.ByteBufferAsIntBuffer[position=0,limit=1,capacity=1]) took 90615ns
07-13 21:24:52.622: D/jPCT-AE(14416): New texture's id is: 11
07-13 21:24:52.622: I/jPCT-AE(14416): glActiveTexture(33984) took 22154ns
07-13 21:24:52.623: I/jPCT-AE(14416): glBindTexture(3553, 11) took 115538ns
07-13 21:24:52.624: I/jPCT-AE(14416): glTexParameterx(3553, 10241, 9729) took 24154ns
07-13 21:24:52.624: I/jPCT-AE(14416): glTexParameterx(3553, 10240, 9728) took 18846ns
07-13 21:24:52.625: I/jPCT-AE(14416): glTexParameterx(3553, 10242, 33071) took 19461ns
07-13 21:24:52.625: I/jPCT-AE(14416): glTexParameterx(3553, 10243, 33071) took 18000ns
07-13 21:24:52.636: I/jPCT-AE(14416): glTexImage2D(3553, 0, 6408, 360, 600, 0, 6408, 5121, java.nio.DirectByteBuffer[position=0,limit=432000,capacity=432000]) took 10327692ns
07-13 21:24:52.637: I/jPCT-AE(14416): glBindTexture(3553, 1) took 26769ns
07-13 21:24:52.637: D/jPCT-AE(14416): New texture uploaded: com.threed.jpct.NPOTTexture@27cf779 in thread Thread[GLThread 1559,5,main]
07-13 21:24:52.638: I/jPCT-AE(14416): glBindTexture(3553, 11) took 23693ns
07-13 21:24:52.638: D/jPCT-AE(14416): Creating render buffer in depth mode!
07-13 21:24:52.640: D/jPCT-AE(14416): Render buffer created: 1


Title: Re: Crash (native)
Post by: EgonOlsen on July 14, 2017, 09:51:33 pm

Might be a driver problem of some kind or an oversight on my side, but I've no idea what it's supposed to be...

Title: Re: Crash (native)
Post by: AeroShark333 on July 15, 2017, 09:39:15 am

Well apparently having a 4bpp render texture causes problems for me on older Andreno's and Mali's. A non-4bpp render texture pretty much solved everything instantly...

Title: Re: Crash (native)
Post by: AeroShark333 on January 23, 2018, 11:10:32 am

Still getting these mysterious SIGSEGV errors..

Crash log #1: https://pastebin.com/xtCdy0Yk (line #141)
Working log #2: https://pastebin.com/9Ngvzg2Q (line #337)

So it seems that glDrawElements(...) is causing a crash here, although it is not always happening which I still don't really understand.

I tried to make it use glDrawArrays(...) by invoking build(false) and compile(false,false) but no luck there, same story: random crashes but sometimes works.

All textures do load, but when the first World draw call is made, it might crash.

EDIT:
Another unrelated question I always wondered about:
Why is TextureManager static and why isn't it designed in such way that you can have multiple TextureManagers (for multiple renderers)?

EDIT2:
I seem to be having issues with render target textures. Everytime I change device orientation I create a new render texture so it'd fit the rotated screen dimensions. However, I seem to be getting a memory leak here... How I do this:
-> start
-> on surface changed (): create rendertargettexture and add to texturemanager with a specific name
-> on draw (): use rendertexture
-> change screen orientation
-> on surface changed (): set rendertargettexture reference to null + unload&remove rendertargettexture using specific name + add new rendertargettexture with new dimensions
-> on draw (): use new rendertexture
While this all works fine, it seems to fill my device's memory if I keep changing the screen orientation.
Without using rendertargettexture, RAM usage might also increase a little when changing screen orientation but it'd get GC'ed and RAM usage will drop again.

Title: Re: Crash (native)
Post by: AeroShark333 on February 02, 2018, 11:05:03 am

Hello?

Title: Re: Crash (native)
Post by: EgonOlsen on February 05, 2018, 09:50:32 am

Sorry, I haven't spotted your question ealier. The upload method works only at render time, i.e. if you call unload, it doesn't really unload but waits for the next render call and then does the unloading. That's because it has to happen in the GL thread or otherwise, there's nothing to unload.
If you rotate the device, it might be that the actual context is already lost (or onDrawFrame not called anymore on it) so that the unload never happens but somehow the driver keeps the copy in memory (albeit it shouldn't, because it should be bound to the context and if that changes, it should go away).
If you sure to be in the right thread, you can try to set Config.unloadImmediately to true and see if that helps.

Title: Re: Crash (native)
Post by: AeroShark333 on February 06, 2018, 06:12:48 pm

Uhm, I'm not sure if the context is lost...
I don't re-initialize the Framebuffer ever (I just use #resize() whenever the device is rotated).

I already had Config.unloadImmediately set to true, which did not work... Setting it to false did not work either unfortunately.
Whenever I don't use a rendertexture but just the FrameBuffer, RAM usage does not increase on screen rotations.

Is there perhaps a rotate function/method possible for rendertextures/NPOTTextures since screen rotations usually just swap the width and the height? (But these rendertextures would hold the same amount of data eventually for the different orientations)
Probably my solution for now would be to create these two rendertextures at start (one with default orientation and one with rotated orientation) and just switch between these two rendertextures.

---

Another thing about my application:
I don't keep my texturedata for rendertextures nor any other texture in VM.
TextureManager.getMemoryUsage() would indeed show that just 1024 bytes is stored by the VM. (Basically nothing)
However, when I use "Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()", it would show that there's muuuch RAM usage more by the VM, up to 300 megabytes (by jPCT, I assume). What could be using all the RAM?

Title: Re: Crash (native)
Post by: EgonOlsen on February 07, 2018, 10:44:31 am

To answer your last question: The textures and other native data is using that RAM.

About the render targets: As long as you don't create a new FrameBuffer, nothing happens for the textures if your rotate the device. However, I've no idea how it's supposed to work that way, because rotating the device should destroy the context (simply because width and height are changing) and so you should need a new instance of the buffer. But anyway...as long as the buffer doesn't change, there's actually no need to unload the render target texture at all. Have you tried what happens if you don't do that at all?

Title: Re: Crash (native)
Post by: AeroShark333 on February 08, 2018, 09:26:41 pm

Quote from: EgonOlsen on February 07, 2018, 10:44:31 am

To answer your last question: The textures and other native data is using that RAM.

Ah understood.

Quote from: EgonOlsen on February 07, 2018, 10:44:31 am

About the render targets: As long as you don't create a new FrameBuffer, nothing happens for the textures if your rotate the device.

Yes, they are fine if the device is rotated

Quote from: EgonOlsen on February 07, 2018, 10:44:31 am

However, I've no idea how it's supposed to work that way, because rotating the device should destroy the context (simply because width and height are changing) and so you should need a new instance of the buffer.

Well it is a live wallpaper, and live wallpapers are able to preserve EGL context on pause (or something like that).
https://developer.android.com/reference/android/opengl/GLSurfaceView.html#setPreserveEGLContextOnPause(boolean)
So whenever the device is rotated, onSurfaceChanged(...) is called again, and here I can resize the already existing FrameBuffer to the new width and height.

Quote from: EgonOlsen on February 07, 2018, 10:44:31 am

But anyway...as long as the buffer doesn't change, there's actually no need to unload the render target texture at all. Have you tried what happens if you don't do that at all?

I tried that... but the render target won't have the right dimensions then and it will give weird results on screen.
Let's say I start the wallpaper in portrait mode.
I would create a 1440 x 2560 FrameBuffer (width x height)
And at the same time I'd create a 1440 x 2560 NPOTTexture for the render texture.
All fine here.
Now if I change the orientation to landscape, I'd resize the FrameBuffer to 2560x1440 (width x height). (Notice that the values are now swapped)
But the rendertexture is still 1440 x 2560, so I remove this texture from the texturemanager and add a new 2560 x 1440 NPOTTexture.

Removing without unloading did not change anything, still filling memory...

I actually have the feeling that unloading textures does not completely work...
Whenever I open a second live wallpaper instance (using preview) it seems that the textures of that instance aren't unloaded whenever the preview instance is 'killed'.
It is like the primary live wallpaper instance is preventing the other textures to get unloaded or something
(Unless all instances are killed it will all be gone)

Title: Re: Crash (native)
Post by: EgonOlsen on February 09, 2018, 12:13:06 pm

As mentioned, unloading of texture data from the GPU's memory has to happen in the GL rendering thread with a valid context. Otherwise, there nothing to unload it from. If the OS destroys a GL context, the graphics driver should actually free the associated memory. If that doesn't happen...well, I can't do anything about it then.
Have you tried this on some other device witha different GPU? Does it behave the same?

Title: Re: Crash (native)
Post by: AeroShark333 on February 11, 2018, 05:31:40 pm

I tested rendertarget textures with rotating screen on the following devices

Code: [Select]

My device (ZTE Axon 7 @ Android 7.1.1 Custom ROM):
-> Low VM RAM (discard what I said about 300 MB RAM usage in VM earlier... It's about 30 MB actually (I guess my eyes added a digit... derp))
-> No memoryleak when rotating screen in VM (but there is in native/video memory)
-> However, in developer options -> Active services, the RAM usage keeps rising (300+ MB+ here (could go much higher though (1,8+ GB after many many screen rotations => device will kill other processes and might even reboot here) so I suppose it's not VM but native+video+VM that is being displayed here)

Some old tablet (Difrnce DIT4350 @ Android 4.0.4)
-> Low VM RAM
-> No memory leak with rendertarget textures
-> Crashes after many screen rotations..?

Old tablet 2 (Asus TF101 @ Android 4.0.3)
-> Low VM RAM
-> Crashes after many screen rotations?

Emulator #1 (Android 4.1.1):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM

Emulator #2 (Android 4.2.2):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM

Emulator #3 (Android 7.1.0):
-> Low VM RAM
-> No memory leak with rendertarget textures in VM
-> I don't see the VM+Video+Native memory usage as high as on my own device here in developer options... Unloading seems to work just fine here
-> No memory leak with rendertarget textures in native+video

For the sake of clarity also a test without rendertarget textures on my main device:

Code: [Select]

-> Low VM RAM
-> No memoryleak with rotating screen
-> Memoryleak with renderers when restarted in native+video RAM (renderer restarts when a setting is changed)
How does it restart:
-> Change a setting
-> (I believe it still uses the same GL context as before)
-> Removing and unloading textures from texturemanager (but it won't go through another draw call to actually unload them I suppose...)
-> Framebuffer is disposed
-> Reference to the renderer is gone now
-> A new Framebuffer is created
Now that I think of it... I think I could re-use the framebuffer... :|
10 minutes later... -> Re-using the same FrameBuffer but the memory leak remains..?

In the end, it seems that textures aren't unloaded untill the whole wallpaper engine is killed.
(restarting doesn't kill the wallpaper engine...)

Starting to think it could be a driver issue on my device... Egh

I'll try to test it with other physical devices

Title: Re: Crash (native)
Post by: AeroShark333 on February 27, 2018, 01:59:50 pm

For now I'll just assume my device is the only device with this unloading issue... Oh well, it's a custom ROM...

Anyway, about the SIGSEGV error that keeps happening at the first world draw call, I think it's because of my custom shaders... Which I don't really understand though...
On most high-end devices there are no issues at all with my custom shaders
And I don't really understand why the default shaders would work just fine (always..) while they look more complicated than some of the custom shaders I'm using. Although, on devices where my custom shaders crash, it does NOT always crash, which completely blows my mind... It seems to happen just randomly basically.

Unlike the default shader, my custom shaders use:
-> pre-processor things with #
-> setting uniform variables in onDraw
-> defined functions within the shader
Though, I don't think these are really the issue...

While Googling this issue I did find some weird OpenGLES shader crash reports by other people that could be solved by work-arounds such as changing the order of operands...???
Anyway, what would be do's and don't for writing a GLES shader? Or maybe: how did you manage to create the 'perfect?' default shader which never seems to crash?
Does jPCT-AE perhaps treat custom shaders differently than default shaders?

Another thing that seems to reduce the probability of the random crash at the first draw call was to use lower polygon models...

Also... What could be an explanation of the randomness of the crashes since it does not always happen, well the positions of the Object3D's are always different but would that make a huge difference...? I'd think not but apart from that nothing else is really different and yet it somehow manages to render/crash
And once the first draw call has successfully completed (assuming all Object3D's are visible) then it won't crash in future world draw calls

Another possible solution: increase the buffersize of the framebuffer even more? I thought Config.blittingMode = 8; did impact the probability of crashing in a positive way (I think it had to do with vertex upload buffer maybe, I don't really know...)
Is there any way for me to determine what is actually causing the crash as in which call in the jPCT-AE jar is causing the SIGSEGV error?
Might help for solving the issue...

Title: Re: Crash (native)
Post by: AeroShark333 on March 04, 2018, 04:43:10 pm

Okay nevermind, it crashes with default shaders too :| It just seems more likely with my custom shaders though...
But increasing the buffer size to 1800 did help a little, is it possible to increase it even more?
Why is the default 600 anyway? And what units are these 1800? Bytes I assume?

Another thing that helped a lot is reducing polygon count per mesh but yeah... that'd reduce quality...

LOGS:
Working: https://pastebin.com/n08EE8VR
Not working: https://pastebin.com/AuQF8NTm

Title: Re: Crash (native)
Post by: EgonOlsen on March 05, 2018, 10:01:12 am

Which buffer size do you mean exactly? And which device are you using to test this?

Title: Re: Crash (native)
Post by: AeroShark333 on March 05, 2018, 04:34:03 pm

Quote from: EgonOlsen on March 05, 2018, 10:01:12 am

Which buffer size do you mean exactly?

03-05 10:19:44.749: I/jPCT-AE(2711): Blitting buffer size: 600
^ this one

I tried to test with the default Config.blittingMode and with Config.blittingMode = 8;
I used higher polygon count models for this test.
Compat mode => Config.blittingMode = 8;
No compat mode => Default Config.blittingMode

Code: [Select]

compat mode:
runs: 10
succes: 5
crashes: 5

no compat mode:
runs: 10
succes: 1
crashes: 9

compat mode:
runs: 10
succes: 4
crashes: 6

no compat mode:
runs: 10
succes: 0
crashes: 10

compat mode:
runs: 10
succes: 5
crashes: 5

no compat mode:
runs: 10
succes: 0
crashes: 10As you can see it drops the chance of crashing from ~96% to ~53%.
Whether this is just a coincidence, I can't tell but I tested this multiple times (swapping between the two config values after every 10 runs).

Quote from: EgonOlsen on March 05, 2018, 10:01:12 am

And which device are you using to test this?

I'm currently using a Genymotion emulator (With a Nexus 5, Android 5.0.1 build) to reproduce these crashes. (I can reproduce crash on older physical devices, just to make sure... Plus many people reported this SIGSEGV crash through the Google Play Store and I think I can assume they are not using an emulator...  ??? )

Title: Re: Crash (native)
Post by: EgonOlsen on March 06, 2018, 09:26:01 am

No, they aren't using an emulator for sure, but...from my own experience, crashes happen mostly on MALI-based GPUs. Can you confirm this based on the Google Play stats?

Title: Re: Crash (native)
Post by: AeroShark333 on March 06, 2018, 12:32:34 pm

All devices with SIGSEGV's (for https://play.google.com/store/apps/details?id=com.aeroshark333.artofearthify):
Samsung Galaxy J1 Ace => Mali-400MP2 or Vivante GC7000 UL - J110L
Motorola Moto E4 (2nd Gen) => Mali-T720
Xiaomi Mi A1 => Adreno 506
Samsung Galacy Note 3 => Adreno 330 - N9005, N9002 or Mali-T628 MP6 - N9000
Lenovo K5 => Adreno 405 or Mali-T860MP2
LGE LG Aristo => Adreno 308

Another app of mine with SIGSEGV's (for https://play.google.com/store/apps/details?id=com.aeroshark333.skinviewer):
Huawei MediaPad => Adreno 220
Samsung Galaxy S3 Neo => Adreno 305
Samsung Galaxy Note 2 => Mali-400MP4
LGE L20 => Mali-400
ZTE Lever Z936L => Adreno 306
Huawei Mate 9 => Mali-G71 MP8
HTC U11+ =>Adreno 540
Motorola Moto X4 => Adreno 508
General Mobile GM6 => Mali-T720 MP2
OnePlus 3T => Adreno 530
Xiaomi Mi A1 => Adreno 506
Samsung Galaxy Tab E 8.0 => Adreno 306
Motorola Moto C Plus => Mali-T720MP2
Samsung Galaxy Tab A 10.1 (2016) => Mali-T830 MP2
Motorola Moto C =>    Mali-T720MP2
Samsung Galaxy Tab 3 Lite 7.0 => Vivante GC1000 (according to specs website but logs mention "libGLES_mali.so"...)
Samsung Galaxy On7 => Adreno 306
LGE Nexus 5X => Adreno 418
Huawei P8 Lite => Mali-T830MP2

So it's mostly (or only?) Adreno/Mali based GPU's for me

I found this while Googling around: https://stackoverflow.com/questions/30825386/android-opengl-fatal-signal-11-sigsegv-code-2
I tried the same code on the Nexus 5 emulator and I got some similar results.
=> size = 10000; would crash
=> size = 3000; would work
=> size = 5000; would crash
=> size = 3500; would crash sometimes?
When it works, I would show nothing but it would keep 'drawing' and not crashing
Adding floatBuffer.rewind(); after giving it values would fix the issue for any size (and it'd actually show something when drawing.. lol).
I'm not sure if this could be helpful but I sure found it interesting.

Title: Re: Crash (native)
Post by: EgonOlsen on March 06, 2018, 04:41:06 pm

That looks more like the normal distribution of GPUs in the Android market than anything else. The stackoverflow post doesn't help either. Of course, I'm rewinding the buffers. Otherwise, it wouldn't be able to render anything in the first place.

Personally, I just accepted a certain "crash rate". It just happens on some devices, may it be caused by driver errors or by some custom rom that has some great "optimization" in it that just doesn't work.

Any ideas about which "in the wild" crash rate we are taking here? 50% 1% 0.1%...any clues?

And because fiddling around with the blitting config seems to changes things for you: Are you actually blitting stuff? What happens if you don't?

Title: Re: Crash (native)
Post by: AeroShark333 on March 06, 2018, 11:47:40 pm

Quote from: EgonOlsen on March 06, 2018, 04:41:06 pm

Any ideas about which "in the wild" crash rate we are taking here? 50% 1% 0.1%...any clues?

Well it depends on the context..? Higher polygon count seems to make it more likely to crash. While lower polygon models don't crash at all...

Quote from: EgonOlsen on March 06, 2018, 04:41:06 pm

And because fiddling around with the blitting config seems to changes things for you: Are you actually blitting stuff? What happens if you don't?

Yes, I do blit things before the first world.draw() call.
=> Texture blits (some of these textures are used for the Object3D's, so the textures get uploaded to the GPU and removed from VM heap memory)
=> Loading screen (probably 50+ blits of a 2x2 texture with variable greyscale color) per frame

I tried to comment out the texture blits (so they'd stay in VM heap memory) => it would still crash
But when I removed all blits (texture+loading blits) before the first draw call, it would work fine.

Also, only have texture blits (without loading screen blits) would still be able to crash but not so likely.

Interesting results I guess...

I once again tested the crashing likelyness (with higher polygon models and with blitting before the first world.draw() call)
=> Config.blittingMode = 8
Runs: 25
Crashes: 17
Result: More than the 50% of last time...
=> Default Config.blittingMode
Runs: 25
Crashes 25
Result: About the same result as last time (100% vs. 96%)

So could it be that blitting anything before having all Object3D data loaded could cause this SIGSEGV issue?

PS: I actually do blit (2D background behind 3D world) before calling the first world.draw() in the other app too actually...

Title: Re: Crash (native)
Post by: EgonOlsen on March 07, 2018, 07:42:51 am

Blitting is just like rendering an object except that the data of that "blitting object" is dynamic and changes every frame. That's not a problem per se, animate objects do exactly the same. A lot of apps using jPCT-AE are doing it all the time (including mine) without any problems. However, I'm well aware that it might cause trouble, which is why there are these config settings for it (which are just some shots in the dark as well). The actual problem is, that I've no idea why this happens and when. I've checked the code at least a dozen times because of this and it's just fine. It's the same code that desktop jPCT uses as well and it doesn't have this problem. My current app is blitting stuff before doing anything else and that is fine as well.

Your apps...are these all wallpapers or standard apps?

Title: Re: Crash (native)
Post by: AeroShark333 on March 07, 2018, 07:53:49 pm

Quote from: EgonOlsen on March 07, 2018, 07:42:51 am

A lot of apps using jPCT-AE are doing it all the time (including mine) without any problems. However, I'm well aware that it might cause trouble, which is why there are these config settings for it (which are just some shots in the dark as well). The actual problem is, that I've no idea why this happens and when. I've checked the code at least a dozen times because of this and it's just fine.

Well yeah, I'm unable to reproduce this SIGSEGV error on most of my devices too, it'd work just fine with the way I render everything now.
And I'm not sure if this blitting before the uploading the Object3D data is actually the issue for all the SIGSEGV reports I got, maybe it would only solve the problem for the emulator.

Quote from: EgonOlsen on March 07, 2018, 07:42:51 am

Your apps...are these all wallpapers or standard apps?

Mixed, however I can run the renderer class in a regular Android Activity too but that'd not really make much of a difference..?
The app I'm currently working on is the wallpaper app, and the other app is a 'standard app' I'd say.

My best workaround/solution for now would be to make sure the Object3D's I'm using are uploaded to the GPU before blitting anything.
Which I'll try to implement soon so I can see if people would still get SIGSEGV's after this.
Though, there's one problem... How can I set textures to my Object3D's after building and compiling them?
If I remember correctly it'd have a delay or something before the textures get visibly applied or something if you do it this way.

Title: Re: Crash (native)
Post by: EgonOlsen on March 08, 2018, 09:07:42 am

Quote from: AeroShark333 on March 07, 2018, 07:53:49 pm

Though, there's one problem... How can I set textures to my Object3D's after building and compiling them?
If I remember correctly it'd have a delay or something before the textures get visibly applied or something if you do it this way.

...I'm not sure what you mean by that...???

Title: Re: Crash (native)
Post by: AeroShark333 on March 09, 2018, 12:07:55 am

Oh... Ehm, nevermind maybe it was scaling..? Ah nevermind this.

However, is it safe to apply textures after having having the Object3D's built and compiled?
It seemed to work just fine? Though, not sure about performance...
However, a multi-textured TextureInfo would give an ArrayOutOfBoundsException when I apply the TextureInfo after having built and compiled.

I also wondered if 16k and 32k textures could be enabled, devices these days can handle quite a lot hehe :)

Title: Re: Crash (native)
Post by: EgonOlsen on March 09, 2018, 08:18:03 am

Yes, it's save and it's cheap. However, compiling the object fixes the texture stage count for it. That's why you are getting that exception with the TextureInfo. YOu could assign a TextureInfo with the same amount of stage but using some dummy textures, compile, assing the actual textures. That should actually work.

16k and 32k...it's absurd IMHO to use those. A 16k texture with 32bit and no compression but mipmaps would require ~2GB auf GPU memory and almost the same in VM memory. Still not very feasible IMHO.

Title: Re: Crash (native)
Post by: AeroShark333 on March 10, 2018, 01:50:35 am

Quote from: EgonOlsen on March 09, 2018, 08:18:03 am

Yes, it's save and it's cheap. However, compiling the object fixes the texture stage count for it. That's why you are getting that exception with the TextureInfo. YOu could assign a TextureInfo with the same amount of stage but using some dummy textures, compile, assing the actual textures. That should actually work.

Alright, thanks for the help! :)

Quote from: EgonOlsen on March 09, 2018, 08:18:03 am

16k and 32k...it's absurd IMHO to use those. A 16k texture with 32bit and no compression but mipmaps would require ~2GB auf GPU memory and almost the same in VM memory. Still not very feasible IMHO.

Hmmm yeah, I understand... Though that would be true for squared textures but for me just one dimension would be okay. I can already kind of use 16384x4096 textures on my phone using NPOTTexture (which I guess is kind of a hack-ish way to surpass the 8192 limit restricted by jPCT. So well yeah...

Title: Re: Crash (native)
Post by: EgonOlsen on March 11, 2018, 05:18:59 pm

Try this jar: http://jpct.de/download/beta/jpct_ae.jar (http://jpct.de/download/beta/jpct_ae.jar)

It should support textures up to 16384 in size.

Title: Re: Crash (native)
Post by: AeroShark333 on March 18, 2018, 04:38:30 pm

Quote from: EgonOlsen on March 09, 2018, 08:18:03 am

Yes, it's save and it's cheap. However, compiling the object fixes the texture stage count for it. That's why you are getting that exception with the TextureInfo. YOu could assign a TextureInfo with the same amount of stage but using some dummy textures, compile, assing the actual textures. That should actually work.

So I tried this with two TextureInfo's (one 3-layered with dummy textureID and one 3-layered with the actual textureID's) but I am still getting the Exception.

Code: [Select]

final int dummyID = textureManager.getTextureID(textureManager.getNameByTexture(textureManager.getDummyTexture()));
final TextureInfo ti = new TextureInfo(dummyID);
ti.add(dummyID, TextureInfo.MODE_ADD);
ti.add(dummyID, TextureInfo.MODE_ADD);

obj.setTexture(ti);
obj.build();
obj.compile();
obj.strip();

world.addObject(obj);
world.renderScene(frameBuffer);
world.draw(frameBuffer);
This is how I first load the Object3D with 3 (not even sure if it actually gives 3...) texturelayers.

But when I apply the real TextureInfo (after loading Textures and getting their ID's) it will crash:

Code: [Select]

03-18 11:35:18.768: E/AndroidRuntime(4487): java.lang.ArrayIndexOutOfBoundsException: length=1; index=1
03-18 11:35:18.768: E/AndroidRuntime(4487): at com.threed.jpct.Object3D.setTexture(Object3D.java:3660)
When the real TextureInfo only holds one texture(layer) it won't crash... So it doesn't really seem to set 3 layers using the dummy textures or something..?

EDIT:
I moved the obj.strip() line to after applying the real TextureInfo, which seemed to fix it...

Title: Re: Crash (native)
Post by: EgonOlsen on March 18, 2018, 08:36:56 pm

Interesting...maybe I'm stripping dummy texture layers away...I'm not sure ATM, but if it works now... ;)

Title: Re: Crash (native)
Post by: AeroShark333 on April 06, 2018, 12:08:44 am

Okay, good and bad news I guess:

Good news:
The SIGSEGV reports seemed to have stopped (on Android 7.1.2 and below at least..).
So the solution to have all vertices/Object3D's loaded to the GPU before any blit/texture data upload seemed to have worked..?

Bad news:
However, I've been getting a new SIGSEGV error now (which only seems to happen on Android 8.0..?):
Crashreport:
On OnePlus 5T and Huawei P20 Lite

Code: [Select]

backtrace:
  #00  pc 000000000030b868  /system/lib64/libskia.so (_ZN15SkScalerContext10getMetricsEP7SkGlyph+40)
  #01  pc 0000000000283b0c  /system/lib64/libskia.so (_ZN12SkGlyphCache16allocateNewGlyphE15SkPackedGlyphIDNS_11MetricsTypeE+360)
  #02  pc 000000000028396c  /system/lib64/libskia.so (_ZN12SkGlyphCache17getGlyphIDMetricsEt+16)
  #03  pc 0000000000278b20  /system/lib64/libskia.so (_ZN19SkFindAndPlaceGlyph26GlyphFindAndPlaceFullPixelIR12DrawOneGlyphLN7SkPaint5AlignE0ELNS_13SelectKerningE0EE20findAndPositionGlyphEPPKc7SkPointS2_+40)
  #04  pc 0000000000276040  /system/lib64/libskia.so (_ZN19SkFindAndPlaceGlyph14ProcessPosTextIR12DrawOneGlyphEEvN7SkPaint12TextEncodingEPKcm7SkPointRK8SkMatrixPKfiNS3_5AlignEP12SkGlyphCacheOT_+972)
  #05  pc 0000000000275bb8  /system/lib64/libskia.so (_ZNK6SkDraw11drawPosTextEPKcmPKfiRK7SkPointRK7SkPaintPK14SkSurfaceProps+400)
  #06  pc 00000000001f41d4  /system/lib64/libskia.so (_ZN14SkBitmapDevice11drawPosTextEPKvmPKfiRK7SkPointRK7SkPaint+112)
  #07  pc 000000000026ee40  /system/lib64/libskia.so (_ZN12SkBaseDevice12drawTextBlobEPK10SkTextBlobffRK7SkPaintP12SkDrawFilter+432)
  #08  pc 0000000000215068  /system/lib64/libskia.so (_ZN8SkCanvas14onDrawTextBlobEPK10SkTextBlobffRK7SkPaint+500)
  #09  pc 0000000000215a20  /system/lib64/libskia.so (_ZN8SkCanvas12drawTextBlobEPK10SkTextBlobffRK7SkPaint+236)
  #10  pc 00000000002600b4  /system/lib64/libskia.so (_ZN23SkColorSpaceXformCanvas14onDrawTextBlobEPK10SkTextBlobffRK7SkPaint+84)
  #11  pc 0000000000215a20  /system/lib64/libskia.so (_ZN8SkCanvas12drawTextBlobEPK10SkTextBlobffRK7SkPaint+236)
  #12  pc 0000000000095f78  /system/lib64/libhwui.so (_ZN7android10SkiaCanvas10drawGlyphsEPKtPKfiRK7SkPaintfffffff+300)
  #13  pc 0000000000037684  /system/lib64/libhwui.so (_ZN7android15DrawTextFunctorclEmm+368)
  #14  pc 0000000000037194  /system/lib64/libhwui.so (_ZN7android12MinikinUtils10forFontRunINS_15DrawTextFunctorEEEvRKN7minikin6LayoutEPNS_5PaintERT_+276)
  #15  pc 0000000000036f98  /system/lib64/libhwui.so (_ZN7android6Canvas8drawTextEPKtiiiffiRKNS_5PaintEPNS_8TypefaceE+356)
  #16  pc 0000000000130b18  /system/lib64/libandroid_runtime.so (_ZN7android9CanvasJNIL14drawTextStringEP7_JNIEnvP8_jobjectlP8_jstringiiffill+136)
  #17  pc 0000000000b5f6b4  /system/framework/arm64/boot-framework.oat (android.graphics.BaseCanvas.nDrawText [DEDUPED]+244)
  #18  pc 0000000000b62cd8  /system/framework/arm64/boot-framework.oat (android.graphics.BaseCanvas.drawText+216)
  #19  pc 0000000000b74924  /system/framework/arm64/boot-framework.oat (android.graphics.Canvas.drawText+52)
  #20  pc 000000000128b2e8  /system/framework/arm64/boot-framework.oat (android.text.BoringLayout.draw+136)
  #21  pc 0000000001540fb4  /system/framework/arm64/boot-framework.oat (android.widget.TextView.onDraw+3316)
  #22  pc 00000000010f6b90  /system/framework/arm64/boot-framework.oat (android.view.View.draw+256)
  #23  pc 00000000010f8360  /system/framework/arm64/boot-framework.oat (android.view.View.draw+3616)
  #24  pc 00000000013c64d4  /system/framework/arm64/boot-framework.oat (android.view.ViewGroup.drawChild+68)
  #25  pc 00000000013c1248  /system/framework/arm64/boot-framework.oat (android.view.ViewGroup.dispatchDraw+1464)
  #26  pc 00000000010f6ba8  /system/framework/arm64/boot-framework.oat (android.view.View.draw+280)
  #27  pc 0000000000509384  /system/lib64/libart.so (art_quick_invoke_stub+580)
  #28  pc 00000000000d8078  /system/lib64/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+200)
  #29  pc 00000000002821dc  /system/lib64/libart.so (_ZN3art11interpreter34ArtInterpreterToCompiledCodeBridgeEPNS_6ThreadEPNS_9ArtMethodEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+352)
  #30  pc 000000000027c8a4  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+672)
  #31  pc 00000000004f3d30  /system/lib64/libart.so (MterpInvokeVirtualQuick+680)
  #32  pc 00000000004fea94  /system/lib64/libart.so (ExecuteMterpImpl+29972)
  #33  pc 000000000025d620  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+444)
  #34  pc 0000000000263d20  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #35  pc 000000000027c884  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #36  pc 00000000004f1e78  /system/lib64/libart.so (MterpInvokeDirect+504)
  #37  pc 00000000004fae14  /system/lib64/libart.so (ExecuteMterpImpl+14484)
  #38  pc 000000000025d620  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+444)
  #39  pc 0000000000263d20  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #40  pc 000000000027c884  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #41  pc 00000000004f1e78  /system/lib64/libart.so (MterpInvokeDirect+504)
  #42  pc 00000000004fae14  /system/lib64/libart.so (ExecuteMterpImpl+14484)
  #43  pc 000000000025d620  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+444)
  #44  pc 0000000000263d20  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #45  pc 000000000027c884  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #46  pc 00000000004f3d30  /system/lib64/libart.so (MterpInvokeVirtualQuick+680)
  #47  pc 00000000004fea94  /system/lib64/libart.so (ExecuteMterpImpl+29972)
  #48  pc 000000000025d620  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+444)
  #49  pc 0000000000263d20  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #50  pc 000000000027d6f4  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb1ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+584)
  #51  pc 00000000004f3754  /system/lib64/libart.so (MterpInvokeDirectRange+424)
  #52  pc 00000000004fb114  /system/lib64/libart.so (ExecuteMterpImpl+15252)
  #53  pc 000000000025d620  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+444)
  #54  pc 0000000000263d20  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #55  pc 000000000027c884  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #56  pc 00000000004f1e78  /system/lib64/libart.so (MterpInvokeDirect+504)
  #57  pc 00000000004fae14  /system/lib64/libart.so (ExecuteMterpImpl+14484)
  #58  pc 000000000025d620  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+444)
  #59  pc 0000000000263d20  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #60  pc 000000000027c884  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #61  pc 00000000004f1e78  /system/lib64/libart.so (MterpInvokeDirect+504)
  #62  pc 00000000004fae14  /system/lib64/libart.so (ExecuteMterpImpl+14484)
  #63  pc 000000000025d620  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+444)
Galaxy S8 And Galaxy S8+

Code: [Select]

backtrace:
  #00  pc 00400e60f947a908  <unknown>
  #01  pc 0000000000330400  /system/lib64/libskia.so (_ZN15SkScalerContext10getMetricsEP7SkGlyph+48)
  #02  pc 000000000029f404  /system/lib64/libskia.so (_ZN12SkGlyphCache16allocateNewGlyphE15SkPackedGlyphIDNS_11MetricsTypeE+372)
  #03  pc 000000000029f250  /system/lib64/libskia.so (_ZN12SkGlyphCache17getGlyphIDMetricsEt+16)
  #04  pc 0000000000293b38  /system/lib64/libskia.so (_ZN19SkFindAndPlaceGlyph26GlyphFindAndPlaceFullPixelIR12DrawOneGlyphLN7SkPaint5AlignE0ELNS_13SelectKerningE0EE20findAndPositionGlyphEPPKc7SkPointS2_+40)
  #05  pc 0000000000290ecc  /system/lib64/libskia.so (_ZN19SkFindAndPlaceGlyph14ProcessPosTextIR12DrawOneGlyphEEvN7SkPaint12TextEncodingEPKcm7SkPointRK8SkMatrixPKfiNS3_5AlignEP12SkGlyphCacheOT_+940)
  #06  pc 0000000000290a60  /system/lib64/libskia.so (_ZNK6SkDraw11drawPosTextEPKcmPKfiRK7SkPointRK7SkPaintPK14SkSurfaceProps+400)
  #07  pc 000000000020ad00  /system/lib64/libskia.so (_ZN14SkBitmapDevice11drawPosTextEPKvmPKfiRK7SkPointRK7SkPaint+112)
  #08  pc 00000000002897e4  /system/lib64/libskia.so (_ZN12SkBaseDevice12drawTextBlobEPK10SkTextBlobffRK7SkPaintP12SkDrawFilter+436)
  #09  pc 000000000022e1cc  /system/lib64/libskia.so (_ZN8SkCanvas14onDrawTextBlobEPK10SkTextBlobffRK7SkPaint+524)
  #10  pc 000000000022ebbc  /system/lib64/libskia.so (_ZN8SkCanvas12drawTextBlobEPK10SkTextBlobffRK7SkPaint+236)
  #11  pc 0000000000279fc4  /system/lib64/libskia.so (_ZN23SkColorSpaceXformCanvas14onDrawTextBlobEPK10SkTextBlobffRK7SkPaint+84)
  #12  pc 000000000022ebbc  /system/lib64/libskia.so (_ZN8SkCanvas12drawTextBlobEPK10SkTextBlobffRK7SkPaint+236)
  #13  pc 000000000009d92c  /system/lib64/libhwui.so (_ZN7android10SkiaCanvas10drawGlyphsEPKtPKfiRK7SkPaintfffffff+300)
  #14  pc 0000000000039380  /system/lib64/libhwui.so (_ZN7android15DrawTextFunctorclEmm+368)
  #15  pc 0000000000038e84  /system/lib64/libhwui.so (_ZN7android12MinikinUtils10forFontRunINS_15DrawTextFunctorEEEvRKN7minikin6LayoutEPNS_5PaintERT_+276)
  #16  pc 0000000000038c84  /system/lib64/libhwui.so (_ZN7android6Canvas8drawTextEPKtiiiffiRKNS_5PaintEPNS_8TypefaceE+356)
  #17  pc 0000000000177448  /system/lib64/libandroid_runtime.so (_ZN7android9CanvasJNIL14drawTextStringEP7_JNIEnvP8_jobjectlP8_jstringiiffill+136)
  #18  pc 0000000000bb5f34  /system/framework/arm64/boot-framework.oat (android.graphics.BaseCanvas.nDrawText [DEDUPED]+244)
  #19  pc 0000000000bb95d4  /system/framework/arm64/boot-framework.oat (android.graphics.BaseCanvas.drawText+244)
  #20  pc 0000000000bcaad4  /system/framework/arm64/boot-framework.oat (android.graphics.Canvas.drawText+52)
  #21  pc 00000000013ab328  /system/framework/arm64/boot-framework.oat (android.text.BoringLayout.draw+136)
  #22  pc 000000000167c3bc  /system/framework/arm64/boot-framework.oat (android.widget.TextView.onDraw+3980)
  #23  pc 0000000001158814  /system/framework/arm64/boot-framework.oat (android.view.View.draw+308)
  #24  pc 000000000115a0f0  /system/framework/arm64/boot-framework.oat (android.view.View.draw+3616)
  #25  pc 00000000011934e0  /system/framework/arm64/boot-framework.oat (android.view.ViewGroup.drawChild+64)
  #26  pc 000000000118dd1c  /system/framework/arm64/boot-framework.oat (android.view.ViewGroup.dispatchDraw+1468)
  #27  pc 000000000115882c  /system/framework/arm64/boot-framework.oat (android.view.View.draw+332)
  #28  pc 000000000052df84  /system/lib64/libart.so (art_quick_invoke_stub+580)
  #29  pc 00000000000d86a8  /system/lib64/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+200)
  #30  pc 0000000000291720  /system/lib64/libart.so (_ZN3art11interpreter34ArtInterpreterToCompiledCodeBridgeEPNS_6ThreadEPNS_9ArtMethodEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+352)
  #31  pc 000000000028bd30  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+672)
  #32  pc 0000000000518898  /system/lib64/libart.so (MterpInvokeVirtualQuick+680)
  #33  pc 0000000000523714  /system/lib64/libart.so (ExecuteMterpImpl+29972)
  #34  pc 000000000026bed0  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+448)
  #35  pc 0000000000272794  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #36  pc 000000000028bd10  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #37  pc 00000000005169b8  /system/lib64/libart.so (MterpInvokeDirect+504)
  #38  pc 000000000051fa94  /system/lib64/libart.so (ExecuteMterpImpl+14484)
  #39  pc 000000000026bed0  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+448)
  #40  pc 0000000000272794  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #41  pc 000000000028bd10  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #42  pc 00000000005169b8  /system/lib64/libart.so (MterpInvokeDirect+504)
  #43  pc 000000000051fa94  /system/lib64/libart.so (ExecuteMterpImpl+14484)
  #44  pc 000000000026bed0  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+448)
  #45  pc 0000000000272794  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #46  pc 000000000028bd10  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #47  pc 0000000000518898  /system/lib64/libart.so (MterpInvokeVirtualQuick+680)
  #48  pc 0000000000523714  /system/lib64/libart.so (ExecuteMterpImpl+29972)
  #49  pc 000000000026bed0  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+448)
  #50  pc 0000000000272794  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #51  pc 000000000028cbec  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb1ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+684)
  #52  pc 00000000005182b8  /system/lib64/libart.so (MterpInvokeDirectRange+424)
  #53  pc 000000000051fd94  /system/lib64/libart.so (ExecuteMterpImpl+15252)
  #54  pc 000000000026bed0  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+448)
  #55  pc 0000000000272794  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #56  pc 000000000028bd10  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #57  pc 00000000005169b8  /system/lib64/libart.so (MterpInvokeDirect+504)
  #58  pc 000000000051fa94  /system/lib64/libart.so (ExecuteMterpImpl+14484)
  #59  pc 000000000026bed0  /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadEPKNS_7DexFile8CodeItemERNS_11ShadowFrameENS_6JValueEb+448)
  #60  pc 0000000000272794  /system/lib64/libart.so (_ZN3art11interpreter33ArtInterpreterToInterpreterBridgeEPNS_6ThreadEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+212)
  #61  pc 000000000028bd10  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+640)
  #62  pc 00000000005169b8  /system/lib64/libart.so (MterpInvokeDirect+504)
  #63  pc 000000000051fa94  /system/lib64/libart.so (ExecuteMterpImpl+14484)
Seems to be a similar crash on all 4 devices (just different code-lines on the Samsung devices)

EDIT: I'm actually not sure if this SIGSEGV is related to jPCT... :|

Title: Re: Crash (native)
Post by: EgonOlsen on April 06, 2018, 07:57:30 am

Looks like something related to font rendering to me. I don't think that this relates to jPCT...

Title: Re: Crash (native)
Post by: AeroShark333 on September 19, 2018, 12:36:48 pm

Unfortunately I am still getting the SIGSEGV errors...

However, I came across this:
https://stackoverflow.com/questions/18531835/java-android-fatal-signal-11-sigsegv
"The answer was that the buffer wasn't big enough. Then the openGL API (in my case) accessed an invalid offset (in low-level) and caused a segmentation fault, just like one would get for accessing invalid memory in C. This happens outside of java because bytebuffers are managed by the kernel to allow hardware and low-level code work with your memory."
Is it possible to check the buffers are initialized properly or something? (like see if everything (begin and end) in the buffer is accessible)
I don't know which buffer the problem is (I suppose jPCT has multiple buffers for different things)

Workflow:
Load the Object3D's (by world.renderScene + world.draw) individually which works fine (this should upload their meshes to the GPU I suppose)
Load textures and blit textures (so the VM memory is cleared)
Give all Object3D's their new scaling + position
Add all Object3D's to the world
@first draw world call => SIGSEGV crash (does not always crash)

Note: lower poly models reduce the crash rates

Title: Re: Crash (native)
Post by: EgonOlsen on September 19, 2018, 02:34:56 pm

The buffer sizes are fine. I've checked that multiple times in the past, because I had similar problems on some devices and on the desktop as well. If they wouldn't be, the engine couldn't even store the data in the first place, because it would crash with a buffer overflow kind of exception. You can do such things in C, but not in Java (unless you are assigning the wrong buffer, but that's not the case either).

Title: Re: Crash (native)
Post by: AeroShark333 on September 26, 2018, 03:06:30 am

Hmmm, alright...
I found something interesting maybe:
I have 3 polygon models (model0 = low polygon count, model1 = medium polygon count, model2 = high polygon count)

When using model2:

Code: [Select]

09-26 00:54:36.307 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 0 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33784
    a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 0 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33280
09-26 00:54:36.308 12287-12307/com.aeroshark333.artofearthify I/ArtOfEarthify: Done loading models
09-26 00:54:36.310 12287-12307/com.aeroshark333.artofearthify I/3.artofearthif: Waiting for a blocking GC Explicit
09-26 00:54:36.363 12287-12298/com.aeroshark333.artofearthify I/3.artofearthif: Background concurrent copying GC freed 1087(1323KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 256MB/262MB, paused 447us total 235.483ms
09-26 00:54:36.363 12287-12307/com.aeroshark333.artofearthify I/3.artofearthif: WaitForGcToComplete blocked Explicit on ProfileSaver for 52.895ms
09-26 00:54:36.472 12287-12307/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 4147(769KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 256MB/262MB, paused 463us total 109.121ms
09-26 00:54:36.598 12287-12307/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 5(32KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 256MB/262MB, paused 459us total 124.721ms
09-26 00:54:36.764 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 00:54:36.765 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2208
09-26 00:54:36.884 12287-12307/com.aeroshark333.artofearthify I/ArtOfEarthify: Loaded textures: 2
09-26 00:54:36.889 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 00:54:36.891 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2272
09-26 00:54:37.052 12287-12307/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 573(59KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 256MB/262MB, paused 590us total 103.887ms
09-26 00:54:37.178 12287-12307/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 12(32KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 256MB/262MB, paused 446us total 125.404ms
09-26 00:54:37.331 12287-12307/com.aeroshark333.artofearthify W/jPCT-AE: [ 1537923277331 ] - WARNING: Texture's size is 2/1, but textures should be square for OpenGL ES2.0! This may result in a black texture!
When using model1:

Code: [Select]

09-26 01:03:21.295 12390-12594/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xd5376560
    Out of bounds vertex attribute info: clientArray? 0 attribute 3 vbo 11 allocedBufferSize 5296 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33488
09-26 01:03:21.295 12390-12594/com.aeroshark333.artofearthify I/ArtOfEarthify: Done loading models
09-26 01:03:21.295 12390-12594/com.aeroshark333.artofearthify I/3.artofearthif: Waiting for a blocking GC Explicit
09-26 01:03:21.322 12390-12401/com.aeroshark333.artofearthify I/3.artofearthif: Background concurrent copying GC freed 902(1075KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 264MB/270MB, paused 2.438ms total 206.115ms
09-26 01:03:21.322 12390-12594/com.aeroshark333.artofearthify I/3.artofearthif: WaitForGcToComplete blocked Explicit on HeapTrim for 26.936ms
09-26 01:03:21.464 12390-12594/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 4930(1148KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 263MB/269MB, paused 1.051ms total 141.794ms
09-26 01:03:21.594 12390-12594/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 5(32KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 263MB/269MB, paused 442us total 127.988ms
09-26 01:03:21.858 12390-12594/com.aeroshark333.artofearthify I/ArtOfEarthify: Loaded textures: 2
09-26 01:03:22.048 12390-12594/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 572(59KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 263MB/269MB, paused 481us total 139.200ms
09-26 01:03:22.174 12390-12594/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 12(32KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 263MB/269MB, paused 446us total 124.181ms
09-26 01:03:22.324 12390-12594/com.aeroshark333.artofearthify W/jPCT-AE: [ 1537923802324 ] - WARNING: Texture's size is 2/1, but textures should be square for OpenGL ES2.0! This may result in a black texture!
When using model0:

Code: [Select]

09-26 01:05:03.534 12390-12401/com.aeroshark333.artofearthify I/3.artofearthif: Background concurrent copying GC freed 60908(7MB) AllocSpace objects, 615(16MB) LOS objects, 29% free, 14MB/20MB, paused 855us total 130.193ms
09-26 01:05:03.636 12390-12623/com.aeroshark333.artofearthify I/ArtOfEarthify: Loading background object!
09-26 01:05:03.712 12390-12623/com.aeroshark333.artofearthify I/ArtOfEarthify: Loading sun object!
09-26 01:05:03.780 12390-12623/com.aeroshark333.artofearthify I/ArtOfEarthify: Loading moon object!
09-26 01:05:03.801 12390-12623/com.aeroshark333.artofearthify I/ArtOfEarthify: Done moon object!
09-26 01:05:03.837 12390-12623/com.aeroshark333.artofearthify I/System.out: 2b
09-26 01:05:03.837 12390-12623/com.aeroshark333.artofearthify I/ArtOfEarthify: 3
09-26 01:05:04.019 12390-12401/com.aeroshark333.artofearthify I/3.artofearthif: Background concurrent copying GC freed 3522(952KB) AllocSpace objects, 0(0B) LOS objects, 3% free, 146MB/152MB, paused 608us total 132.321ms
09-26 01:05:04.213 12390-12623/com.aeroshark333.artofearthify I/ArtOfEarthify: Done loading models
09-26 01:05:04.213 12390-12623/com.aeroshark333.artofearthify I/3.artofearthif: Waiting for a blocking GC Explicit
09-26 01:05:04.236 12390-12401/com.aeroshark333.artofearthify I/3.artofearthif: Background concurrent copying GC freed 1140(1393KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 260MB/266MB, paused 4.783ms total 200.504ms
09-26 01:05:04.236 12390-12623/com.aeroshark333.artofearthify I/3.artofearthif: WaitForGcToComplete blocked Explicit on ProfileSaver for 23.046ms
09-26 01:05:04.345 12390-12623/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 3486(1970KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 258MB/264MB, paused 457us total 109.524ms
09-26 01:05:04.472 12390-12623/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 5(32KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 258MB/264MB, paused 481us total 124.901ms
09-26 01:05:04.799 12390-12623/com.aeroshark333.artofearthify I/ArtOfEarthify: Loaded textures: 2
09-26 01:05:04.950 12390-12623/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 577(75KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 258MB/264MB, paused 464us total 118.729ms
09-26 01:05:05.083 12390-12623/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 12(32KB) AllocSpace objects, 0(0B) LOS objects, 2% free, 258MB/264MB, paused 456us total 131.184ms
09-26 01:05:05.234 12390-12623/com.aeroshark333.artofearthify W/jPCT-AE: [ 1537923905234 ] - WARNING: Texture's size is 2/1, but textures should be square for OpenGL ES2.0! This may result in a black texture!
I have not loaded any textures before loading these Object3D's (except dummytextures?) that but this memory usage is too high...?
^So that's because I draw the world a lot before loading the textures to make sure the object3d's are properly loaded (but I believe this is pointless so I removed that)
The memory usage is around 20MB now, but it'd still crash with the low-poly model (model0)

The application can SIGSEGV crash with with all three models...
Any idea why?

Title: Re: Crash (native)
Post by: EgonOlsen on September 26, 2018, 10:11:36 am

This looks very strange:

Code: [Select]

09-26 00:54:36.764 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 00:54:36.765 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2208
09-26 00:54:36.884 12287-12307/com.aeroshark333.artofearthify I/ArtOfEarthify: Loaded textures: 2
09-26 00:54:36.889 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 00:54:36.891 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2272
It's obviously the same buffer instance, which the driver tries to fill with different sized input data...which never fits. I've no idea why that is.
Could you try to set Config.byteBufferLimit to 0 (or some other small value) to see if that changes anything?

Title: Re: Crash (native)
Post by: AeroShark333 on September 26, 2018, 02:24:32 pm

When Config.byteBufferLimit = 0:

Code: [Select]

09-26 12:02:52.714 5293-5313/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xd5a0f240
    Out of bounds vertex attribute info: clientArray? 0 attribute 2 vbo 56 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33280
    a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xebe0fe90
    Out of bounds vertex attribute info: clientArray? 0 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33280
    a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xebe0fe90
    Out of bounds vertex attribute info: clientArray? 0 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33784
    a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xebe0fe90
    Out of bounds vertex attribute info: clientArray? 0 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33280
09-26 12:02:52.715 5293-5313/com.aeroshark333.artofearthify I/System.out: 2b
09-26 12:02:52.715 5293-5313/com.aeroshark333.artofearthify I/ArtOfEarthify: 3
09-26 12:02:52.741 5293-5313/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 49894(2042KB) AllocSpace objects, 38(3MB) LOS objects, 23% free, 20MB/26MB, paused 862us total 24.748ms
09-26 12:02:52.765 5293-5313/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 139(36KB) AllocSpace objects, 0(0B) LOS objects, 23% free, 20MB/26MB, paused 720us total 22.994ms
09-26 12:02:52.917 5293-5313/com.aeroshark333.artofearthify I/ArtOfEarthify: Done loading models
09-26 12:02:52.946 5293-5313/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 27(31KB) AllocSpace objects, 0(0B) LOS objects, 23% free, 20MB/26MB, paused 579us total 28.449ms
09-26 12:02:52.980 5293-5313/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 5(32KB) AllocSpace objects, 0(0B) LOS objects, 23% free, 20MB/26MB, paused 576us total 30.571ms
09-26 12:02:53.155 5293-5313/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xebe0fe90
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 12:02:53.164 5293-5313/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xebe0fe90
09-26 12:02:53.165 5293-5313/com.aeroshark333.artofearthify E/emuglGLESv2_enc: Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2208
09-26 12:02:53.330 5293-5313/com.aeroshark333.artofearthify I/ArtOfEarthify: Loaded textures: 2
09-26 12:02:53.333 5293-5313/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xebe0fe90
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 12:02:53.335 5293-5313/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xebe0fe90
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2272
09-26 12:02:53.402 5293-5313/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 575(75KB) AllocSpace objects, 0(0B) LOS objects, 22% free, 20MB/26MB, paused 579us total 30.227ms
09-26 12:02:53.437 5293-5313/com.aeroshark333.artofearthify I/3.artofearthif: Explicit concurrent copying GC freed 12(32KB) AllocSpace objects, 0(0B) LOS objects, 22% free, 20MB/26MB, paused 590us total 32.737ms
09-26 12:02:53.592 5293-5313/com.aeroshark333.artofearthify W/jPCT-AE: [ 1537963373592 ] - WARNING: Texture's size is 2/1, but textures should be square for OpenGL ES2.0! This may result in a black texture!
It will print a similar stacktrace for
Config.byteBufferLimit = 16;
Config.byteBufferLimit *= 64;

But maybe it's just an issue with the emulator..?
Since even when these 'out of boundary' messages get spammed, the application might still work (randomly...)
The crashing error does happen on real physical devices though (the SIGSEGV's)

I wondered, is it bad practice to pre-load the Object3D's by calling world.renderScene() and world.draw() often after each other when the camera is looking at all the Object3D's?
Because I currently do this but I have a feeling that a lot of draw calls at once isn't good for memory or something..?

Also, when using Config.useVBO = false the application would already crash before any texture loading happens (so when the geometry's are drawn with dummy textures)
It seems to be able to make some world draws but it crashes after a few, while Config.useVBO = true has no issues to load geometries here

Title: Re: Crash (native)
Post by: EgonOlsen on September 27, 2018, 08:20:20 am

I'm really not sure about this emulator thing. I would say, it's a emulator issue, because it doesn't make any sense what it's printing out there. I don't reserve these 2064 byte large buffers for sure.
I'm not sure how your loading and rendering mix...maybe it's a threading issue of some kind? Maybe it tries to render objects that aren't fully processed?

Title: Re: Crash (native)
Post by: AeroShark333 on September 27, 2018, 01:37:29 pm

Hmmm, that is weird...

I don't think it is a threading issue since I'm loading the objects and geometries in the GLThread...
Maybe it tries to render objects that aren't fully processed? => How can I know this?

Also, the crash also happens when only using drawWireFrame(...) instead of draw(...), I don't know if this can give you some clue but who knows

Title: Re: Crash (native)
Post by: jaco robier on September 27, 2018, 09:37:19 pm

Me too, I sometimes had the crash error :
"GC_FOR_ALLOC freed 1030K, 10% free 38859K/42784K, paused 5ms, total 5ms
Fatal signal 11 (SIGSEGV) at 0x97319048 (code = 2), thread 1217 (otic.industrial)".
it was sometimes at the start of my app when I loaded a file "factory.SER".

Since then I used another 3D software to convert and generate "factory.obj" file and started serialization again. it fix this problem and i do not understand why my old "factory.obj" file was bad ? serialization issue ?  format Wavefront .obj incompatible ?

Title: Re: Crash (native)
Post by: EgonOlsen on September 28, 2018, 08:25:23 am

Quote from: jaco robier on September 27, 2018, 09:37:19 pm

Since then I used another 3D software to convert and generate "factory.obj" file and started serialization again. it fix this problem and i do not understand why my old "factory.obj" file was bad ? serialization issue ?  format Wavefront .obj incompatible ?

Any problems with the format itself should never lead to a native crash. Looks more like some kind of memory issue to me...these things are very hard to track, because there are gazillions of different devices out there and I've seen all kinds of strange behaviour from some of them.

Title: Re: Crash (native)
Post by: EgonOlsen on September 28, 2018, 08:28:05 am

Quote from: AeroShark333 on September 27, 2018, 01:37:29 pm

Also, the crash also happens when only using drawWireFrame(...) instead of draw(...), I don't know if this can give you some clue but who knows

I don't think so. It's basically using the same data in a different way. Lets take one step back to narrow it down, please:

• On which devices (exact model number if possible) does this happen?
• Which Android versions are affected?
• Does it happen only sometimes or all of the time?
• Can you provide a simple test case that has this problem?

Title: Re: Crash (native)
Post by: AeroShark333 on September 30, 2018, 12:19:44 pm

Which devices? => See post #25 in this thread for some of the devices affected
My 'device' (actually emulator) I use to reproduce the error: Nexus 5X API 28 x86 (Android 9, API 28) (This one should be downloadable from Android Studio)

Which Android versions? Any...

Sometimes or all the time? Depends, for low-polygon models it happens less often but for high-polygon models more often.

Test case: https://www.dropbox.com/s/rsoz0dhm1sds6wm/TestCase.zip?dl=1
(the code is a little messy but I mostly stripped code from the original application)

Stacktrace (working):

Code: [Select]

09-30 10:18:59.541 26730-26750/com.aeroshark333.testcase W/jPCT-AE: [ 1538302739541 ] - WARNING: OpenGL vendor:     Google (NVIDIA Corporation)
    [ 1538302739541 ] - WARNING: OpenGL renderer:   Android Emulator OpenGL ES Translator (GeForce GTX 950M/PCIe/SSE2)
    [ 1538302739541 ] - WARNING: OpenGL version:    OpenGL ES 2.0 (4.5.0 NVIDIA 398.11)
    [ 1538302739541 ] - WARNING: OpenGL renderer initialized (using 4/32 texture stages)
09-30 10:18:59.542 26730-26750/com.aeroshark333.testcase I/System.out: Sensor Detection Started!
09-30 10:18:59.548 26730-26730/com.aeroshark333.testcase I/System.out: Error.
09-30 10:18:59.549 26730-26730/com.aeroshark333.testcase I/chatty: uid=10084(com.aeroshark333.testcase) identical 2 lines
09-30 10:18:59.562 26730-26730/com.aeroshark333.testcase I/System.out: Error.
09-30 10:18:59.673 26730-26750/com.aeroshark333.testcase I/ArtOfEarthify: Loading blit shaders!
09-30 10:18:59.753 26730-26750/com.aeroshark333.testcase I/ArtOfEarthify: Loading earth object!
09-30 10:18:59.867 26730-26741/com.aeroshark333.testcase I/ark333.testcas: Background concurrent copying GC freed 10715(711KB) AllocSpace objects, 2(48KB) LOS objects, 46% free, 7MB/13MB, paused 5.656ms total 28.853ms
09-30 10:19:00.130 26730-26750/com.aeroshark333.testcase I/ArtOfEarthify: Loading background object!
09-30 10:19:00.249 26730-26750/com.aeroshark333.testcase I/ArtOfEarthify: Loading sun object!
09-30 10:19:00.397 26730-26750/com.aeroshark333.testcase I/ArtOfEarthify: Loading moon object!
09-30 10:19:00.412 26730-26750/com.aeroshark333.testcase I/ArtOfEarthify: Done moon object!
09-30 10:19:00.524 26730-26750/com.aeroshark333.testcase I/ArtOfEarthify: Done loading models
09-30 10:19:00.555 26730-26750/com.aeroshark333.testcase I/ark333.testcas: Explicit concurrent copying GC freed 25326(1094KB) AllocSpace objects, 29(2MB) LOS objects, 39% free, 9MB/15MB, paused 668us total 28.008ms
09-30 10:19:00.570 26730-26750/com.aeroshark333.testcase I/ark333.testcas: Explicit concurrent copying GC freed 153(52KB) AllocSpace objects, 0(0B) LOS objects, 39% free, 9MB/15MB, paused 590us total 13.971ms
09-30 10:19:00.758 26730-26750/com.aeroshark333.testcase I/System.out: beep0a
    beep0b
    beep0c
09-30 10:19:00.759 26730-26750/com.aeroshark333.testcase I/System.out: beep1a
    beep1b
09-30 10:19:00.763 26730-26750/com.aeroshark333.testcase I/System.out: beep1c
09-30 10:19:00.764 26730-26750/com.aeroshark333.testcase I/System.out: beep2
    beep3
09-30 10:19:00.765 26730-26750/com.aeroshark333.testcase I/System.out: beep4
    beep5
09-30 10:19:00.766 26730-26750/com.aeroshark333.testcase I/System.out: beep6
09-30 10:19:00.784 26730-26750/com.aeroshark333.testcase I/ark333.testcas: Explicit concurrent copying GC freed 346(74KB) AllocSpace objects, 15(2MB) LOS objects, 46% free, 7MB/13MB, paused 550us total 17.247ms
09-30 10:19:00.799 26730-26750/com.aeroshark333.testcase I/ark333.testcas: Explicit concurrent copying GC freed 13(48KB) AllocSpace objects, 0(0B) LOS objects, 46% free, 7MB/13MB, paused 439us total 14.073ms
09-30 10:19:00.975 26730-26750/com.aeroshark333.testcase W/jPCT-AE: [ 1538302740975 ] - WARNING: Your application uses default shaders, but they have been disabled in Config. Consider to enable them or performance will suffer!
09-30 10:19:00.990 26730-26750/com.aeroshark333.testcase E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xd72bcf20
    Out of bounds vertex attribute info: clientArray? 0 attribute 3 vbo 15 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33784
09-30 10:19:00.991 26730-26750/com.aeroshark333.testcase E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xd72bcf50
    Out of bounds vertex attribute info: clientArray? 0 attribute 4 vbo 16 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 33784
    a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xd72bcf80

Stacktrace (not working):

Code: [Select]

09-30 10:16:31.090 26487-26518/com.aeroshark333.testcase W/jPCT-AE: [ 1538302591089 ] - WARNING: OpenGL vendor:     Google (NVIDIA Corporation)
    [ 1538302591090 ] - WARNING: OpenGL renderer:   Android Emulator OpenGL ES Translator (GeForce GTX 950M/PCIe/SSE2)
09-30 10:16:31.091 26487-26518/com.aeroshark333.testcase W/jPCT-AE: [ 1538302591091 ] - WARNING: OpenGL version:    OpenGL ES 2.0 (4.5.0 NVIDIA 398.11)
    [ 1538302591091 ] - WARNING: OpenGL renderer initialized (using 4/32 texture stages)
09-30 10:16:31.114 26487-26518/com.aeroshark333.testcase I/System.out: Sensor Detection Started!
09-30 10:16:31.189 26487-26487/com.aeroshark333.testcase I/System.out: Error.
09-30 10:16:31.189 26487-26487/com.aeroshark333.testcase I/chatty: uid=10084(com.aeroshark333.testcase) identical 3 lines
09-30 10:16:31.189 26487-26487/com.aeroshark333.testcase I/System.out: Error.
09-30 10:16:31.282 26487-26518/com.aeroshark333.testcase I/ArtOfEarthify: Loading blit shaders!
09-30 10:16:31.351 26487-26518/com.aeroshark333.testcase I/ArtOfEarthify: Loading earth object!
09-30 10:16:31.579 26487-26518/com.aeroshark333.testcase I/ArtOfEarthify: Loading background object!
09-30 10:16:31.746 26487-26518/com.aeroshark333.testcase I/ArtOfEarthify: Loading sun object!
09-30 10:16:31.879 26487-26518/com.aeroshark333.testcase I/ArtOfEarthify: Loading moon object!
09-30 10:16:31.894 26487-26518/com.aeroshark333.testcase I/ArtOfEarthify: Done moon object!
09-30 10:16:31.990 26487-26518/com.aeroshark333.testcase I/ArtOfEarthify: Done loading models
09-30 10:16:32.028 26487-26518/com.aeroshark333.testcase I/ark333.testcas: Explicit concurrent copying GC freed 26739(1115KB) AllocSpace objects, 29(2MB) LOS objects, 22% free, 20MB/26MB, paused 730us total 37.701ms
09-30 10:16:32.067 26487-26518/com.aeroshark333.testcase I/ark333.testcas: Explicit concurrent copying GC freed 209(52KB) AllocSpace objects, 0(0B) LOS objects, 22% free, 20MB/26MB, paused 1.073ms total 37.880ms
09-30 10:16:32.257 26487-26518/com.aeroshark333.testcase I/System.out: beep0a
    beep0b
09-30 10:16:32.258 26487-26518/com.aeroshark333.testcase I/System.out: beep0c
    beep1a
    beep1b
09-30 10:16:32.259 26487-26518/com.aeroshark333.testcase A/libc: Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xf1cc2000 in tid 26518 (GLThread 2033), pid 26487 (ark333.testcase)


Title: Re: Crash (native)
Post by: EgonOlsen on October 01, 2018, 10:25:32 pm

Thanks. I'll go and try the test case on my devices (...when I'm back from holiday) to find one that crashes and start from there. I really don't trust emulators, so I prefer to find a non-working device instead.

Title: Re: Crash (native)
Post by: AeroShark333 on October 07, 2018, 07:43:59 pm

I don't know if you had time to look into this yet... but any results?

Title: Re: Crash (native)
Post by: EgonOlsen on October 08, 2018, 09:53:19 am

No, I just came back from holiday.

Title: Re: Crash (native)
Post by: EgonOlsen on October 09, 2018, 08:08:18 pm

After downloading half the internet to upgrade to AS 3.2, I now had the chance to try the test case. What exactly is it supposed to do? I can see some "loading" message followed by a white screen. Is that intentional or am I missing something?

If the emulator runs (in most cases, it just crashes (not the app in the emulator, but the whole emulator)), it also prints out these buffer size warnings. However, I've checked the code again...it's impossible that I reserve the wrong size for them, simply because I'm using the Android API to create them based on int[]-arrays. If the Android API reserves 2064 bytes for and int[]-array of 33292 bytes and then wonders why it doesn't fit, then I'm out of luck. But I don't think that's the case. I think the emulator messages are a red hering.

Title: Re: Crash (native)
Post by: AeroShark333 on October 10, 2018, 03:33:54 pm

It is supposed to get to that white screen yes.
However, some devices won't get to this white screen and crash in the world.draw() calls in the loading process or the actual 'first' world.draw() call when the actual 3D rendering happens (after the loading process)

The crash does not always happen but I do keep getting these SIGSEGV errors in Google Play Store developer console from actual devices. I was able to 'reproduce' (on my old (now broken) HTC Desire 820) this error. So now the only thing that can help me reproduce the error is the emulator with Nexus 5X API28 x86 Android 9.

But I am not able (or rarely able) to reproduce the error with much lower polygon models so is it possible to load higher polygon models as if they were lower polygon models somehow? No idea here... world.drawWireFrame() and world.draw() both produce the SIGZSEGV.

Sidenote: Config.useVBO = false only seems to make the crashrates worse for me on the emulator

Title: Re: Crash (native)
Post by: AeroShark333 on October 13, 2018, 09:35:14 am

Any clues? Or ideas left to how to solve this?

Title: Re: Crash (native)
Post by: EgonOlsen on October 16, 2018, 10:46:34 am

So far, I wasn't able to reproduce it. What's your actual crash rate in Google Play that can be attributed to such kind of native crashes?

Title: Re: Crash (native)
Post by: AeroShark333 on October 17, 2018, 11:13:06 pm

Hmmm weird...
Does Config.useVBO = false; also not help to reproduce the error?
For me, setting the Config.useVBO = false; would only increase the likelyhood of crashing.

The crashreports for different SIGSEGV's for the last 60 days from Google Play:
1 user(s), 49 crashes (code=2)
3 user(s), 10 crashes (code=1)
1 user(s), 03 crashes (code=1)
2 user(s), 03 crashes (code=1)
2 user(s), 02 crashes (code=1)
2 user(s), 02 crashes (code=2)
2 user(s), 02 crashes (code=2)
1 user(s), 02 crashes (code=0)
2 user(s), 02 crashes (abort)
1 user(s), 02 crashes (code=2)
1 user(s), 02 crashes (code=2)
1 user(s), 01 crashes (code=2)
1 user(s), 01 crashes (code=2)
1 user(s), 01 crashes (code=1)
1 user(s), 01 crashes (code=2)
1 user(s), 02 crashes (code=1)

code = 0: signal 11 (SIGSEGV), code 0 (SI_USER)
code = 1: signal 11 (SIGSEGV), code 1 (SIGV_MAPERR)
code = 2: signal 11 (SIGSEGV), code 2 (SIGV_ACCERR)
abort: no idea..? (probably also some kind of SIGSEGV)

Most of these reports show a backtrace to the graphics driver (some .so files)
And the reports are shows seperately (although they might have the same code=x) because of different graphics driver files I suppose

I also found this crashlog for 4 different devices which I found really weird:

Code: [Select]

java.lang.ExceptionInInitializerError:
  at com.threed.jpct.Object3DCompiler.compile (Object3DCompiler.java:150)
  at com.threed.jpct.World.compile (World.java:2109)
  at com.threed.jpct.World.renderScene (World.java:1067)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify$1.run (ArtOfEarthify.java:991)
  at com.aeroshark333.artofearthify.utils.WorkerThread$2.run (WorkerThread.java:46)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify.onDrawFrame (ArtOfEarthify.java:1753)
  at com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame (LiveWallpaperRenderer.java:45)
  at android.opengl.GLSurfaceView$GLThread.guardedRun (GLSurfaceView.java:1548)
  at android.opengl.GLSurfaceView$GLThread.run (GLSurfaceView.java:1259)
Caused by: java.lang.NegativeArraySizeException:
  at com.threed.jpct.CompiledInstance.<clinit> (CompiledInstance.java:28)

Title: Re: Crash (native)
Post by: EgonOlsen on October 18, 2018, 09:27:48 am

I actually meant what the crash rate is. Because, if 99.5% of all runs are fine, then I would guess that it's a driver problem of some kind but if only 50% run fine, it might be a more serious issue.

The array crash is actually impossible. This is the code:

Code: [Select]

protected final static int BUFFER_SIZE = Config.vertexBufferSize;
protected final static int[] smallBufferOne = new int[BUFFER_SIZE];

Unless you've set Config.vertexBufferSize to a negative value, there's no way that this can happen other than a VM bug. I would ignore it for now. Android does really strange things sometimes, the VM definitely isn't bug free.

Title: Re: Crash (native)
Post by: AeroShark333 on October 18, 2018, 11:57:11 am

In the past 60 days there have been about 720 installs, where 24 of these devices would give a crash. (3.3%) It's not guaranteed that all devices do report their crashes so it's probably higher than 3.3%
But these crashes also happen on newer Android versions

I used to own a device which would get SIGSEGV's but the device broke...
I now own a device it never crashes on. (I can only reproduce the SIGSEGV on an emulator, but not all emulators crash just one of the many I have)

So there's a 3.3% chance your device could get SIGSEGV's
And then about 50% of the runs will crash with a SIGSEGV (because these crashes don't always happen) on these devices

Title: Re: Crash (native)
Post by: EgonOlsen on October 19, 2018, 08:57:59 am

I'll go through my more obscure test devices this weekend and try to reproduce it.

Title: Re: Crash (native)
Post by: EgonOlsen on October 19, 2018, 10:21:51 pm

Nope, I'm not able to reproduce it. It runs just fine on everything that I've tried it on...

Title: Re: Crash (native)
Post by: AeroShark333 on October 24, 2018, 03:57:35 pm

Hmmm, this is the AVD emulator I use to reproduce the error (I think I also had a Genymotion emulator that'd crash if you want that one...):
https://drive.google.com/open?id=1-iNRd9xdTU7j-WCzYIWcOqfgIxt4eRe6
Unzip these files to C:\Users\<your_username>\.android\avd
(Also edit the .ini file to make it match your path (probably only change the username twice)
And it should pop up now when you try to run the application from Android Studio I believe

Title: Re: Crash (native)
Post by: EgonOlsen on October 25, 2018, 08:35:09 am

Is that one different from the one included in the SDK?

Title: Re: Crash (native)
Post by: AeroShark333 on October 25, 2018, 10:57:35 am

Hmmm, it's a Nexus 5X with API-28 (x86)
(I think I installed it from the SDK but yeah)
I've had this one for a while now so probably a newer one might be a bit different

Title: Re: Crash (native)
Post by: EgonOlsen on October 25, 2018, 02:31:24 pm

I can't really use the emulator, because for me, it crashes like mad anyway no matter what I'm trying to do with it. That's not the app inside of the emulator, but the whole emulator instance.

Title: Re: Crash (native)
Post by: AeroShark333 on October 25, 2018, 05:15:16 pm

When you change Config.useVBO = true to false in the testcase's code
Would that help to reproduce the error on a physical device perhaps?

Title: Re: Crash (native)
Post by: AeroShark333 on May 31, 2019, 08:41:45 pm

  at com.threed.jpct.Logger.log (Logger.java:206)
  at com.threed.jpct.GL20.checkError (GL20.java:163)
  at com.threed.jpct.GL20.glGenBuffers (GL20.java:1385)
  at com.threed.jpct.CompiledInstance.compileToVBO (CompiledInstance.java:1478)
  at com.threed.jpct.CompiledInstance.render (CompiledInstance.java:606)
  at com.threed.jpct.GLRenderer.drawWireframe (GLRenderer.java:2548)
  at com.threed.jpct.World.draw (World.java:1424)
  at com.threed.jpct.World.drawWireframe (World.java:1132)

Any idea what'd cause this error?

EDIT:
Also... I found this: https://stackoverflow.com/questions/47754714/load-huge-texture-in-parts-in-opengl-es-2-0
Maybe it would be a cool feature for jPCT

Title: Re: Crash (native)
Post by: EgonOlsen on June 03, 2019, 10:12:05 am

Is that the complete stack trace? I'm somehow missing the top part...

Title: Re: Crash (native)
Post by: AeroShark333 on June 04, 2019, 03:49:52 pm

No, this is the complete stacktrace

Title: Re: Crash (native)
Post by: EgonOlsen on June 05, 2019, 01:02:09 pm

Strange. Actually, there has to be some output what the actual GL error is. It might not be part of the actual exception though. If it helps to know this, is another question...

Title: Re: Crash (native)
Post by: AeroShark333 on June 07, 2019, 05:45:34 pm

This looks like a similar stacktrace from another user:

java.lang.RuntimeException:
  at com.threed.jpct.Logger.log (Logger.java:206)
  at com.threed.jpct.GL20.checkError (GL20.java:163)
  at com.threed.jpct.GL20.glGenBuffers (GL20.java:1385)
  at com.threed.jpct.CompiledInstance.compileToVBO (CompiledInstance.java:1478)
  at com.threed.jpct.CompiledInstance.render (CompiledInstance.java:606)
  at com.threed.jpct.GLRenderer.drawWireframe (GLRenderer.java:2548)
  at com.threed.jpct.World.draw (World.java:1424)
  at com.threed.jpct.World.drawWireframe (World.java:1132)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify$1.run (ArtOfEarthify.java:732)
  at com.aeroshark333.artofearthify.utils.WorkerThread$2.run (WorkerThread.java:46)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify.onDrawFrame (ArtOfEarthify.java:1402)
  at com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame (LiveWallpaperRenderer.java:45)
  at android.opengl.GLSurfaceView$GLThread.guardedRun (GLSurfaceView.java:1531)
  at android.opengl.GLSurfaceView$GLThread.run (GLSurfaceView.java:1248)

Title: Re: Crash (native)
Post by: EgonOlsen on June 13, 2019, 12:53:23 pm

I guess you don't have access to the log messages that are printed before this exception?

Title: Re: Crash (native)
Post by: AeroShark333 on June 13, 2019, 07:48:09 pm

I don't...

Title: Re: Crash (native)
Post by: AeroShark333 on January 27, 2020, 11:53:47 pm

I now have this stacktrace, maybe it's possible to find something interesting

Code: [Select]

backtrace:
  #00  pc 00000000000150a0  /vendor/lib64/libsrv_um.so
  #01  pc 0000000000027190  /vendor/lib64/egl/libGLESv2_mtk.so
  #02  pc 000000000002ac68  /vendor/lib64/egl/libGLESv2_mtk.so
  #03  pc 0000000000025dbc  /vendor/lib64/egl/libGLESv2_mtk.so
  #04  pc 0000000000025878  /vendor/lib64/egl/libGLESv2_mtk.so (glDrawElements+140)
  #05  pc 00000000000da720  /system/lib64/libandroid_runtime.so (android_glDrawElements__IIILjava_nio_Buffer_2(_JNIEnv*, _jobject*, int, int, int, _jobject*)+304)
  #06  pc 00000000003bc8e4  /system/framework/arm64/boot-framework.oat (offset 0x3b3000) (android.graphics.Color.nativeRGBToHSV [DEDUPED]+196)
  #07  pc 0000000000562a4c  /system/lib64/libart.so (art_quick_invoke_static_stub+604)
  #08  pc 00000000000d0360  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
  #09  pc 0000000000284b38  /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
  #10  pc 000000000027eaf4  /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+948)
  #11  pc 0000000000533624  /system/lib64/libart.so (MterpInvokeStatic+204)
  #12  pc 0000000000554f94  /system/lib64/libart.so (ExecuteMterpImpl+14612)
  #13  pc 00000000001fa708  /data/app/com.aeroshark333.artofearthify-y8JycfhWqFOb07jVYzYokA==/oat/arm64/base.vdex (com.threed.jpct.GL20.glDrawElements)
  #14  pc 00000000002585f0  /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.1077557954)+496)
  #15  pc 000000000025e170  /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
  #16  pc 000000000027ead8  /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+920)
  #17  pc 0000000000533098  /system/lib64/libart.so (MterpInvokeInterface+1392)
  #18  pc 0000000000555014  /system/lib64/libart.so (ExecuteMterpImpl+14740)
  #19  pc 00000000001f6c92  /data/app/com.aeroshark333.artofearthify-y8JycfhWqFOb07jVYzYokA==/oat/arm64/base.vdex (com.threed.jpct.CompiledInstance.render+4206)
  #20  pc 00000000002585f0  /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.1077557954)+496)
  #21  pc 000000000025e170  /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
  #22  pc 000000000027fbe4  /system/lib64/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+724)
  #23  pc 000000000053548c  /system/lib64/libart.so (MterpInvokeVirtualQuickRange+420)
  #24  pc 0000000000558c14  /system/lib64/libart.so (ExecuteMterpImpl+30100)
  #25  pc 00000000001fef10  /data/app/com.aeroshark333.artofearthify-y8JycfhWqFOb07jVYzYokA==/oat/arm64/base.vdex (com.threed.jpct.GLRenderer.drawVertexArray+492)
  #26  pc 00000000002585f0  /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.1077557954)+496)
  #27  pc 000000000025e170  /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
  #28  pc 000000000027fbe4  /system/lib64/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+724)
  #29  pc 000000000053548c  /system/lib64/libart.so (MterpInvokeVirtualQuickRange+420)
  #30  pc 0000000000558c14  /system/lib64/libart.so (ExecuteMterpImpl+30100)
  #31  pc 0000000000221be6  /data/app/com.aeroshark333.artofearthify-y8JycfhWqFOb07jVYzYokA==/oat/arm64/base.vdex (com.threed.jpct.World.draw+234)
  #32  pc 00000000002585f0  /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.1077557954)+496)
  #33  pc 000000000025e170  /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
  #34  pc 000000000027fbe4  /system/lib64/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+724)
  #35  pc 0000000000534c94  /system/lib64/libart.so (MterpInvokeDirectRange+244)
  #36  pc 0000000000555214  /system/lib64/libart.so (ExecuteMterpImpl+15252)
  #37  pc 0000000000221ae4  /data/app/com.aeroshark333.artofearthify-y8JycfhWqFOb07jVYzYokA==/oat/arm64/base.vdex (com.threed.jpct.World.draw+12)
  #38  pc 00000000002585f0  /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.1077557954)+496)
  #39  pc 000000000025e170  /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
  #40  pc 000000000027ead8  /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+920)
  #41  pc 0000000000535170  /system/lib64/libart.so (MterpInvokeVirtualQuick+584)
  #42  pc 0000000000558b94  /system/lib64/libart.so (ExecuteMterpImpl+29972)
  #43  pc 0000000000195c2e  /data/app/com.aeroshark333.artofearthify-y8JycfhWqFOb07jVYzYokA==/oat/arm64/base.vdex (com.aeroshark333.artofearthify.lw.ArtOfEarthify.onDrawFrame+1902)
  #44  pc 00000000002585f0  /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.1077557954)+496)
  #45  pc 000000000025e170  /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
  #46  pc 000000000027ead8  /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+920)
  #47  pc 0000000000535170  /system/lib64/libart.so (MterpInvokeVirtualQuick+584)
  #48  pc 0000000000558b94  /system/lib64/libart.so (ExecuteMterpImpl+29972)
  #49  pc 0000000000197ad4  /data/app/com.aeroshark333.artofearthify-y8JycfhWqFOb07jVYzYokA==/oat/arm64/base.vdex (com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame+4)
  #50  pc 00000000002585f0  /system/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool) (.llvm.1077557954)+496)
  #51  pc 0000000000521b38  /system/lib64/libart.so (artQuickToInterpreterBridge+1032)
  #52  pc 000000000056b8fc  /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
  #53  pc 0000000000a8ea70  /system/framework/arm64/boot-framework.oat (offset 0x3b3000) (android.opengl.GLSurfaceView$GLThread.guardedRun+4000)
  #54  pc 0000000000a8fb30  /system/framework/arm64/boot-framework.oat (offset 0x3b3000) (android.opengl.GLSurfaceView$GLThread.run+224)
  #55  pc 0000000000562788  /system/lib64/libart.so (art_quick_invoke_stub+584)
  #56  pc 00000000000d0340  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
  #57  pc 0000000000466148  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
  #58  pc 0000000000467210  /system/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue*)+424)
  #59  pc 00000000004942a0  /system/lib64/libart.so (art::Thread::CreateCallback(void*)+1120)
  #60  pc 0000000000084bd4  /system/lib64/libc.so (__pthread_start(void*)+36)
  #61  pc 000000000002344c  /system/lib64/libc.so (__start_thread+68)
Lines 13,19,25,31,37,43,49 are most interesting perhaps

Title: Re: Crash (native)
Post by: EgonOlsen on January 28, 2020, 10:15:42 am

That's the one (or at least very similar) that I'm seeing for my own apps every now and then. But it doesn't really help. All the engine is doing, is to tell the GL driver to draw some geometry. Why this causes a crash deep inside of the GL pipeline under some circumstances is beyond me. Another problem is, that you can't be sure when this happen because there's no context. You don't know if this happens during normal operation (I've never ever experienced this on one of my own devices) or if it happens when the context is shutting down anyway (or doing some other wierd thing).

Title: Re: Crash (native)
Post by: AeroShark333 on March 10, 2020, 03:04:25 am

I actually do have an emulator on my PC where I can reproduce this SIGSEGV error.
However, I'm not sure if the emulator crash truly is identical to the crashes that users receive.

In Android Studio, I've been using the debug option to test some things out.
I'd let the application stop once it hits  the following line :

Code: [Select]

gl11.glDrawElements(this.primitiveType, this.indexCount, 5123, 0);
It's not running the above line yet until I tell it to continue, the app basically hangs/suspends in meantime.
While the app is suspended, I can run an evaluation (custom code) that I can insert through the debugger as follows:

Code: [Select]

for(int xxx=3;xxx<this.indexCount;xxx+=3){
System.out.println("Indexcount=" + xxx);
gl11.glDrawElements(this.primitiveType, xxx, 5123, 0);
}
Now there are three different scenario's:
- The application crashes when a certain index count (xxx) has been reached. (lower limit)
- The application crashes for another index count (xxx+6). (higher limit)
- The application doesn't crash at all (because it does still happen randomly...)

So for an Object3D, there's always two values as index count where it could crash: xxx and xxx+6.

The only thing that changes this xxx value (and xxx+6 value) is:
- the vertex count of the object
- the overall structure of the object.

I have only tested this with UV-spheres and ico-spheres.

As a conclusion, I have found that if it was possible to lower these 'index counts', so that high values are not reached, the crash won't happen.
The only way to achieve that is to lower the Config.glBatchSize value.
And yes, with the emulator this does help to reduce the occurences of this SIGSEGV crash to 0.
I'm not sure if this will fix the issue for real devices but it's worth a shot I guess.

I have two questions remaining, however:
- Why is the default Config.glBatchSize = 8000?
- If an Object3D for instance has 48000 vertices and the Config.glBatchSize = 8000. The Object3D loads it in batches of 23997, 24000 and 3 vertices. Why is the first batch 3 vertices smaller than the batch size would suggest?

Title: Re: Crash (native)
Post by: EgonOlsen on March 10, 2020, 02:52:22 pm

The 8000 is just a magic number. I had some trouble with higher values on the desktop using older nVidia drivers, so I tried to find a compromise between these problems and a reasonable high value. It then transfered over to the Android version. It might indeed help to lower it for some unknown reason.

About the strange batch sizes...I don't know ATM. I'll have a look at this.

Title: Re: Crash (native)
Post by: EgonOlsen on March 10, 2020, 09:26:07 pm

A had a look at the batch size issue. It's a problem with the way in which batch sizes are calculated. It's only really obvious if the vertex count is a multiple of the batch size. I've fixed it, but I don't think that it requires a new version just for that. It looks strange in the log output, but it's not an actual problem.

Title: Re: Crash (native)
Post by: AeroShark333 on March 11, 2020, 12:53:21 am

Alright, thank you. I figured it'd not make a big difference but I mostly wondered if this was intentional so I guess not.

About the ideal batch size, I have found Config.glBatchSize=3000 to be pretty ideal in my use cases when the vertex count for the Object3D is smaller than about 100000. The Config.glBatchSize needs to be further decreased when your Object3D has higher vertexcount. But this different per Object3D structure again...

In my use case the distance between vertices does become smaller for higher vertexcount... I don't know if that could be a problem that the vertices become more dense. I have noticed a stronger drop for the needed glBatchSize for higher polygoncount UV-spheres than for higher polygoncount ico-spheres.

Title: Re: Crash (native)
Post by: EgonOlsen on March 11, 2020, 08:41:26 am

Honestly, I've no idea about how and why the vertex count can cause an issue. As mentioned, I had some similar experience on the desktop and I debugged the hell out of it, thinking that my counts were somehow wrong and that I was rendering some out of bounds geometry. But that's not the case, so I really don't know what the issue is here...

Title: Re: Crash (native)
Post by: AeroShark333 on September 19, 2020, 04:52:58 am

Offtopic but any clue what could cause this crash?

Code: [Select]

java.lang.RuntimeException:
  at com.threed.jpct.Object3D.render (Object3D.java:6595)
  at com.threed.jpct.World.renderScene (World.java:1079)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify.onDrawFrame (ArtOfEarthify.java:2331)
  at com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame (LiveWallpaperRenderer.java:73)
  at android.opengl.GLSurfaceView$GLThread.guardedRun (GLSurfaceView.java:1571)
  at android.opengl.GLSurfaceView$GLThread.run (GLSurfaceView.java:1270)
  at com.threed.jpct.Logger.log
  at com.threed.jpct.Logger.log (Logger.java:150)
  at com.threed.jpct.World.renderScene (World.java:1095)
  at com.aeroshark333.artofearthify.lw.ArtOfEarthify.onDrawFrame (ArtOfEarthify.java:2331)
  at com.aeroshark333.artofearthify.lw.LiveWallpaperRenderer.onDrawFrame (LiveWallpaperRenderer.java:73)
  at android.opengl.GLSurfaceView$GLThread.guardedRun (GLSurfaceView.java:1571)
  at android.opengl.GLSurfaceView$GLThread.run (GLSurfaceView.java:1270)
Device: Samsung Galaxy S8, 3GB RAM, Android 9 (not my device)

Title: Re: Crash (native)
Post by: EgonOlsen on September 21, 2020, 09:48:07 am

Judging from the line in World, which causes the actual problem (1095), there should also be this output somewhere in the log:

Quote

There's a problem with the object list not being consistent during rendering. This is often caused by concurrent modification of jPCT objects on a thread different from the rendering thread!

Are you any chance modifying the world's collection of objects in some other thread like when a touch event happens?

Title: Re: Crash (native)
Post by: AeroShark333 on September 21, 2020, 02:30:57 pm

Quote from: EgonOlsen on September 21, 2020, 09:48:07 am

Judging from the line in World, which causes the actual problem (1095), there should also be this output somewhere in the log:

Quote

There's a problem with the object list not being consistent during rendering. This is often caused by concurrent modification of jPCT objects on a thread different from the rendering thread!

Are you any chance modifying the world's collection of objects in some other thread like when a touch event happens?

I think that line is only printed with a NullPointerException but I'm not sure about this RuntimeException...

I'm not modifying the world's collection of objects at that point any more... So I am confused...

I don't have access to any other logs however... So I'm puzzled...
I wonder what the Object3D.java:6595 line is all about though

Title: Re: Crash (native)
Post by: EgonOlsen on September 21, 2020, 02:47:00 pm

That puzzles me as well. This stacktrace doesn't make much sense as a whole. It somehow looks like as if two stacktraces have been mixed together, because you just can't go from GLSurfaceView$GLThread.run()...to Logger.log()...back to GLSurfaceView$GLThread.run(). Something is messed up here. 6595 in Object3D depends on the version you are using. If it's most recent beta from some weeks ago, then it happens while accessing the lights that this object is being influenced by for this frame. That's a temp list used during rendering. It can't change at this stage unless the object is fiddled around with in another thread.

But only the part until the Logger.log looks reasonable and that points to a nullpointer while processing the world's objects, which can actually only be caused by some other thread fiddling around with either this list or an object itself which would explain the problem in line 6595 as well.

Title: Re: Crash (native)
Post by: AeroShark333 on September 21, 2020, 03:04:28 pm

I'm using the latest beta (which has 8 texturelayers support)
I'm only using a single light source at [0,0,0], which doesn't ever change actually...

I don't think I'm changing any lighting in any other thread actually...
I believe the only thing that could be altered from other threads that might consider the Object3D is: camera position/orientation and shader variables (uniforms).

Title: Re: Crash (native)
Post by: EgonOlsen on September 21, 2020, 03:22:01 pm

Quote from: AeroShark333 on September 21, 2020, 03:04:28 pm

I'm using the latest beta (which has 8 texturelayers support)

In that case, it's this line:

Code: [Select]

int id = (int) ((float[]) ls.get(i))[1];

i is the index into the lights list (ls). It ranges from 0 to the list's length (exclusive). 1 is an index into the float[] array that has been stored in this list. It can never be null, because it's created a startup (just as ls). However, both, the list and the array, are static instances in Object3D (yes, that's ugly but I had to do it that way to avoid object creation and garbage collection especially on older versions of Android). That means that any other thread calling render on any other Object3D will mangle this list. This has to be what happens here, I don't see any other way. Maybe it happens when the GL context/rendering thread changes because the device wakes up from sleep or something like that? So that the old thread hasn't been terminated while the new one already exists? I've no idea, I'm just guessing here...

Title: Re: Crash (native)
Post by: AeroShark333 on September 21, 2020, 03:40:21 pm

I'm guessing then it's either context change, resuming of renderer or pausing of renderer...
I don't think it could be anything else..?

I believe I did have some issues with NullPointerExceptions before when resuming/pausing/changing context. I did catch it before and if I remember correctly the problem would fix itself..? So the NPE's would disappear shortly after such events if I remember correctly. But I removed catching the error/exception in this version because it also caught shader crashes which I didn't want to catch.

Is it possible to 'test' a written shader beforehand (when loading)? That it compiles well and could work well? I think I tried FrameBuffer.compileShader before but it doesn't throw a crash or error..?
Only when the Object3D, which is using the GLSLShader, is visible it'd crash.

I guess I could ignore it for now as it's only one occurrence...
But yeah, just letting you know

Title: Re: Crash (native)
Post by: EgonOlsen on September 21, 2020, 03:45:11 pm

FrameBuffer.compileShader() compiles the shader. It just doesn't really execute it (how should it...). So you can test, if it compiles that way, but not if it really works.

Title: Re: Crash (native)
Post by: AeroShark333 on September 21, 2020, 07:51:01 pm

Hmmm, okay...

I think I'll fix it with:

Code: [Select]

frameBuffer.compileShader(shader, null);
                    frameBuffer.setBlittingShader(shader);
                    frameBuffer.blit(brightness, 0, 0, 0, 0, 2, 2, false);
                    frameBuffer.setBlittingShader(null);to test every shader. This does seem to trigger errors/crashes and works for Object3D shaders too.

That way I can still catch the RuntimeException from World.renderScene/World.draw whenever it happens and not needing to blame it on faulty shaders because those can be checked beforehand now.
I'm still guessing the exception is thrown due to context pause/resume/change but I'm not entirely sure.

Title: Re: Crash (native)
Post by: EgonOlsen on September 23, 2020, 08:42:45 am

Quote from: AeroShark333 on September 21, 2020, 07:51:01 pm

I'm still guessing the exception is thrown due to context pause/resume/change but I'm not entirely sure.

Neither am I, but I don't see what else it could be ATM. I've seen similar things happening with my stuff. Quite a lot of crashes reported by Google Play seem to happen at these stages rather than during normal operation.