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.so
On 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
To answer your last question: The textures and other native data is using that RAM.
Ah understood.

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

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.

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