Aleksey Bragin wrote:
On May 1, 2010, at 7:57 AM, James Tabor wrote:
I'm reacting to when it gets broken! I could be wrong and when I am I do admit it openly! But, you need to read bug 5265. I guess we can revert all the gdi batch code to fix it. Yes it fixes it but still the real problem persists, what happen to the TEB?
This is exactly the problematic behavior: Why enable GDI batch code if it does NOT work? Fix underlying bug *first* and then enable the code. Especially considering that GDI batch may be seen as optimization, not as a vital code needed for rendering. Is it?
And honestly, you are trying to find a bug in the wrong direction, in my opinion. Analyze it logically: somehow, TEB appears to work everywhere except for your GDI batch code. And, one of the hackfixs you committed in 46414 is around this code: for (; GdiBatchCount > 0; GdiBatchCount--) { ULONG Size; // Process Gdi Batch! Size = GdiFlushUserBatch(pDC, (PGDIBATCHHDR) pHdr); if (!Size) break; pHdr += Size; } You "protected" pHdr pointer dereference inside GdiFlushUserBatch() by wrapping it into SEH. Now let's call Captain Obvious again to help and think, what is more probable: Mysterious TEB invalidation, or GdiBatchCount not matching the size of pHdr array? So that the reading goes beyond the buffer and certainly faults (and you hack-catch this fault in SEH to pretend you caught the mysterious kernel bug). I suspect the latter, because it might be anything - race condition, a bug in the code, a buffer overflow, uninitialized variable access, or you're trying to flush the batch queue of an already dead thread.
Both broken fonts and the massive gdi object leak in Acrobat reader and other apps and probably a bazillion of other bugs were caused by broken pointer arithmetics in gdi32 batch code. ZWabbit knows what I mean. And I would also suspect it to be at fault when "the teb is missing", The code doesn't protect against malicious values in the Size field of the headers and when you use the upper half of a handle instead of the size value ...
I'm fixing it. But after fixing the gdi object leak, Acrobat reader doesn't die a painful death due to too many objects, but some objects seem to be missing, causing broken rendering. Hiding a bug with another bug. Ironic, isn't it?
Regards, Timo