Paul Vriens wrote:
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
If it's heap corruption then it could well depend on the order of allocations, so it could be timing dependent. I've attached a patch that poisons the apartment structure after when it is freed so that hopefully any use-after-free will become more obvious. Could you apply it and see what the results are? Does the X Error stop? Do we now get warnings about accessing a handle of 0xcccccccc (run with warn+all for this)?
Rob
I can remember having a conversation with Christian Costa for the same kind of error.
That was after he added some extra filter registration in quartz/regsvr.c. I just played around with the CoInitialize in register_filters. I changed CoInitialize(NULL) into CoInitializeEx(NULL, COINIT_MULTITHREADED) and the error was gone.
When I do the same change now, the X Error is gone as well. Does this give you a clue?
Not much I'm afraid. When using an MTA the window isn't created, so there is no chance of an X Error during its destruction. There is something you could try though. Can you move the "if (apt->win) DestroyWindow(apt->win);" line in COM_ApartmentRelease to after the LIST_FOR_EACH_SAFE list iteration? If the apartment pointer is bad then we should easily die in the list iteration (the iteration will only end once it finds a pointer back to the original list, which is very unlikely if we are using a bad apartment pointer). I also noticed in the log that you are getting a few heap warnings. Could you try scattering a few of these debug statements throughout the devenum self-registration code (particularly around any COM calls): if (!HeapValidate(GetProcessHeap(), 0, NULL)) DebugBreak(); This should then dump you to the debugger close to where the heap corruption occurred. If you can narrow it down to one line in devenum (i.e. it succeeds before the call, fails after) then can you let me know which line that is and that should be a big clue to finding out what is going wrong.
Thanks, Rob