Maybe manually deleting things like the datacache folder? Who knows? Completely uninstall your module. Mark it as uninstalled in the DB and completely remove it from the classes and all skin directories.
I am sure you have it packed up where you can reinstall it, but if not you can just manually copy the files while keeping the structure the same so you can paste them back in if needs be.
I am targeting your module because I am assuming that is where the issue lies. By taking it completely out of the equation, we can determine where the true problem lies. You can easily spin up fresh instance of X-Cart and install your module there. If that works than we can rule out your module.
After removing your module file, I would literally do a file diff in Winmerge or similar, without including var or images or files, against your fresh instance of XC just to see if there are changes. If all is well then we can rule out XC's files and your module. And then we can start looking at the database for corruption.
If all is well in a fresh install of XC, can we just port the language tables and the products from the dev site to the fresh install? With an import/export?
If all is not well with XC itself (and it's modules), can we disable the modules one by one to see if any are causing the problem?
I have to say, memory leaks like this are pretty frustrating. The error message is not helpful at all. If only PHP had some kind of garbage collector, or some way to show exactly where the leak is coming from! I am sure someone with more knowledge than I could help pinpoint the problem, there has to be a way to find out the origin. All the methods I can suggest are very tedious and labor intensive. But from what I can tell about you, you will persevere till it is found.
Maybe someone else can share some techniques for tracking this nasty bugger down. Tony? Alex?
Here is my experience: I have a client site that was built on what I would consider a beta version of XC, with many modules (custom and official) installed and uninstalled over the last couple years. It has a highly customized skin built by QSL (autoparts). At this point, its honestly a mangled limping dog of a site.
Every time we rebuild cache it hangs on step 8. Same type of memory leak.
We have found that it will rebuild perfectly without the QSL skin enabled. And it will rebuild after the QSL skin is enabled. But it will only rebuild once. On the next rebuild, you will have to disable the QSL skin or it will hang. So if you make any changes to modules on this site and need to rebuild, you first have to disable the QSL skin, which triggers a rebuild; make your changes, then re-enable the QSL skin, rebuild. This may be your workaround that I mentioned earlier. But you need to narrow it down to which module is the culprit. That took us 2 days of work, on a job we only billed 2 hours for. Ouch.