How do I debug this?

[CenTdemeern1]

I was trying out citro3d, everything was going alright, but then when I made a call to draw my VBO this happened. This isn't a normal panic type thing so I have no idea how to debug this.

2 questions:

1. How do I debug this?
2. Do you have a Discord server or IRC channel or something where I can get some help with this kind of thing through a live chat?

[FenrirWolf]

1. There are a few ways to try debugging it. One would be to use gdb, which you can use by following this guide in the ctru-rs wiki. You can also try $DEVKITARM/bin/arm-none-eabi-addr2line -C -e <your-homebrew-program.elf> -a <address> with the PC and LR values from that crash dump to see where in the source code those addresses correspond to.

2. We don't have a discord or IRC or whatnot at the moment, though I honestly feel like we should.

[CenTdemeern1]

Also regarding this

(but I'm unsure whether anyone would be interested in chatting on it for long 😂)

As long as:

• 3DS-development-in-Rust-related discussions keep happening (like showing what you're working on or discussing suggestions for API changes)
• new and old people keep asking questions

it should be fine, you should have a decent amount of activity. And even if not, it makes you ready to have activity and makes it more easy to advertise that "we exist, we have cool tools, and we are willing to help!"

Having a well organized Discord server with a few (or more) people in it also shows that you have a community or are ready to have one which is more welcoming and reassuring when trying out the tools

Keeping people chatting for very long probably doesn't have to be a priority because it's not really a "just chatting server", and if people have things to talk about they will

Discord servers also make for a nice place to have things like announcements, in a way that allows people to enable notifications and such (so you can announce releases, get people to partake in a poll without requiring them to run across it by chance, etc)

Lastly many people put GitHub webhooks in channels so they can quickly catch up on PRs and comments for example (Discord has special GitHub integration if you put /github at the end of the url, just a tip, though not sure if this is still needed)

Just using Discord as an example here because it's the popular option. Something like Matrix could probably work too (but less people use that and are probably less willing to get notifications from that) and so could IRC (though there you can't really post screenshots as easily for example)

Those are my two cents on the topic, hopefully it helps spark some ideas or something. I don't know how to end this half-infodump-half-suggestion

[AzureMarker]

I'll defer to the people more active in the project, but here's my take as someone with experience in long running open source projects like this one.

Discord servers cost time to maintain and moderate, which takes away from time available to work on the project. They can also sap motivation if people would rather work on code (similar to what Meziu said about feeling pressured). Contributor health is very important, burnout is real. I'm not very active in the project now, but even the most active members might not be able to give the real time responses you seem to want, so a more async platform like GitHub is a good fit. Remember that we all have lives going on outside of GitHub.

Unless we start outgrowing the capabilities GitHub provides us for collaboration and discussion, I don't think investing in a Discord server would be a wise way to spend contributor time. That being said, this could change in the future if there's a big influx of people interested in the project and needing real time collaboration.

[ian-h-chamberlain]

I've occasionally thought about whether it would make sense for us to setup a chat like this, particularly recently it seems like a number of people have had minor toolchain setup problems which might have been quickly resolvable via a Discord or something like that. However in the same vein as what @AzureMarker said, there are only a couple of core devs and we mostly just work on the project as we have time, which can sometimes be "not at all" for long stretches.

That said — we could try out some free option for a while, and see how it goes? Worst case everyone just stops using it, right? I think the Rust project has had good luck with https://zulip.com, which has threading and a decent "async" workflow, so that might be another option to consider vs Discord / IRC? We may (if needed) qualify for their free option as an open source project as well.

I don't personally have a strong preference one way or the other, and I haven't had a ton of time to spend on this project lately, so I guess idk what other @rust3ds/active people are thinking and whether this would be worth it or not.

[CenTdemeern1]

I've personally never heard of or used Zulip, so I don't know how easy it would be to get people to join that platform just to ask simple questions. So I'm not against it, it's good to have options, but I'm just trying to point out that it's a good idea to take into consideration which platforms people (mainly the people who'd want to join a chat to ask a question) are already using or can get started on without too much commitment (as in the commitment of making a new account on a new service you don't already know). That's kind of still why I (and possibly many others) would prefer Discord over Matrix for example. The last time I used Matrix I found out I already had an account from 4-5 years ago which I completely forgot about and never used

Also, since I use Discord a lot in general, I'd be down for stopping by every once in a while and answering questions in the server when I can. (And/or helping set it up if you'd like help with that)

[CenTdemeern1]

I'll defer to the people more active in the project, but here's my take as someone with experience in long running open source projects like this one.

Discord servers cost time to maintain and moderate, which takes away from time available to work on the project. They can also sap motivation if people would rather work on code (similar to what Meziu said about feeling pressured). Contributor health is very important, burnout is real. I'm not very active in the project now, but even the most active members might not be able to give the real time responses you seem to want, so a more async platform like GitHub is a good fit. Remember that we all have lives going on outside of GitHub.

Unless we start outgrowing the capabilities GitHub provides us for collaboration and discussion, I don't think investing in a Discord server would be a wise way to spend contributor time. That being said, this could change in the future if there's a big influx of people interested in the project and needing real time collaboration.

Ah sorry, I didn't see this message. Yeah, that's fair enough

[Meziu]

I heavily suggest you to share what piece of code caused an ARM panic, since it probably means there are some unsafe cases not properly handled by the wrapper. This is what we are working on improving, so learning the underlying issue would be great 😃.

[CenTdemeern1]

I'd have to make a more minimal example because right now my codebase isn't exactly small. I'll work on that, gimme a bit

[CenTdemeern1]

Update: done! Here it is:
gpu-repro.zip
I can also make a repo for it instead if you'd like.

[CenTdemeern1]

@Meziu here's an @ mention in case you didn't see this (like if it got lost in a sea of notifications or something)
I can also make an updated version that still crashes but actually specifies a projection matrix this time because I've figured out how to do that now

[Meziu]

@Meziu here's an @ mention in case you didn't see this (like if it got lost in a sea of notifications or something) I can also make an updated version that still crashes but actually specifies a projection matrix this time because I've figured out how to do that now

The triggered abort is here.

Here's the full backtrace:

In particular, the gpuCmdBuf pointer seems to be null, which is what causes the crash:

@ian-h-chamberlain since you worked on most of the wrapping library, do you know how this could be possible? (I don't have the time right now to hardware watch the changes in that pointer 😓 ).

[CenTdemeern1]

Update: after placing a bunch of trace prints I found out the application locks up in apt.main_loop() when the HOME or Power button is pressed, and it locks up after this "Trace 15" when start is pressed (aka after main?)

The application does not actually lock up until you try to exit or cause some other interrupt
When trying to open the Rosalina Menu it seems to just freeze on the spot without a clear trace step it stops at

[ian-h-chamberlain]

Hmm, this sounds like possibly a libctru or Horizon kernel bug, but I suppose it's still possible that it's caused by some undefined behavior as a result of using the GPU incorrectly or something (or maybe another drop implementation is triggering it?) Do you have a Git repo for the code after you made those changes?

[CenTdemeern1]

Do you have a Git repo for the code after you made those changes?

I do, I'll go make sure everything is committed and I'll make it public

[CenTdemeern1]

Update: done, the repo and relevant binary crate that runs on 3ds can be found at https://github.com/CenTdemeern1/witness-rs/tree/main/frontend-3ds

[ian-h-chamberlain]

Ok, I was able to reproduce the problem on my 3DS (not in Citra, interestingly), and got this stack trace:

#0  svcArbitrateAddressNoTimeout () at /Users/davem/projects/devkitpro/pacman-packages/libctru/src/libctru-2.3.1/libctru/source/svc.s:253
#1  0x00107bd8 in syncArbitrateAddress (addr=<optimized out>, type=<optimized out>, value=<optimized out>) at /Users/davem/projects/devkitpro/pacman-packages/libctru/src/libctru-2.3.1/libctru/source/synchronization.c:22
#2  0x0010683c in gspWaitForAnyEvent () at /Users/davem/projects/devkitpro/pacman-packages/libctru/src/libctru-2.3.1/libctru/source/services/gspgpu.c:311
#3  0x00136d3c in gxCmdQueueWait (queue=<optimized out>, timeout=<optimized out>) at /Users/davem/projects/devkitpro/pacman-packages/libctru/src/libctru-2.3.1/libctru/source/gpu/gxqueue.c:116
#4  0x00133be0 in C3Di_WaitAndClearQueue (timeout=<optimized out>) at /Users/davem/projects/devkitpro/pacman-packages/citro3d/src/citro3d-1.7.1/source/renderqueue.c:95
#5  0x001342f4 in C3D_RenderTargetSetOutput (target=target@entry=0x0, screen=GFX_TOP, side=GFX_LEFT, transferFlags=transferFlags@entry=0) at /Users/davem/projects/devkitpro/pacman-packages/citro3d/src/citro3d-1.7.1/source/renderqueue.c:381
#6  0x00134318 in C3D_RenderTargetDetachOutput (target=target@entry=0x82048a8) at /Users/davem/projects/devkitpro/pacman-packages/citro3d/src/citro3d-1.7.1/include/c3d/renderqueue.h:69
#7  0x00134348 in C3D_RenderTargetDelete (target=0x82048a8) at /Users/davem/projects/devkitpro/pacman-packages/citro3d/src/citro3d-1.7.1/source/renderqueue.c:366
#8  0x00112bd0 in citro3d::render::{impl#0}::drop (self=0x81ffb6c) at src/render.rs:33
#9  0x001010d8 in core::ptr::drop_in_place<citro3d::render::Target> () at /Users/ianchamberlain/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:514
#10 0x001034e4 in witness_3ds::main () at frontend-3ds/src/main.rs:105

So maybe there is some kind of deadlock in the order things are getting dropped? In the meantime I filed rust3ds/citro3d-rs#48 so any further investigation can go there.