Closed nadrino closed 4 years ago
Hey,
Can you make a debug build and see where it crashes? You can use aarch64-none-elf-addr2line (from devkitA64) with the crash report from Atmosphere.
Thanks a lot for the support !
How should I use "aarch64-none-elf-addr2line" ? (never used it before)
Run it on the debug elf and give the address of the stack trace you see in the crash report
Le 19 juin 2020 19:30:29 Adrien Blanchet notifications@github.com a écrit :
Thanks a lot for the support ! How should I use "aarch64-none-elf-addr2line" ? (never used it before) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Ok so I need to launch the .elf on my Switch -> it crashes -> reboot the switch -> get the crash repport -> use "aarch64-none-elf-addr2line" to understand the error code. Is it right ?
Yup, the debug elf gets placed next to the nro when you run the makefile
Le 20 juin 2020 01:38:08 Adrien Blanchet notifications@github.com a écrit :
Ok so I need to launch the .elf on my Switch -> it crashes -> reboot the switch -> get the crash repport -> use "aarch64-none-elf-addr2line" to understand the error code. Is it right ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
Ok there we go : 02507420952_010000000000100d.log
But when I do:
aarch64-none-elf-addr2line -e SimpleModManagerGui.elf 0000000a2e54f9a8
I got:
??:0
Actually I don't really know what to excpect from this adress2line command since I know the crash is happenning while glfwCreateWindow
is called. Since glfw is an already compiled library, I don't know what would we be able to do with a line number
By the way here is the list of adresses: SimpleModManagerGui.elf.txt
You're passing the absolute address in memory to addr2line which is wrong. ASLR will place it in a random location on every start. What you should do instead is passing the address relative to the load address to addr2line.
PC: 000000038e271b1c (nx-hbmenu + 0xc4b1c)
<- from your log file
The first number is the absolute address and nx-hbmenu + 0xc4b1c means offset 0xc4b1c from wherever the hbloader loaded you to. Additionally there are a few more flags you can pass to addr2line to get better output. Try running this instead:
aarch64-none-elf-addr2line -e yourprogram.elf -f -p -C -a 0xC4B1C
Oh I see ! Thanks a lot for the explainations !
So running aarch64-none-elf-addr2line -e SimpleModManagerGui.elf -f -p -C -a 0xC4B1C
, here is what I got:
0x00000000000c4b1c: _mesa_GetQueryIndexediv at :?
You want to go further down the stack trace then. Take the same number at the end of the ReturnAddress
lines. From bottom to top this will be the functions called in order before it reached _mesa_GetQueryIndexediv and crashed
Did you try the borealis example homebrew first? Does it run?
To rule out any funky setup issues on your CFW install
The borealis example works perfectly fine (when it's compiled with the Makefile)
I was making a simpler version of my main() function to clean up all annex calls from SMM:
#include <borealis.hpp>
// MAIN
int main(int argc, char **argv){
brls::Logger::setLogLevel(brls::LogLevel::DEBUG);
if (!brls::Application::init("SimpleModManager")){
brls::Logger::error("Unable to init Borealis application");
exit(EXIT_FAILURE);
}
return EXIT_SUCCESS;
}
And here is the error log with the ReturnAddress lines parsed:
X[00]: 000000072456e284
X[01]: 000000072456e298
X[02]: 00000000004f8029
X[03]: 000000003b9ac8c8
X[04]: 000000003b9ac8c8
X[05]: 000000005eede8bd
X[06]: 0000000000000001
X[07]: aaaaaaaaaaaaaaab
X[08]: 0000000000000000
X[09]: 0000000000000000
X[10]: 0000000000000000
X[11]: 0000000000000000
X[12]: 0000000000000000
X[13]: 0000000000000000
X[14]: 0000000000000000
X[15]: 0000000000000000
X[16]: 0000000000000000
X[17]: 0000000000000000
X[18]: 0000000000000000
X[19]: 0000000000000000
X[20]: 0000000000000000
X[21]: 0000000000000000
X[22]: 0000000000000000
X[23]: 0000000000000000
X[24]: 0000000000000000
X[25]: 0000000000000000
X[26]: 0000000000000000
X[27]: 0000000000000000
X[28]: 0000000000000000
FP: 0000000008041eb0
LR: 00000007244a6e58 (nx-hbmenu + 0x95e58): 0x0000000000095e58: _mesa_GetString at :?
SP: 0000000008041eb0
PC: 00000007244a5c94 (nx-hbmenu + 0x94c94): 0x0000000000094c94: draw_buffers_error at :?
Stack Trace:
ReturnAddress[00]: 00000007244af22c (nx-hbmenu + 0x9e22c): 0x000000000009e22c: nvc0_init_query_functions at :?
ReturnAddress[01]: 00000007244e3a14 (nx-hbmenu + 0xd2a14): 0x00000000000d2a14: teximage_no_error at :?
ReturnAddress[02]: 000000072441bbe0 (nx-hbmenu + 0xabe0): 0x000000000000abe0: glnvg__setUniforms(GLNVGcontext*, int, int) at /Users/ablanche/Documents/Work/Repositories/SimpleModManager/test/../gui/library/borealis/library/include/borealis/extern/nanovg/nanovg_gl.h:975
ReturnAddress[03]: 00000007244af368 (nx-hbmenu + 0x9e368): 0x000000000009e368: create_queries at :?
ReturnAddress[04]: 00000007244b038c (nx-hbmenu + 0x9f38c): 0x000000000009f38c: _mesa_EndQueryIndexed at :?
ReturnAddress[05]: 0000000000000000
I had hoped the pacman packages had debug symbols for mesa and/or glfw, not everything seems to be present
Does the same code work with a Makefile?
Gonna try that!
It might comes from some compile/link options that are added by cmake
Hum... compiled it with a Makefile and also got a crash. Didn't expect that
I've commited these test files I've been working on : https://github.com/nadrino/SimpleModManager/tree/debug/test. In case you see something obvious...
Same crash?
It seems. In fact I've put the exact same files from the example, and while compiling with this Makefile I got:
0x0000000000094c94: _mesa_FramebufferDrawBufferEXT at :?
So regular Makefile and regular example works, but your own Makefile and the example doesn't work?
Yes, and I would say only my Makefile (which is practically just a copy-paste of the example with updated paths) is wrong since the source files are exactly the example ones : https://github.com/nadrino/SimpleModManager/tree/debug/test
How can only paths changes cause such a crash?
Alright it's working now!
Yes, at this point I throught may be there was something wrong with the resources path.
The last issue was comming from the fact that I was leaving the "rootFrame" empty, which seemd to be the exact same problem as for the cmake project.
I retried compiling within my cmake project after doing a bit of cleaning, and there I couldn't compile anymore. This was actually because I was not including the SMM files correcly. I believe some wierd cmake cache was responsible for making the .elf compilable.
So in short: cleanup the cmake cached files...
Thanks a lot for the support @natinusala, I think it was very useful for me !
Btw I got a last question : In borealis you are using a logger. Does it write the ouput in a file somewhere ? I mean how this is intended to be used ?
Glad to hear that's fixed!
You need to use nxlink to get logs at runtime, as with any other homebrew
Hello there,
I'm trying to use borealis as a submodule for my Switch homebrew SimpleModManager. I included the borealis lib with cmake in my project, and the compilation seems to work fine. However when I try to launch it on the Switch it crashes.
I've tried to isolate the problem and it seems like it comes from there :
When
glfwInit()
is called, it makesglfwCreateWindow
crashing.Have you any clue on where it could come from ?
P.-S. Great GUI by the way :) It's been a while since I've looked for a kind a neutral GUI lib for the swich!