SEGV_MAPERR on _memory_heap_thread_cache_extract about tracy

[wolfpld]

Is there a reason why you're enabling TRACY_DELAYED_INIT?

[babelchips]

It was just an attempt to resolve this issue.

[wolfpld]

This is likely caused by rpmalloc not being initialized. The crash trace points out to a call to tracy_malloc in Profiler constructor (i.e. m_buffer( (char*)tracy_malloc( TargetFrameSize*3 ) )).

In case of TRACY_DELAYED_INIT being enabled, rpmalloc initialization should be performed during construction of struct ProfilerData, by RPMallocInit rpmalloc_init field being before Profiler profiler.

In the other case, rpmalloc initialization is done by specifying initialization order, placing static RPMallocInit init_order(102) s_rpmalloc_init before static Profiler init_order(105) s_profiler. init_order is an alias for __attribute__ ((init_priority(val))).

I can't repro this on my side.

[babelchips]

Thanks. So if I get the fault with TRACY_DELAYED_INIT in either state and this is part of init_order even manually calling init rpmalloc somewhere early won't help.

Can I assume the issue I am seeing is due to either the use of threads or shared objects?

[wolfpld]

It may be related to usage of multiple shared objects.

You may workaround this by using malloc/free in common/TracyAlloc.hpp.

[babelchips]

Hmmm .... with standard malloc and free it changes things, different point of failure but no further along. I think i'm going to have to workaround this by profiling my code standalone (on ARM) without the extra Android .apk and shared objects baggage.

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
lib/arm64/libandroid_native_app_glue.so (_ZTHN5tracy22s_rpmalloc_thread_initE+20)
lib/arm64/libandroid_native_app_glue.so (_ZTWN5tracy7s_tokenE+8)
lib/arm64/libandroid_native_app_glue.so (_ZN5tracy8GetTokenEv+8)
lib/arm64/libandroid_native_app_glue.so (_ZN5tracy8Profiler14CalibrateDelayEv+240)
lib/arm64/libandroid_native_app_glue.so (_ZN5tracy8ProfilerC1Ev+340)
lib/arm64/libandroid_native_app_glue.so (__cxx_global_var_init.8+24)
lib/arm64/libandroid_native_app_glue.so (_GLOBAL__I_000105+8)
/system/bin/linker64 (__dl__ZN6soinfo10call_arrayEPKcPPFvvEmb+348)
/system/bin/linker64 (__dl__Z9do_dlopenPKciPK17android_dlextinfoPv+2112)
/system/bin/linker64 (__dl_android_dlopen_ext+60)
/system/lib64/libnativeloader.so (_ZN7android17OpenNativeLibraryEP7_JNIEnviPKcP8_jobjectP8_jstring+244)
/system/lib64/libart.so (_ZN3art9JavaVMExt17LoadNativeLibraryEP7_JNIEnvRKNSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEEP8_jobjectP8_jstringPS9_+1016)
/system/lib64/libopenjdkjvm.so (JVM_NativeLoad+284)
/system/framework/arm64/boot.oat (offset 0x54e000) (java.lang.Runtime.nativeLoad+204)
/system/framework/arm64/boot.oat (offset 0x54e000) (java.lang.Runtime.doLoad+204)
/system/framework/arm64/boot.oat (offset 0x54e000) (java.lang.Runtime.loadLibrary0+748)
/system/framework/arm64/boot.oat (offset 0x54e000) (java.lang.System.loadLibrary+96)
/system/lib64/libart.so (art_quick_invoke_static_stub+600)
/system/lib64/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+256)
/system/lib64/libart.so (_ZN3art11interpreter34ArtInterpreterToCompiledCodeBridgeEPNS_6ThreadEPNS_9ArtMethodEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+312)
/system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+528)
/system/lib64/libart.so (MterpInvokeStatic+356)
/system/lib64/libart.so (ExecuteMterpImpl+14612)

Note i've shown the deeper stack trace this time starting with the Android Runtime libart.so. I guess Tracy needs to be initialised much earlier on in this sequence?

[wolfpld]

I guess Tracy needs to be initialised much earlier on in this sequence?

It should be fine as it is.

I guess you can try debugging it by setting a breakpoint in RPMallocInit() and InitOnceCallback(). Everything points to some problems there.

[nagisa]

Calling ___tracy_init_thread before any calls to tracy APIs could help to narrow down the issue to initialization problems.

[babelchips]

Unfortunately it looks like the issue is occurring during global init - before any of my calls to Tracy, so there’s not room to add that call first.

[wolfpld]

All rpmalloc issues should be fixed by b0fc0d5.

[o-oconnell]

@babelchips Have you found a good method of getting the Java frames in the trace? At a glance your stack trace looks like java code. Thanks!