Error Treatment

I have a little question. You know there are some games that have several crashes, which are possible to bypass by disabling hardware renderer.
So my question is: Is it possible to at least detect those app crashs? Because then it’d be possible to disable hardware renderer in the source code as long as this error would be caused.

this would greatly increase compatibility until you guys can finally solve this error completely.

in my example, i’m playing PMD Super and it’s not possible to save every time i want to.
it’s somehow possible to guess when it’ll come to a crash but you can’t really look forward when those cutscenes appear, where the crash usually occur, so if you miss one - crash. and you have to start from the beginning.

Thank you for your good work :slight_smile:

I think that the closest thing would be to extract the log that Citra’s log console does each time you run it.
In fact, in the old forums, there was a command that extracts the content of that log to a .txt file, and it gets filled with what the log console says until the game crashes.
Sadly, I can’t remember it, through.
And I apologise if I didn’t explained it very well.

We’re actually working on better crash reporting tools to make this easier, it won’t be ready for a while, but we’re aware this should be easier.

Glad to hear that, Flame!
Through, at the moment, it would be nice to have that command, that is, until those crash reporting tools are finished.
PS: BTW, great job on the Citra Emulator! You all are doing a nice work!

The command at least in Windows, is citra-qt 2>log.txt to log all output from citra-qt.
This needs to be ran in a command line window, in the Citra directory.

Thanks a lot.
Through, I know this is offtopic, but how can I quote on those forums?

Oh, thanks, I’m so sorry, this is the first time I’m in that kind of forums.

No problem :slight_smile: You’ll get used to the layout!

1 Like

well that’s basically nice but since citra really crashes i don’t think it’s been logged.
i would’ve reported the crash log if i had one, because when windows says “not working” it’s still possible to read the console.
so… maybe you mean another log but however.
i thought the error might not be stated in the logs but maybe it’s possible to find that kind of error or spot a line in that x0000 lines of code that makes citra crash when filled with wrong data etc…
i’m not common to that stuff. it was just an idea i had so you could just do a try/catch statement to block that error and turn the hardware renderer off in case so… yeah…
you don’t even have to care to turn it on again when the error doesnt appear anymore, because mostly you see, when the cutscene ended.
at least i think its about some kind of cutscenes… because i’ve never seen the error in another game than PMD Super.

The error you’re describing sounds exactly like the error that happens in Pokemon Super Mystery Dungeon. There, it tells me it’s a “zero input width” error. Does anyone know how to fix that? This issue is known, don’t know if it’s being worked on. I have also written about that issue in more detail there. This issue also happens on PMD: Gates to Infinity, but for whatever reason, if it throws the error there, it doesn’t crash. [quote=“The_Spanish_Inquisit, post:11, topic:223”]
“zero input width”

Then there must be something else that isn’t logged and makes the emulator crash at that point on Super Mystery Dungeon.

Well, what happens is the emulator tries to read a broken RGBA8 texture and fails, thus resulting in a crash. This issue is also a regression, because if you turn off H/W renderer, it goes past that scene. Why you don’t see it in the log is because it first tries to read, then it writes into the log.

if you know where the error is, just put it in a try catch blog to prevent it from crashing. or is it more complex?
this’d be the best way of doing things don’t you think?

The best way to NOT get this error is enabling S/W Renderer for the scenes.[quote=“kokujou, post:15, topic:223”]
if you know where the error is, just put it in a try catch blog to prevent it from crashing.

if i disable hardware renderer the games speed is below 1%. you can possible play this way.
so you have to find another way. we don’t see when the error occurs. at least print out some pre-error or anything like that that allows us to bypass the specific scene.
you can’t tell us to always let the game crash and remember the point where it crashs.

It’s normal. The H/W renderer is a huge speed-up for Citra. You don’t have to play the entire game with it being off, just being the cutscenes with the error. (it’s actually 10%)

This could be very difficult to do (please don’t flame me developers if that’s wrong), because this error happens before it produces it to the log. There’s no specific error before, that could tell about this error.

thats exactly what i’m saying! so the easiest way to handle it would be to catch the error. just find the line of code that produces the error. if it’s really a texture problem as i read above it shouldn’t be that hard.
catch the error, disable hardware renderer in code till this error don’t happen again and turn it on again.
or let the user turn it on, when the cutscene is over.

the problem is: you can’t see when a cutscene is coming. ok mostly its in the battle but even after the battle surprising cutscenes are coming.

There’s no reason to do that. The focus is on accuracy and I would consider something like that more of a “hack,” which is highly frowned upon. Things will be fixed over time.