Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android library failing to build #1010

Closed
ThreeDeeJay opened this issue Jun 27, 2024 · 6 comments
Closed

Android library failing to build #1010

ThreeDeeJay opened this issue Jun 27, 2024 · 6 comments

Comments

@ThreeDeeJay
Copy link
Contributor

ThreeDeeJay commented Jun 27, 2024

Some extra context: #824
I put together a GitHub actions workflow to build the Android library (libopenal.so) and noticed that a commit is causing some compilation errors. After some trial and error, I managed to track down the culprit, from June 1st:

@ThreeDeeJay
Copy link
Contributor Author

On a side note, I'm not sure if it's related, but the the one that did build crashes sView with this error when enabling HRTF in the settings, unlike Centurion96's build which works, though I think it lacks embedded HRTF which might be a clue. 🤔

Here's the log starting right before enabling HRTF:


D com.sview: PlayerBase::stop() from IPlayer
D AudioTrack: stop(186): called with 477126 frames delivered
D openal: [ALSOFT] (II) ALC_OUTPUT_MODE_SOFT = 6578
D openal: [ALSOFT] (II) ALC_HRTF_SOFT = 2
D openal: [ALSOFT] (II) Pre-reset: *Stereo, Float32, 48000hz, 960 / 2880 buffer
D com.sview: PlayerBase::PlayerBase()
D com.sview: TrackPlayerBase::TrackPlayerBase()
I libOpenSLES: Emulating old channel mask behavior (ignoring positional mask 0x3, using default mask 0x3 based on channel count of 2)
D openal: [ALSOFT] (II) Post-reset: Stereo, Int16, 48000hz, 960 / 2880 buffer
D openal: [ALSOFT] (II) Searching / for *.mhr
E openal: [ALSOFT] (EE) Exception enumerating files: filesystem error: in directory_iterator::directory_iterator(...): Permission denied ["/"]
D openal: [ALSOFT] (II) Adding built-in entry "!1_Built-In HRTF"
D openal: [ALSOFT] (II) Loading !1_Built-In HRTF...
D openal: [ALSOFT] (II) Detected data set format v3
W StAudioQueue: type=1400 audit(0.0:9583): avc:  denied  { read } for  name="/" dev="dm-1" ino=2 scontext=u:r:untrusted_app_29:s0:c98,c257,c512,c768 tcontext=u:object_r:rootfs:s0 tclass=dir permissive=0 ppid=1624 pcomm="main" pgid=25685 pgcomm="com.sview" app=com.sview
D openal: [ALSOFT] (II) Loaded HRTF Built-In HRTF for sample rate 48000hz, 64-sample filter
D openal: [ALSOFT] (II) 1st order + Full HRTF rendering enabled, using "Built-In HRTF"
D openal: [ALSOFT] (II) Channel config, Main: 4, Real: 2
D openal: [ALSOFT] (II) Allocating 6 channels, 24576 bytes
D openal: [ALSOFT] (II) Min delay: 7.75, max delay: 32.50, FIR length: 64
D openal: [ALSOFT] (II) New max delay: 24.75, FIR length: 89
D openal: [ALSOFT] (II) Max sources: 256 (255 + 1), effect slots: 64, sends: 2
D openal: [ALSOFT] (II) Dithering enabled (16-bit, 32768)
D openal: [ALSOFT] (II) Output limiter enabled, -0.0005dB limit
D openal: [ALSOFT] (II) Fixed device latency: 1000000ns
D openal: [ALSOFT] (II) Post-start: Stereo, Int16, 48000hz, 960 / 2880 buffer
W openal: [ALSOFT] (WW) pthread_setschedparam failed: Operation not permitted (1)
W openal: [ALSOFT] (WW) D-Bus not available
F libc: Fatal signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0xe4581a38 in tid 25793 (alsoft-mixer), pid 25685 (com.sview)
I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstoneProto
I crash_dump32: performing dump of process 25685 (target tid = 25793)
W System: A resource failed to call AbstractCursor.close.
W System: A resource failed to call CursorWrapperInner.close.
W System: A resource failed to call AbstractCursor.close.
W System: A resource failed to call CursorWrapperInner.close.
W crash_dump32: type=1400 audit(0.0:9584): avc:  denied  { read } for  name="/" dev="dm-1" ino=2 scontext=u:r:crash_dump:s0:c98,c257,c512,c768 tcontext=u:object_r:rootfs:s0 tclass=dir permissive=0 ppid=1 pcomm="init" pgid=1 pgcomm="init" app=com.sview
W crash_dump32: type=1400 audit(0.0:9585): avc:  denied  { read } for  name="/" dev="dm-1" ino=2 scontext=u:r:crash_dump:s0:c98,c257,c512,c768 tcontext=u:object_r:rootfs:s0 tclass=dir permissive=0 ppid=1 pcomm="init" pgid=1 pgcomm="init" app=com.sview
W crash_dump32: type=1400 audit(0.0:9586): avc:  denied  { read } for  name="/" dev="dm-1" ino=2 scontext=u:r:crash_dump:s0:c98,c257,c512,c768 tcontext=u:object_r:rootfs:s0 tclass=dir permissive=0 ppid=1 pcomm="init" pgid=1 pgcomm="init" app=com.sview
W crash_dump32: type=1400 audit(0.0:9587): avc:  denied  { read } for  name="/" dev="dm-1" ino=2 scontext=u:r:crash_dump:s0:c98,c257,c512,c768 tcontext=u:object_r:rootfs:s0 tclass=dir permissive=0 ppid=1 pcomm="init" pgid=1 pgcomm="init" app=com.sview
F DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG: backtrace:
F DEBUG: #00 pc 000d0b38  /data/app/~~KvOx4ElXIr_v-_FM4vcxzA==/com.sview-Us29JoLSfw4y9PYkPDCKbA==/lib/arm/libopenal.so (void MixDirectHrtf_<NEONTag>(al::span<float, 1024u>, al::span<float, 1024u>, al::span<std::__ndk1::array<float, 1024u> const, 4294967295u>, al::span<std::__ndk1::array<float, 2u>, 4294967295u>, al::span<float, 1024u>, al::span<HrtfChannelState, 4294967295u>, unsigned int, unsigned int)+96) (BuildId: 5929b6a6691adfe4f6e8e384245da208e26cefc1)
F DEBUG: #01 pc 00097951  /data/app/~~KvOx4ElXIr_v-_FM4vcxzA==/com.sview-Us29JoLSfw4y9PYkPDCKbA==/lib/arm/libopenal.so (DeviceBase::ProcessHrtf(unsigned int)+128) (BuildId: 5929b6a6691adfe4f6e8e384245da208e26cefc1)
F DEBUG: #02 pc 000993d3  /data/app/~~KvOx4ElXIr_v-_FM4vcxzA==/com.sview-Us29JoLSfw4y9PYkPDCKbA==/lib/arm/libopenal.so (DeviceBase::renderSamples(unsigned int)+6354) (BuildId: 5929b6a6691adfe4f6e8e384245da208e26cefc1)
F DEBUG: #03 pc 0009985d  /data/app/~~KvOx4ElXIr_v-_FM4vcxzA==/com.sview-Us29JoLSfw4y9PYkPDCKbA==/lib/arm/libopenal.so (DeviceBase::renderSamples(void*, unsigned int, unsigned int)+132) (BuildId: 5929b6a6691adfe4f6e8e384245da208e26cefc1)
F DEBUG: #04 pc 000b743f  /data/app/~~KvOx4ElXIr_v-_FM4vcxzA==/com.sview-Us29JoLSfw4y9PYkPDCKbA==/lib/arm/libopenal.so ((anonymous namespace)::OpenSLPlayback::mixerProc()+326) (BuildId: 5929b6a6691adfe4f6e8e384245da208e26cefc1)
F DEBUG: #05 pc 000b769b  /data/app/~~KvOx4ElXIr_v-_FM4vcxzA==/com.sview-Us29JoLSfw4y9PYkPDCKbA==/lib/arm/libopenal.so (void* std::__ndk1::__thread_proxy[abi:v170000]<std::__ndk1::tuple<std::__ndk1::unique_ptr<std::__ndk1::__thread_struct, std::__ndk1::default_delete<std::__ndk1::__thread_struct> >, std::__ndk1::__mem_fn<int ((anonymous namespace)::OpenSLPlayback::*)()>, (anonymous namespace)::OpenSLPlayback*> >(void*)+54) (BuildId: 5929b6a6691adfe4f6e8e384245da208e26cefc1)
F DEBUG: #06 pc 00044323  /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+40) (BuildId: 792a626fd6ec5a902e0f37973978b310)
F DEBUG: #07 pc 0003b42b  /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30) (BuildId: 792a626fd6ec5a902e0f37973978b310)

@kcat
Copy link
Owner

kcat commented Jun 28, 2024

Some extra context: #824 I put together a GitHub actions workflow to build the Android library (libopenal.so) and noticed that a commit is causing some compilation errors. After some trial and error, I managed to track down the culprit, from June 1st:

* [a0e238f](https://github.com/kcat/openal-soft/commit/a0e238f54dbf57a2c88f2b45a0c49f6a13e0784c) - Last commit to [successfully compile](https://github.com/ThreeDeeJay/openal-soft/actions/runs/9703301432/job/26781110464#step:2:7)

* [2719ce2](https://github.com/kcat/openal-soft/commit/2719ce2c0aaf40bdf2db1c3e579b3b76e9cbcf14) - Commit where compilation started [failing](https://github.com/ThreeDeeJay/openal-soft/actions/runs/9703265481/job/26780989241#step:5:107)

Odd. Seems to be failing because libopenal.version specifies functions to export/make global that were deprecated. They still exist and should be exportable, they're marked with __attribute__((visibility("protected"))) to be globally visible (and not internally overridable) as they should be, but for some reason the linker isn't seeing them. Perhaps the linker is discarding them since they're not referenced elsewhere, though they're not the only functions like that. I'll see what's different about them and try something.

On a side note, I'm not sure if it's related, but the the one that did build crashes sView with this error when enabling HRTF in the settings, unlike Centurion96's build which works, though I think it lacks embedded HRTF which might be a clue. 🤔

It's not related to the build failure, but it is related to HRTF. It seems to crash in MixDirectHrtf_<NEONTag> as a result of a bad address alignment, given the address 0xe4581a38. Unfortunately it doesn't say what that address belongs to, or the faulting instruction. AFAIK, NEON should be more robust with address alignment, and the given address is 8-byte aligned that loads and stores should be able to use. I'm not sure why it's crashing like that.

@ThreeDeeJay
Copy link
Contributor Author

ThreeDeeJay commented Jun 29, 2024

It's not related to the build failure, but it is related to HRTF. It seems to crash in MixDirectHrtf_<NEONTag> as a result of a bad address alignment, given the address 0xe4581a38. Unfortunately it doesn't say what that address belongs to, or the faulting instruction. AFAIK, NEON should be more robust with address alignment, and the given address is 8-byte aligned that loads and stores should be able to use. I'm not sure why it's crashing like that.

Interesting, setting ALSOFT_EMBED_HRTF_DATA=FALSE prevents the crash, which I guess explains why Centurion's build (which also lacked embedded HRTF) didn't crash either.

Here's a more verbose log, comparing a0e238f with and without ALSOFT_EMBED_HRTF_DATA where I just started sView and enabled HRTF: https://www.diffchecker.com/zpmHlWaC/

BTW in case it's relevant, I'm running the 32-bit version of sView on a 64-bit OS/device.

@kcat
Copy link
Owner

kcat commented Jun 29, 2024

Yes, disabling ALSOFT_EMBED_HRTF_DATA prevents the library from having a built-in HRTF dataset, which prevents HRTF from working if there's no external mhr files it can load load. The app resets the device setting ALC_OUTPUT_MODE_SOFT, ALC_STEREO_HRTF_SOFT to try to enable HRTF, which fails and it falls back to normal stereo. With ALSOFT_EMBED_HRTF_DATA on, it can enable HRTF processing using the built-in dataset, which eventually calls MixDirectHrtf_<NEONTag>, and then crashes for some reason.

@kcat
Copy link
Owner

kcat commented Aug 2, 2024

Is the HRTF crash fixed now with commit a56689d?

@ThreeDeeJay
Copy link
Contributor Author

Thanks, it's not crashing anymore! 👌
https://youtu.be/ssmLgkbRMh0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants