• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 2 3 4 5 6 ... 116 Next »

Debugging in-game memory leak by adding more emulated RAM
View New Posts | View Today's Posts

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Debugging in-game memory leak by adding more emulated RAM
01-26-2022, 03:35 PM
#1
Leseratte10 Offline
Wiimmfi-Team
***
Posts: 55
Threads: 10
Joined: Apr 2019
I've been debugging a weird memory leak bug in Mario Kart Wii (unrelated to Dolphin) over the last couple days that we've ran into while developing a new feature for Wiimmfi. In order to debug this more efficiently, I need to make sure that the game's internal "malloc" methods never run out of space and always return valid memory, so I would like to use Dolphin to give the game access to more RAM to do that.

More context: I have been unable to figure out which exact code is responsible for the memory leak, but I noticed that there's like a dozen different malloc-like functions in the game, each used by various "subsystems". If II could go through these, one-by-one, and make them allocate RAM from elsewhere (no longer using "main" memory), I could figure out which of the malloc functions is the culprit (the one where the leak stops when it's allocating from elsewhere).

I saw in the code that Dolphin seems to have a code path to emulate a development console instead of a retail one to have more RAM, but I don't think that that is going to help me. That will increase the size of the main mem90 range, but all the internal heaps the game creates will still have their original size. As this is purely for testing and not something that will ever run in production, I had the crazy idea of "inventing" my own memory range.

Is it possible to mod Dolphin to just consider like the range between 0x50000000 and 0x7fffffff to be valid memory, without assigning it to either mem80 or mem90? So that a stock unmodified game will never read or write to that RAM on its own, but custom game patches / code can read and write (execute would be cool, but isn't required) from and to this memory block?

Then I could, one-by-one, patch the game's malloc methods to just always return space from that range (and maybe I don't even need to bother freeing anything and can just return new space every time), and once I notice that the game's actual RAM usage in mem80 and mem90 is no longer leaking / uselessly increasing, I know that the malloc function I'm currently "redirecting" to the new is responsible for the memory leak, and I at least have less code to analyze for memory leaks. The game doesn't have any checks on the return value of malloc (except checking if it's 0), so it should handle nonstandard addresses just fine, I hope.

I assume that since the games all implement memory management, heaps, malloc/free, ... themselves there's probably no feature in Dolphin to help debug memory leaks either, is there? Or any other feature that would help in this case?
Find
Reply
01-26-2022, 10:05 PM
#2
Neui Offline
Quiet
***
Posts: 175
Threads: 1
Joined: Apr 2015
I am not entirely sure why you think of an additional memory region, but don't want to simply increase the memory areas (MEM1 and MEM2) Dolphin can already do in the advanced settings and use the additional memory gained from that as the additional region (together with that the game doesn't seem to use the additional memory of its own as you wrote).

Also, as an possible alternative method/idea, maybe "tag" each allocated area (like each (or just one?) malloc function allocates 4 or 8 more bytes to contain some (hopefully non-clashing) subsystem identifier, removing that tag on free, and check what tag increasingly "appears" by scanning the memory.) (In the game code itself I mean, not Dolphin)
Find
Reply
01-26-2022, 10:46 PM
#3
Leseratte10 Offline
Wiimmfi-Team
***
Posts: 55
Threads: 10
Joined: Apr 2019
The problem with just increasing MEM1 and/or MEM2 in the Dolphin settings is that the game will "know" about that and then start using the additional memory so I no longer have a continuous empty space for my tests. That's why my idea was to introduce a new range that can be written to / read from, but won't be used by normal games. Maybe that's a stupid solution, but I had no other idea. 

Your idea with increasing the size to store an identifier sounds useful, though. Then I could do that once with a stock game (to count how many occurrences of each type usually end up on that heap) and once with my modifications, and then I should be able to see which type is present more often. 

I'll give that a try, thanks for the hint.
Find
Reply
01-26-2022, 11:12 PM
#4
notmiguel Offline
Spanish Member
**
Posts: 44
Threads: 0
Joined: Oct 2021
(01-26-2022, 10:46 PM)Leseratte10 Wrote: The problem with just increasing MEM1 and/or MEM2 in the Dolphin settings is that the game will "know" about that and then start using the additional memory so I no longer have a continuous empty space for my tests. That's why my idea was to introduce a new range that can be written to / read from, but won't be used by normal games. Maybe that's a stupid solution, but I had no other idea. 

Your idea with increasing the size to store an identifier sounds useful, though. Then I could do that once with a stock game (to count how many occurrences of each type usually end up on that heap) and once with my modifications, and then I should be able to see which type is present more often. 

I'll give that a try, thanks for the hint.

One question (offtopic of course). Are you the real Lesseratte?
Just another forum user, nothing special.
The character on my profile picture is 2k-tan: https://www.ostan-collections.net/wiki/index.php/Windows_2000
More info about OS-tans: https://www.ostan-collections.net/wiki/index.php/Introduction
Find
Reply
01-26-2022, 11:58 PM
#5
Leseratte10 Offline
Wiimmfi-Team
***
Posts: 55
Threads: 10
Joined: Apr 2019
If by "real" you mean the one who created the LE-CODE, Wiimmfi and stuff like that, yeah, that's me. 
Find
Reply
01-27-2022, 02:03 AM
#6
notmiguel Offline
Spanish Member
**
Posts: 44
Threads: 0
Joined: Oct 2021
(01-26-2022, 11:58 PM)Leseratte10 Wrote: If by "real" you mean the one who created the LE-CODE, Wiimmfi and stuff like that, yeah, that's me. 

That is very cool
Just another forum user, nothing special.
The character on my profile picture is 2k-tan: https://www.ostan-collections.net/wiki/index.php/Windows_2000
More info about OS-tans: https://www.ostan-collections.net/wiki/index.php/Introduction
Find
Reply
01-27-2022, 03:36 AM
#7
JosJuice Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 8,873
Threads: 7
Joined: Oct 2014
(01-26-2022, 03:35 PM)Leseratte10 Wrote: Is it possible to mod Dolphin to just consider like the range between 0x50000000 and 0x7fffffff to be valid memory, without assigning it to either mem80 or mem90? So that a stock unmodified game will never read or write to that RAM on its own, but custom game patches / code can read and write (execute would be cool, but isn't required) from and to this memory block?

This is possible. In fact, Dolphin already has such a region of memory at 0x7E000000 to 0x7FFFFFFF, which is used to trick some GameCube games that otherwise would have required MMU emulation into working without MMU emulation. You can enable it for Wii games by changing this line: https://github.com/dolphin-emu/dolphin/blob/c18abfaecc5bf5c21da57d4b8a08f5bf4557187f/Source/Core/Core/HW/Memmap.cpp#L271
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode