-
Notifications
You must be signed in to change notification settings - Fork 545
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Crashes in release mode (debug works fine) #43
Comments
I'm getting same error on Android. Release mode crashes at alBufferData() because of heap corruption, but RelWithDebugInfo and Debug work fine. http://stackoverflow.com/questions/38165186/openal-application-crashes-hangs-when-i-pass-non-nullptr-to-albufferdata-fro |
Does something like Valgrind exist for OSX or Android? That would help pinpoint memory corruption errors. alBufferData is working fine for both Linux and Windows, which uses the exact same code, and I'm not getting other reports of problems like this from other OSX or Android users, making me think it's something peculiar with your setups (not that there isn't anything I can do to fix/workaround the problem, but I do need to narrow down where the problem is to try to fix it). I've also tried both your programs with both GCC 4.9.2 and Clang 3.5.2, and they work fine. Since you both seem to be using Clang (IIRC, that's what Apple uses by default), maybe its address sanitizer can help pinpoint the problem. I've never used it myself before though, so I don't know exactly how it works.
It's RelWithDebInfo, not RelWithDebugInfo. The latter isn't a standard build type, so it would be the same as building without any optimizations or debug info. |
As far as I know, android ndk supports only two build types, DEBUG and RELEASE. I think the error is somewhere else, but am not sure about it. |
@sriharshachilakapati I'm cross-compiling OpenAL as a shared lib using cmake and toolchains from ndk. I'm talking about cmake build types, not ndk ones. @kcat Sorry, my mistake. RelWithDebInfo crashes too. I'm going to try to use valgrind or clang's address sanitizer and I'll inform you if I succeed. |
Getting the same problem -- OSX as well 10.10.5, llvm 7.0.2, cmake 3.4, 32-bit build. Did you guys ever figure this out? |
I failed to set up clang's asan, so I'm just using random string as a build type for now. For some reason empty string seemed to have a different effect. |
Having the same problem in Android release build as well as in RelWithDebInfo, compiler is clang. Streaming code works well on iOS (using Apple implementation of OpenAL) |
Found that LoadData in alBuffer.c calls realloc with newsize equal to 0, because NewBytes is 0 |
That shouldn't be a problem, since it'll either act like |
I ran my simple program with Valgrind and got the output below (I'm not sure what it means I have never used Valgrind before). This is the full stack I got: `==6832== Memcheck, a memory error detector valgrind: m_syswrap/syswrap-amd64-darwin.c:507 (void wqthread_hijack(Addr, Addr, Addr, Addr, Int, Addr)): Assertion 'tst->os_state.pthread - magic_delta == self' failed. host stacktrace: sched status: Thread 1: status = VgTs_WaitSys (lwpid 2567) Thread 2: status = VgTs_WaitSys (lwpid 4099) Thread 3: status = VgTs_WaitSys (lwpid 5635) Note: see also the FAQ in the source distribution. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind |
Also this is the clang I'm using: Apple LLVM version 7.3.0 (clang-703.0.31) |
That appears to be crashing deep within OSX while trying to find a device component to open. Though it looks like valgrind itself is crashing with |
Sometimes when running it, it takes a much longer time to complete and I get this (yes, it looks like the same output): ==7477== Memcheck, a memory error detector valgrind: m_syswrap/syswrap-amd64-darwin.c:507 (void wqthread_hijack(Addr, Addr, Addr, Addr, Int, Addr)): Assertion 'tst->os_state.pthread - magic_delta == self' failed. host stacktrace: sched status: Thread 1: status = VgTs_WaitSys (lwpid 2567) Thread 2: status = VgTs_WaitSys (lwpid 6147) Thread 3: status = VgTs_WaitSys (lwpid 5635) Thread 4: status = VgTs_WaitSys (lwpid 7171) Note: see also the FAQ in the source distribution. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind |
I found that there was a problem with valgrind 3.11.10 on OS X 10.11. I applied the patch from https://bugs.kde.org/show_bug.cgi?id=354883. I ran valgrind again and got this output: ==30285== Memcheck, a memory error detector Memcheck: mc_main.c:1730 (void set_address_range_perms(Addr, SizeT, UWord, UWord)): Assertion '! sr_isError(sres)' failed. host stacktrace: sched status: Thread 1: status = VgTs_WaitSys (lwpid 2567) Thread 2: status = VgTs_Runnable (lwpid 5891) Thread 3: status = VgTs_Yielding (lwpid 5635) Note: see also the FAQ in the source distribution. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind |
It would be interesting to see other people's (that's having the same crash) output using valgrind. |
Started seeing this in LWJGL after switching our CI to the latest Xcode version. I used Travis CI to test different versions, results:
On Xcode 7.3.1, I'm getting no crashes with Debug and MinSizeRel builds. Release and RelWithDebInfo builds crash. |
So the solution is to go back to Xcode 7.2.1? No other way to fix it? |
It seems using the MinSizeRel build type works around it too, according to what Spasi said. MinSizeRel isn't a bad build type to use, as it has optimizations and keeps the file size down (and sometimes optimizing for size can be about as good as full optimizations, because reducing the code footprint keeps down redundant code, which helps make it run faster). Otherwise, it's probably a problem with Clang's optimizer. I've finally been able to reproduce a Clang-related crash here on Linux, and it seems to be an optimization problem. If I simply trace certain local variables at specific points, it works, but if I don't trace those variables, it crashes. For example, if I do this in
and load a 16-bit mono sound, it prints out:
before crashing, which is obviously wrong (the 'type' size should be 2 for 16-bit samples). But if I simply uncomment that first line and rebuild, I get:
which is correct, and it no longer crashes. It seems removing |
Now everything works fine here with an Xcode 7.3.1 release build. Thanks! |
Seems to work fine, good job! I didn't get a crash, but I got this message when playing the sound:
What does it mean? |
That means your system doesn't have either |
Closing as fixed by commit a758cc8. |
I have created a small sample program in C++ trying to play sounds with OpenAL Soft. The program crashes when compiled in release mode, when compiled in debug mode it works. I'm on OS X using 1.17.2
I get this error message:
The source of the sample program can be found at:
http://stackoverflow.com/questions/37889119/openal-soft-crashes-in-release-mode-debug-works-fine
The text was updated successfully, but these errors were encountered: