Strange issue since 5.4.1

Clamsoda · 11-18-13, 06:26 AM

Good morning,

I have been getting a strange issue since 5.4.1, where I receive an "Interface action failed because of AddOn" error when I join a party while in combat.

I would like to stress that this issue did NOT occur before 5.4.1, and is not related to -- as far as I can tell -- trying to manipulate the secure frames via SetSize, SetScale, etc.

Here is the error:

Code:

1x [ADDON_ACTION_BLOCKED] AddOn "oUF_Clamsoda" tried to call the protected function "UNKNOWN()".
!BugGrabber-r198-release\BugGrabber.lua:552: in function <!BugGrabber\BugGrabber.lua:552>
<in C code>
<in C code>
FrameXML\SecureGroupHeaders.lua:164: in function <FrameXML\SecureGroupHeaders.lua:123>
FrameXML\SecureGroupHeaders.lua:488: in function <FrameXML\SecureGroupHeaders.lua:387>
<in C code>
FrameXML\SecureStateDriver.lua:100: in function <FrameXML\SecureStateDriver.lua:95>
FrameXML\SecureStateDriver.lua:127: in function <FrameXML\SecureStateDriver.lua:119>

Locals:
nil

The error report is pretty useless to me, but I was able to get the error to stop by -- strangely -- getting rid of my SetPoint call on the SpawnHeader. I tried moving the SetPoint call into the oUF-initialConfigFunction with no success.

All that being said, I don't quite understand what is going wrong. I will post all 3 relevant files if it is any use to anyone. They are listed in the order they are called by the toc.

config.lua
functions.lua
units/party.lua

Line 112 of party.lua is what is causing the error, but I can't really get rid of my header's SetPoint call, which is why I am so lost.

As a note, the SetSize and SetScale functions inside of AddonTable:SharedProperties does NOT affect my header units.

Rainrider · 11-20-13, 11:51 AM

I believe you are supposed to spawn your frames from within oUF:Factory. Something like that:

lua Code:

oUF:RegisterStyle("oUF_ClamsodaParty", PartyStyle)
 
oUF:Factory(function(self)
        self:SetActiveStyle("oUF_ClamsodaParty")
 
        local party = oUF:SpawnHeader("oUF_ClamsodaParty", nil, customVisibility,
                "oUF-initialConfigFunction", initialConfigFunction,
                "template",             "oUF_ClamsodaPartyPets",
                "showParty",            true,
                "columnAnchorPoint",    "BOTTOM",
                "point",                "BOTTOM",
                "yOffset",              41
        )
 
        -- Why doesn't this anchor perfectly?
        party:SetPoint("BOTTOMRIGHT", oUF_ClamsodaPlayer, "BOTTOMLEFT", -16, 0)
end)

Rainrider · 11-20-13, 01:38 PM

You could disregard my previous answer. oUF:Factory should be actually optional.

Could you post your entire code? Especially oUF_ClamsodaPartyPets.

Clamsoda · 11-20-13, 02:54 PM

Thank you for the interest Rainrider. I was going to say, isn't oUF Factory optional? Anyways, oUF_ClamsodaPartyPets is the name of my XML template used for spawning pets with their owner in a party. The code I used is taken from oUF's sample code.

oUF_Clamsoda.xml

Like I said, getting rid of the SetPoint call on the SpawnHeader(line 112 of units/party.lua) completely gets rid of the error. Not to mention, this error was not occurring pre 5.4.1.

I guess there isn't much more I can do than link the entire AddOn. Feel free to go through all of it =X.

Rainrider · 11-20-13, 08:35 PM

That you didn't get an error pre 5.4.1 could mean you hadn't encountered it yet. How do you reproduce the error btw?

The error you get would mean something is not right with your template or the attributes you set to the header. The template itself seems ok to me. So, it's kind of a wild guess but could it be something with the way you scale your frames?

Install oUF_MovableFrames and type "/omf" in-game. It seems the scale don't apply to your party header. Further the partypet frame just disappears. Set AddonTable.Config.scale to 1 or a value below 1 and look what happens after typing "/omf". You could move the frames around and then type "/omf x" to see what is the actual scale applied. I can't tell why it is like that though

zork · 11-21-13, 02:06 AM

I have some questions:

Does the error appear out of combat or in combat only? Taints are combat only. But they may appear once you entered combat after you did sth.
Have you tested it by actually being in a party or have you spawned the group header with solo being enabled?
Have you tested changing the SetPoint to UIParent or a secure drag frame?
Have you tested the issue with every other addon disabled only oUF and your unitframes running?

Gonna test it on the PTR aswell. Maybe it has sth to do with the parented frame, but actually I doubt that. My group is added to a frame that has UserPlaced enabled. Maybe those frames have special conditions.

Lua Code:

local attr = {
  visibility          = "custom [group:party,nogroup:raid] show;hide",  --show this header in party
  showPlayer          = true,     --make this true to show player in party
  showSolo            = false,    --make this true to show while solo (only works if solo is in visiblity aswell
  showParty           = true,     --make this true to show headerin party
  showRaid            = false,    --show in raid
  point               = "LEFT",
}
 
local pos = { a1 = "TOPLEFT", a2 = "TOPLEFT", af = "UIParent", x = 5, y = -77 },
 
local partyDragFrame = CreateFrame("Frame", "oUF_DiabloPartyDragFrame", UIParent)
partyDragFrame:SetSize(50,50)
partyDragFrame:SetPoint(pos.a1,pos.af,a2,pos.x,pos.y)
partyDragFrame:SetMovable(true)
partyDragFrame:SetUserPlaced(true)
 
local party = oUF:SpawnHeader(
  "oUF_DiabloPartyHeader",
  nil,
  attr.visibility,
  "showPlayer",         attr.showPlayer,
  "showSolo",           attr.showSolo,
  "showParty",          attr.showParty,
  "showRaid",           attr.showRaid,
  "point",              attr.point,
  "oUF-initialConfigFunction", ([[
    self:SetWidth(%d)
    self:SetHeight(%d)
    self:SetScale(%f)
  ]]):format(128, 64, 0.82)
)
party:SetPoint("TOPLEFT",partyDragFrame,0,0)

Basically what I would do to evaluate the bug is to comment out most of the spawn code. Make it as basic as possible. Check for the error. If the error is gone work from that point forward until you found it.

Phanx · 11-21-13, 04:02 AM

Out of curiosity, why bother with format here:

Code:

([[
    self:SetWidth(%d)
    self:SetHeight(%d)
    self:SetScale(%f)
  ]]):format(128, 64, 0.82)

?

zork · 11-21-13, 04:35 AM

Because I use references to my config table in the real code. I replaced them in the snippet.

Clamsoda · 11-21-13, 05:53 AM

@Rainrider: Reproducing the error is as simple as entering combat, then creating/joining a party.

The error only occurs when I am NOT in a party, and invite someone/get invited to one while I am in combat. Subsequent invites to the party cause no harm.

I've tested every bit of the party code, and I go nowhere until the last thing I tried was just getting rid of the SetPoint call on my SpawnHeader, just to be thorough. It got rid of the error, but I can't really leave my SpawnHeader unplaced.

I tried changing the SetPoint parent to UIParent, with no effect.

I've stripped the AddOn down as far as possible, and it goes without saying: I test these issues with just oUF, and my layout enabled.

Does anyone have a clue why the error report is so generic? The protected function called is UNKNOWN()...

@Phanx: Allows me to use some config values later down the line; I believe they are hardcoded at the moment, but I am the only one that uses the layout so it doesn't affect me much. I do use format() instead of :format() to make up a little overhead.

zork · 11-21-13, 06:54 AM

Actually that makes sense. SetPoint on a secure frame from unsecure environment will catch you a taint in combat. So spawning a party frame in combat will call the SetPoint and get you the error.

But...what is actually disturbing is that the error happens at all. By the time you enter a party the setpoint call on the group header is long time gone. That one is parsed directly on loadup even before PLAYER_LOGIN fired. (At least it should).

A workaround:

Lua Code:

if not InCombatLockdown() then
  party:SetPoint(...)
else
  party:RegisterEvent("PLAYER_REGEN_ENABLED")
  party:HookScript("OnEvent", function(self,event)
    if not InCombatLockdown() and event == "PLAYER_REGEN_ENABLED" then
      party:SetPoint(...)
      party:UnregisterEvent("PLAYER_REGEN_ENABLED")
    end
  end)
end

If that still fails you are calling SetPoint on the group header at a later point (while being in combat). Sounds wierd.

Clamsoda · 11-21-13, 07:23 AM

Yay, you read my mind Zork! That is what has been driving me insane about the entire situation. The header exists before I am even in game, and this didn't happen in 5.4.0. I already tried forcing the SetPoint call on SpawnHeader at PLAYER_LOGIN on a previous round of testing, and it didn't make a difference.

Also, can ANYONE shed ANY light on why the trace cites UNKNOWN() as the protected function that is trying to be called?

What a mess >.<

zork · 11-21-13, 07:27 AM

Btw I googled the error and some other addons had it prior to 5.4.1.
Out of curiosity...backup your WTF folder, get rid of it and try again. Basically use the base WoW installation. Maybe some config file is ****ed up.
Plus...disable BugGrabber. Only use /console taintlog 1. Limit the error sources.

Clamsoda · 11-21-13, 07:33 AM

I just tested with a 100% fresh WTF, and the only two AddOns running were oUF and oUF_Clamsoda. The error did NOT go away.

Also, this doesn't get written to that taint log, it is just an ingame error.

Edit: Uhm...I got the error when I tried it with a fresh WTF, and I was able to reproduce this hundreds of times in testing, but after logging in from THAT test, I can't get it to happen anymore. What the fuc******************************. *smashes face into desk*

zork · 11-21-13, 07:41 AM

Wierd problems need wierd solutions.

Clamsoda · 11-21-13, 07:53 AM

Yeah I friggn' guess...

Thanks everyone for the interest and help. I'll keep you guys updated if I make any headway on what the cause was (or still is?).

zork · 11-21-13, 08:01 AM

Well you could compare WTF folder files. Maybe you had the party frame header name in the layout-local.txt file or in any other wtf file. Maybe you have used "oUF_ClamsodaParty" somewhere else by error thus making it not unique.

Plus you are using your own party template and not the default "SecureGroupHeaderTemplate" template. Maybe mixing the default party header and party pet header is bad.

Clamsoda · 11-21-13, 08:15 AM

I am just following the example code in oUF's XML file. That's the prescribed method -- by Haste -- for spawning party pets as a child frame of their owner. If what I am doing is wrong in that regard, then that code needs to be removed from oUF's XML file.

Rainrider · 11-21-13, 07:53 PM

@zork

His template inherits from SecureGroupHeaderTemplate, he just loses Clique support as the template attribute gets overwritten at https://github.com/haste/oUF/blob/ma....lua#L505-L510, which I'm not quite sure about, as useparent-unit should imply that the attributes from the parent are used (that's the party header). So could it be then, that he lacks the inheritance from SecureHandlerEnterLeaveTemplate and it then bugs out because of the _onenter and _onleave attributes? I actually know nothing about secure buttons and the whole stuff, so don't quote me on that.

I was also able to reproduce the error on my installation so I don't know about the wft stuff. He uses "oUF_ClamsodaParty" as the name of the style too, but that is not a global.

Clamsoda · 11-21-13, 09:03 PM

It honestly may be related to some of the changes in 5.4.1 what with the IsDisabledByParentalControl() taint stuff; and the explanation for similar errors being reported by others pre 5.4.1 could be any other amount of taint issues.

We'll see what crops up. It 100% has NO effect on my UI...just hate to see an error.

zork · 11-22-13, 01:39 AM

I would not bother with BugGrabber anyway. The default Lua errors messages are just fine. Everything else can be catched by /console taintlog 1.