Bug of cheat function

[Zection6V]

I’m not sure how to reproduce it, but when editing cheats in melonDS, sometimes while the codes are being written to the cheat mch, the same code gets written over and over infinitely, causing the file size to become enormous. It ended up reaching 580 MB.

[Zection6V]

And sadly, all the codes after that one disappeared. It might be nice to have a backup feature.

[Arisotura]

Would be nice to have a way to reproduce this. I could try testing it hard, but not sure I could get it to reproduce.

[Zection6V]

Oh, thanks for caring. You're so kind. I used AI to see if I could figure out what might be causing it.

result here:

I think I found a likely cause of the .mch corruption / runaway file growth issue.

There appears to be a serious structural bug in CheatsDialog.cpp that could explain why the same cheat code sometimes gets written over and over until the file becomes enormous.

Likely cause

The main problem seems to be that the cheat tree UI stores raw ARCode* / ARCodeCat* pointers inside QStandardItem data (Qt::UserRole + 1), while the underlying cheat tree is still being modified with operations such as:

• emplace_back(...)
• erase(...)
• emplace(...)
• subtree copy / move during drag and drop

If the underlying Children container reallocates or elements are moved/erased, those raw pointers can become invalid. After that, the UI may still be holding stale pointers and using them later for edit / delete / drag-and-drop operations.

That means the dialog can end up modifying or deleting the wrong nodes, or constructing a corrupted tree in memory. Then, when done() calls codeFile->Save(), the save code may be serializing an already broken structure, which could explain the repeated code output and huge .mch size.

Additional bug in category drag-and-drop

There is also another serious issue in the category move logic.

When a category is moved, the subtree is copied, but the parent pointers appear to be fixed only for the immediate children. Descendants deeper than one level do not seem to have their Parent pointers recursively updated.

So after moving a nested category, part of the subtree may still point to the old parent chain. That can corrupt the tree structure even if the UI looks mostly correct.

Why this matters

Even if the actual infinite write loop is happening inside the save code, CheatsDialog.cpp appears capable of handing Save() a corrupted cheat tree.

So the root cause may not be "the file writer loops forever by itself", but rather:

1. the cheat tree becomes structurally invalid in the editor
2. Save() receives broken data
3. the resulting .mch output becomes duplicated / runaway / massive

Suggested fixes

• Stop storing raw ARCode* / ARCodeCat* pointers in QStandardItem
• Use stable IDs, paths, or heap-stable node references instead
• Do not put raw pointers into drag-and-drop MIME data
• Recursively fix Parent pointers for the entire moved subtree, not just immediate children
• Add safety checks in save code:
  • cycle detection
  • visited-node protection
  • temporary file + replace-on-success

[Arisotura]

The main problem seems to be that the cheat tree UI stores raw ARCode* / ARCodeCat* pointers inside

that's why those come from a std::list - because those pointers are guaranteed to stay valid even when the list is modified

When a category is moved, the subtree is copied, but the parent pointers appear to be fixed only for the immediate children. Descendants deeper than one level do not seem to have their Parent pointers recursively updated.

which is by design - "descendants deeper than one level" are simply not a thing. the editor doesn't let you create them - it doesn't let you drag an existing category into another category, or create nested categories.

[Zection6V]

Thanks for your answer!
I had them check to see if there might be any other causes. I'm sorry this is about all I can do.

---

You're absolutely right — thanks for the correction.

I was wrong on both of those points:

• ARCode* / ARCodeCat* coming from a std::list means those pointers are intended to remain valid across normal list modifications, so my earlier pointer-invalidation suspicion was off.
• I also assumed deeper nested category descendants could exist, but if the editor does not allow creating or moving nested categories at all, then that part is not relevant either.

So those parts of my earlier analysis can be disregarded.

That said, the most suspicious thing in this file still looks like the iterator handling when drag-and-drop is used to reorder items within the same parent.

In dropMimeData(), the insertion position (newit) is computed before the source element is erased. If the move happens within the same parent, and newit ends up referring to the element being erased, or otherwise becomes inconsistent after the erase, then passing that iterator to emplace(newit, ...) would be undefined behavior.

That would fit pretty well with the symptoms here:

• hard to reproduce reliably
• possible in-memory tree corruption
• and then a broken structure being serialized later, causing the .mch file to grow abnormally large

There is also a separate issue in onCheatEntryModified():

For a code directly under the root, item->parent() can be nullptr, and the code may then go on to call parent->rowCount() unconditionally. That seems more like a crash bug than a file-growth bug, but it still looks like a real bug candidate.

So I agree that my earlier explanation was wrong, but I still think there is likely a real bug here, just in a different place.