[models] Crash when loading .vox model on Android with SIGSEGV error #3098
Comments
|
This issue seems related to an external library, created by a contributor so, technically the issue does not belong to this repo but the repo of the creator of the library. I'm afraid the maintenance and support of This is a common problem with that kind of contributions... who takes care of the related issues? |
|
It's problematic that the person who seems to be the originator of this code didn't make a repository for this work. It seems to only exist here. Nevertheless, I was able to isolate the issue, and it appears to stem from this If I remove the conditional part related to the color, there are no more crashes. That's the only notable thing I noticed, although it could be related to other factors. However, if we trust the logs I received, the error indeed seems to occur in I apologize for not being able to provide more precise information. It's quite complicated and very cumbersome for me to debug this code with my equipment, unfortunately. |
|
@Bigfoot71 No worries, I took a quick look to the code and it's quite clean and organized, also it's relatively small. Maybe @fxgenstudio can take a look to this issue? Also checked for updated specs but I couldn't find much info, only the v150 specs and the extension specs. |
|
I have sent an email hoping that it is received. Otherwise, considering the issue occurring only on Android without any apparent reason, I thought about disabling compiler optimizations, but the result remains the same. |
|
Hi, |
|
I have tested many different models obtained from the internet, including the ones I used in my reproducible example. They all work on Linux/Windows but crash on Android. However, they work on Android if I convert them to GLB or OBJ. I thought about memory as a possible issue, but according to the Android Studio profiler, there is no memory spike at the time of the crash. On the contrary, memory usage decreases just before the crash because I deallocate other things before loading the models. Moreover, I am far from the total limit of 256MB, there is only the stack occupation that I cannot see. I can only see its total size, which is 60KB (I mention this because the total of the stack never changes, which makes me think that it refers to the total allocated size). I also tested by adding Furthermore, the crash happens as soon as the first model is loaded, even if it is a small model (i.e., <20 voxels). |
|
You have an example for visual studio and android ? |
|
No, the example I provided will not work with Android Studio. You need to use the Makefile with the following command: However, you may need to modify the Makefiles a bit to make it work on your end. But I have quickly created an Android Studio project for you if you prefer. If you need any further information, please don't hesitate to ask! |
|
Thanks for your Android Studio project. I'll try with an other mobile. |
|
Strange, so it would strongly resemble a memory overflow problem, yet the profiler does not indicate anything at this level on my side. Maybe the information is relevant, my device architecture is |
|
@Bigfoot71 @fxgenstudio Did you try debugging the code to find the exact point where it crashes? Maybe it fails on memory allocation under some specific circunstances of maybe on file access. |
|
Sorry for not having shared all the logs on this subject here, I think we can rule out the file access problem, in my case the crash does occur in |
|
@Bigfoot71 Did you rebuild raylib for Android using the same compiler as your app? Did you generate a separate dynamic library for raylib and your app or is it a single library (raylib linked statically)? |
|
Yes, raylib has been recompiled dozens of times as well as the project and the minimal test, with the same version of clang each time (whether on Linux or Windows which do not have the same setup), the result is always the same. And raylib is statically linked. Regarding the fact of finding the exact point where it crashes in the library, it would be necessary to try by compiling raylib directly with the project to be able to have access to more information, I have already tried, it was not easy and the information obtained was not very revealing. I'll try tonight to rewrite the Android project's CMakeList file to do this, hope it makes it easier and can give more information when debugging. |
|
You could try my apk ? VoxTest.mp4 |
|
Sorry I can't, the APK is compiled for |
|
From Android studio it also works for my Redmi9 (M2004J19AG) |
|
And you haven't made any changes? I don't know what to say, I've tried dozens of times, I always come across the same error, even with the most minimal example possible. |
|
No changes, I use android studio 2022.2.1 with your project. |
|
Just like me for Android Studio, the Flamingo version. However, something really strange happened. While I was running all the tests one last time to get all the logs, I thought I could also record a video of the profiler and resource consumption. So, I clicked on "Profile 'app' with complete data," it recompiled the app, and it opened without crashing with the models for the first time! So, I tried again, still using "Profile 'app' with complete data," and it worked fine that way. I would like to remind you that the crash also happens in release mode with the minimalist Makefile that I provided in my example. What do you think could explain this? So far, I haven't been able to get better logs than this, despite the fact that raylib is compiled with all debug symbols, optimizations disabled, etc: |
|
this smells like stack corruption valgrind is your friend here... bare in mind that its not impossible it could be inducing a crash in a 3rd party (system) library, which you might not have the debug info for installed... |
|
So I first tried to compile raylib and the test project with I looked into HWASan, but again, it requires a flashed device. Then I compiled Valgrind and followed the instructions to use it on Android until I realized that the device also needed to be rooted. Since this is the only phone I have available, and it's my personal phone, I don't really want to root it. If I'm the only one who can reproduce this behavior, and it's impossible for me to learn more about it in the current state, should we close this issue? If that's the case, morally, I will absolutely avoid using vox files on Android. |
|
try making a simple test case for the pc can you induce it to crash? if so valgrind is your friend! |
|
@Bigfoot71 I'm afraid it's very difficult to reproduce and properly track the issue outside of your test environment. I reviewed |
|
@chriscamacho I'm afraid reproducing the exact same issue on a PC might not be that simple, but I'll think about it. I'll search for a way to do it without a rooted device. There must be a way. If anyone has an idea... |
|
@Bigfoot71 On those situations, a solution I used in the past was printing traces all the time for every sensible line of code from the function involved. You should add those traces to |
|
@raysan5 You're right, I'm stupid. I should have done it a long time ago... So, I did three tests:
I'm including the function used with the logs from the last test. Vox_LoadFromMemory_debug.c.txt Edit: I also tried what had worked twice yesterday, which was to launch with 2023-06-07-16-29-53.mp4 |
|
@Bigfoot71 Thanks for the test and the additional info! Could you try just moving Oh, and also replace EDIT: Looking now more carefully to the code, I think the issue is actually that If you use the first solution I proposed, make sure to set |
If the advantage that you're talking about is being a voxel format, then you might want to give a try to Model3D. It is supported by raylib, and the repo contains a command line tool which can convert .vox files into .m3d files. Unlike GLB and OBJ, it's capable of storing voxel data, so you would still have that advantage (voxel info is automatically triangulated into a mesh on load). Further advantage that a .m3d file is much smaller than .vox for the same model. Not a real solution, but hope this helps, |
|
@raysan5 I tried the solutions you suggested. The first one: unsigned char szChunkName[8] = { 0 };
while (fileDataPtr < endfileDataPtr)
{
szChunkName[4] = '\0';
memcpy(szChunkName, fileDataPtr, 4);
szChunkName[4] = 0;
fileDataPtr += 4;
[...]
if (strncmp(szChunkName, "SIZE", 4) == 0)
[...]Its result, it seems to have crashed just after I also tried replacing And the second solution: while (fileDataPtr < endfileDataPtr)
{
char szChunkName[5] = { 0 };
memcpy(szChunkName, fileDataPtr, 4);
szChunkName[4] = 0;
fileDataPtr += 4;
[...]Here is its result, it crashed after 3391 iterations at the I also had a freeze of the app at one time with these logs, I'm sorry, I hadn't noted it was with what solution and I have a doubt now: Otherwise, regardless of the error, the crash never occurs after the same number of iterations but always at the level of To be sure, I specify the procedure: I recompile raylib, I replace the @bztsrc Thank you very much for the suggestion, I'll see that for my project :) |
|
@Bigfoot71 Sorry to read it neither worked... I'm afraid at this point we can assume this issue is out-of-scope of raylib, no idea why it crashes... |
|
I'm still going to keep looking for a bit. Out of spite I rewrote all the necessary code with different function names directly in the Here is the error I got, it became SEGV_MAPERR again, so we are trying to access an unallocated memory area, and this time the logs explicitly tell me that the error occurs in Here is my version of If anyone has an idea, even if it seems stupid, don't hesitate! Edit: By fumbling and testing everything and anything (at this point, weird problem, weird solution) I changed the loop that loads the colors: //(each pixel: 1 byte x 4 : r, g, b, a ) x 256
for (int i = 0; i < 256 - 1; i++)
{
col.r = *((unsigned char*)fileDataPtr++);
col.g = *((unsigned char*)fileDataPtr++);
col.b = *((unsigned char*)fileDataPtr++);
col.a = *((unsigned char*)fileDataPtr++);
pvoxarray->palette[i + 1] = col;
}In this (instead of filling //(each pixel: 1 byte x 4 : r, g, b, a ) x 256
for (int i = 0; i < 256; i++)
{
col.r = *((unsigned char*)fileDataPtr++);
col.g = *((unsigned char*)fileDataPtr++);
col.b = *((unsigned char*)fileDataPtr++);
col.a = *((unsigned char*)fileDataPtr++);
pvoxarray->palette[i] = col;
}And there is no more error at all, it opens every time but obviously the colors are incorrect. Am I losing my mind or is this the beginning of a sign of logic? I also did tests by putting breakpoints everywhere but nothing very meaningful, everything seems perfectly normal at first sight, even before the crashes. |
|
That work under your android when you change palette loop ? |
|
@fxgenstudio Yes exactly, it works when I run it from 0 to 255 rather than 1 to 255 but the colors of the models are incorrect |
|
Ok great news ! |
|
I already did it unfortunately, I put |
|
Maybe a memory alignment problem. |
|
Yes, I just did it but no positive results |
|
Well, I've tried many things again but without success. I had my friends try the same app that crashes on my device, and strangely, it doesn't crash for them. It must be related to my device, I don't know... So we can be sure that this is "out-of-scope of raylib", as mentioned by @raysan5. Therefore, I will close this issue, as it doesn't really belong here. As a conclusion, I will still avoid using this file format for Android with raylib, despite its advantages, because if it happens to me, it may potentially happen to other users as well. Nevertheless, I want to thank you for your patience and all your help! |
I encountered a crash issue when attempting to load a .vox model on Android using
LoadModel(). The application crashes with the following log:The crash occurs in the function
Vox_LoadFromMemorywithinvox_loader.h. It seems to be a segmentation fault (SIGSEGV) with code 1 (SEGV_MAPERR).Steps to Reproduce:
LoadModel/Vox_LoadFromMemoryfunction.Expected Behavior:
The .vox model should be loaded successfully without any crashes.
Actual Behavior:
The application crashes with a SIGSEGV error when attempting to load the .vox model.
Reproducible Demo: Source / APK / EXE - (Dropbox)
Additional Information:
I would greatly appreciate any assistance in resolving this issue. Let me know if any further information is required.
The text was updated successfully, but these errors were encountered: