Help: Frame:SetBackdrop() "crashes" WoW
i have code like the following:
Code:
local SML = LibStub("LibSharedMedia-3.0") however, if uncomment the "edgeSize" element of backdropTable, everything looks great... but the WoW Client experiences intermittent hard crashes, when any nameplates are visible. virtually always this will be with an error code of "132" (the (in)famous "#132 crash"). very occasionally (maybe one crash out of 20+), it will crash without any error code whatsoever (the WoW client will just disappear without warning). i can go hours without a crash, or i can crash within a few seconds of entering the game world. the invariant is that nameplates have to be visible. i think i have narrowed this issue down very tightly, to the "single line of code" that seems to induce the problem: specifying any sort of edgeSize along with any sort of edgeFile (i.e. even an edgeSize of 0 seems to cause the problem). specifying any edgeSize with a edgeFile of "nil" seems to make the problem go away. specifying an edgeFile with no edgeSize seems to make the problem go away. specifying (or not) other pieces of backdropTable (like tile and tileSize) has no effect on the problem. this problem started specifically with WoW 3.3.3, when Texture:SetTexCoordModifiesRect() was removed. regardless of the ultimate cause (Blizzard bug, or whatever), i am really just interested in a workaround (if any). but at this point i am stumped. the only thing i can think of to do is disable borders entirely. if anyone has any ideas, or even just wild guesses, i would be very happy to hear them :). |
What are the details of the texture used? I had a crash problem with a 8x8 texture, but with a 64x64 texture it was fixed.
|
edit: had some MPQs already unpacked. the default tooltip border is 128x16 BLP, and the gold and silver dialog borders are 256x32 BLP. i am desperate enough to try converting my TGAs into BLPs, and changing the resolution to 256x32, but i don't have a lot of confidence that any of that will affect this problem :).
Quote:
one of the edge files i use is the SharedMedia "Roth Square" border (a 128x16 TGA; filename "roth.tga"). the other edge file i use is distributed with Skinner (also a 128x16 TGA; filename "krsnik.tga"). i would have to rummage the MPQs for Blizzard artwork (though i expect they are the same: 128x16, either TGA or BLP). (aside: edge files are normal WoW texture files that must be 8x wider than they are high; described here). these TGA files appear to be perfectly well formed (as "edge files"). and the artwork itself functions properly... right up until WoW crashes. finally, both of these TGA files "worked" perfectly for many months (years?) before WoW 3.3.3 arrived. |
What happens if you use :SetBackdrop() "normally"? (ie, you put the table right in the function instead of passing a variable - same with the file paths)
|
this code resulted in a #132 crash:
Code:
backdropFrame:SetBackdrop( { insets = { left = inset, right = inset, top = inset, bottom = inset, }, edgeFile = edgeFile, edgeSize = 16, bgFile = texture, } ) Code:
backdropFrame:SetBackdrop( { insets = { left = inset, right = inset, top = inset, bottom = inset, }, edgeFile = edgeFile, bgFile = texture, } ) Quote:
i will try that, and update when i have some findings. |
Quote:
|
edit, this code crashes (looks correct graphically, but eventually crashes):
Code:
frame:SetBackdrop( { insets = { left = 4, right = 4, top = 4, bottom = 4, }, Quote:
|
hmm, i also try to clear nameplate borders when nameplates are hidden (due to unit death or range). "de-initialization". i am going to disable all of that code, just to make sure... and then repeat some of this testing. would be funny (and par for the course) for me to be barking up the wrong tree all this time.
if that fails, i will "hardcode" both ends (initialization and de-initialization), as Seerah/Shadowed have suggested, and proceed from there. |
Quote:
The reason for asking you to try the straight path is just narrowing down what could be causing it. It's a lot easier to post something in the UI forums about X bug if you've eliminated most of the causes and can give a quick test case. Quote:
|
at this point, it is looking increasingly as if my "reset the border on nameplate hide" functionality (aka "de-initialization", trying to disable border graphics on a nameplate as the WoW client recycles it, so that when it is used again it does not have a border) is what is/was causing this problem.
i put all the original border control code back in (i.e. the code we were fiddling with in this thread), but left the "de-initialization" code disabled, and i have not been able to produce a crash under any circumstances. so it appears that changing the backdropTable on elements associated with a nameplate that is in the process of being hidden is a "no-no". however, it appears i can safely set the border color to something with 0 (zero) alpha while the nameplate is being hidden (which should have the same basic effect). all the other symptoms related to nameplate initialization (using edgeSize and etc) definitely interacted with the problem, and unfortunately Aloft is indeed able to crash the WoW client intermittently by engaging in some/all of these things, but i think the workaround is not to reset the backdropTable on a nameplate that is in the process of being hidden. (like the old Henny Youngman joke about the man who goes to the doctor.) anyway, thanks very much to all who contributed. it was all worth doing. if the problem crops up again, i will pick up where your suggestions left off :). |
To clarify, you are doing this to replicate:
1) Setting any sort of edgeSize with a texture 2) Remove the backdrop OnHide 3) Wait and the game will crash? |
Quote:
as it turns out, there are a few things that i can do (in the game) that seem to exercise the problem more quickly (so that i don't have to wait as long for the game to crash). examples: opening the "Nerub'ar Victim" cocoons just outside of Warsong Hold (which drops one nameplate and raises another in rapid succession), or doing an Auctioneer "getall" and then panning the camera around the AH continuously while it runs. i am guessing this sort of thing induces a rapid sort of OnHide/OnShow workflow within the client that is particularly favorable to exercising this problem. anyway, i did a total of a couple of hours worth of these things late last night and today (after returning to setting an edgeSize, more in line with my "original" OnShow backdrop processing... and after disabling the OnHide backdrop processing), and i did not see a crash. before this, usually it was a matter of minutes (sometimes mere seconds) before i saw a crash. so, i can't "prove" that disabling the OnHide backdrop processing constitutes a workaround, but at the moment it looks like things are much more stable. i will continue testing, of course... and i promise to come whinging back here if the crashes resume :). once i have done some more testing, and my confidence in this specific workaround grows, i will also go provide a summary of this on the Blizzard support forums. |
quick update: one of my users found a WoWWiki "guide" on #132 errors, which is here.
now armed with some notion of how to analyze these crash dumps, and looking at my backlog of crashes, i can verify that all of Aloft's crashes did indeed occur down in Frame:SetBackdrop(). looking at other addon-related causes for crashes, there were even more caused by Frame:SetBackdrop(), attributed to Ace3. these errors come in a couple of different forms (based on stack traces, one form is attributed to C:\Windows\syswow64\kernel32.dll and the other attributed to C:\Windows\SysWOW64\ntdll.dll... both driven by Frame:SetBackdrop()). seems 64-bit-related to me, and they seem to occur with very similar stack traces, when they occur. indeed, i am running Windows Vista 64 "Ultimate" SP2. i will update further if i discover anything more that can "meaningfully" characterize this problem. |
All times are GMT -6. The time now is 09:02 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI