RAEmus icon indicating copy to clipboard operation
RAEmus copied to clipboard

RAP64 crash when you do the following

Open eldexterr opened this issue 5 years ago • 2 comments

Video Link (the video resolution is very low but I think isn't really important):

In the video I just keep playing while im filtering values until the emu crash, every time I filter, and not a lot of values are wiped from the search

I think when you are searching for a variable and the search values ​​does not change very much and you keep searching without wiping a lot of values ​​from search to search, the emulator can not handle it and just crash

This has happened to me 3 times, and every time I do this, also a window always pop up saying "Windows C ++ Runtime error" (actually in the video did not pop up this time, but the 2 others times it appeared )

eldexterr avatar Apr 26 '19 21:04 eldexterr

This is an out-of-memory error.

Exception thrown at 0x778718A2 in RAProject64.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0019EFFC.

It's not specific to RAP64, but easiest to reproduce there because the N64 RAM is larger than other systems.

When filtering searches, the previous results are remembered for the "<<" functionality. If you're not reducing the number of results, the search history quickly eats up memory. In my testing, each filtering resulting in four million results would consume about 20MB, and the application would crash when Task Manager reported it was using around 800MB (around 35 filterings). If I counted correctly, you crashed after filtering 21 times.

It's unclear why the process is running out of memory at 800MB - I'd expect it to last until close to 2GB. It may be dependent on the machine specs or what else is running on the machine, which might be why I was able to filter almost twice as many times as you.

Additionally, it's unclear why each filtering is consuming 20MB. It should only be consuming around 5 or 6MB (4MB for the RAM snapshot plus a small amount of overhead for the search filter).

The search buffer starts discarding previous results once 50 results are captured, and starting a new search discards all the previous buffers and the memory associated to them. I've verified both of these behaviors, so it's not a memory leak, it's just using too much memory.

I've mentioned in the past that keeping more than one or two previous searches to revert back to was unnecessary, and received feedback that sometimes more was needed. Since there was no consensus on how much was acceptable, we left it at 50.

Ideally, the process shouldn't crash. It wouldn't be too difficult to catch this specific case, but once the process is out of memory, the bad_alloc could occur pretty much anywhere. The best solution I can think of would be to track how many total results are in all of the search history and use that as a heuristic to determine how many previous searches to keep.

As a workaround, you can change your filter from "All" to a specific memory range. Even just doing 1MB instead of 4 should be lower the memory requirements sufficiently to hit the 50 results limit before running out of memory.

Jamiras avatar Apr 28 '19 03:04 Jamiras

Isn't a very huge problem for me because this happen in very strange times, now I know how not to triggered it 😁👍

Also thanks for the reply, I love when you reply in a very detailed way, since I understand a bit more of how emulators work Thanks

eldexterr avatar Apr 28 '19 06:04 eldexterr