Closed paladin-t closed 10 months ago
It's a bit weird I suppose, but the way it currently works is that the ROM data ownership is passed to the emulator. Are you using this in some way where you want to retain ownership of the ROM data after the emulator is destroyed?
The application layer is written in C++. The emulator per se and the ROM are both retained by a wrapper class. In particular the ROM data is created and owned as a member field like std::shared_ptr<Bytes> rom = std::shared_ptr<Bytes>(new Bytes(...))
. They will be both unused and released at a same time; so the problem is not a ROM lives longer than an emulator instance, it is just I hope that ROM is released consistently with it's creating.
Unfortunately that's not a valid strategy with the most recent changes, since the emulator may resize the rom data (see e.g. https://github.com/binji/binjgb/blob/1e67a7515824924289a8d4ce85030806297301e2/src/emulator.c#L1196). You really should assume that when you call emulator_new()
that ownership of the ROM data has been passed to Emulator
.
Ok. Then I think it's better if there were another initialization workflow that duplicates input ROM data inside emulator. In short, an emulator who is in charge of freeing should be also in charge of allocating the space for ROM data.
At least for the ways I use emulator_new()
, it works best to pass ownership. The calling code has no need for the ROM data after it's been loaded. And similarly, it doesn't make sense for the emulator itself to allocate the space since it doesn't know how much it will need; the ROM data could be coming from a file on disk, or generated automatically in memory, or anywhere else.
If you want your calling code to retain ownership the best way is to make a copy yourself to give to the emulator, rather than having an additional option in EmulatorInit
to do this.
I see. I'm ok with that.
In the latest revision in function
emulator_delete
,file_data_delete
is called to release ROM data.https://github.com/binji/binjgb/blob/1e67a7515824924289a8d4ce85030806297301e2/src/emulator.c#L5050-L5056
The data is created outside the emulator, but it's released inside it, which causes unmatched malloc/free. There should be a way that allows a programmer to indicate whether the memory of ROM data is managed by emulator or its caller.