Ouro Loot

1 - Permanently locks up WoW when accessing the ML/EQ-DKP tab

What steps will reproduce the problem?

1. Have this record approximately two to three months of raids and loot drops. Using BigWigs instead of its supported DBM and Full Tracking always enabled when its on.

2. Bring up its frame, click the different tabs. Finally click the ML/EQ-DKP tab.

What is the expected output? What do you see instead?

Expected: for it to display within a reasonable period of time (less than three seconds) the data it outputs to that tab.

Instead: with about two months of raids recorded and not in a raid doing the above (with it "off"), got a stack overflow error (see below). In two different examples, with about three months of raids recorded doing the above, WoW froze. Permanently until I hard-killed it. Both times out of combat, latest time yesterday in a raid while it was turned on, earlier solo with it "off".

What version of the product are you using?

r18 during the two perma-freezes. Around v2r15p2-beta or so (I don't remember exactly) during the stack overflow.

Do you have an error log of what happened?

["message"] = {
				"C stack overflow:\n<in C code>: in function `SetVerticalScroll'\n<string>:\"*:OnValueChanged\":1: in function <[string \"*:OnValueChanged\"]:1>\n<in C code>: in function `SetValue'\n<string>:\"*:OnVerticalScroll\":2: in function <[string \"*:OnVerticalScroll\"]:1>\n<in C code>: ?\n<in C code>: in function `SetVerticalScroll'\n<string>:\"*:OnValueChanged\":1: in function <[string \"*:OnValueChanged\"]:1>\n<in C code>: in function `SetValue'\n<string>:\"*:OnVerticalScroll\":2: in function <[string \"*:OnVerticalScroll\"]:1>\n<in C code>: ?\n<in C code>: in function `SetVerticalScroll'\n<string>:\"*:OnValueChanged\":1: in function <[string \"*:OnValueChanged\"]:1>\n...:\n<in C code>: in function `SetValue'\n<string>:\"*:OnVerticalScroll\":2: in function <[string \"*:OnVerticalScroll\"]:1>\n<in C code>: ?\n<in C code>: in function `SetVerticalScroll'\n<string>:\"*:OnValueChanged\":1: in function <[string \"*:OnValueChanged\"]:1>\n<in C code>: in function `SetValue'\n<string>:\"*:OnVerticalScroll\":2: in function <[stri", -- [1]
				"ng \"*:OnVerticalScroll\"]:1>\n<in C code>: ?\n<in C code>: in function `SetVerticalScroll'\n<string>:\"*:OnValueChanged\":1: in function <[string \"*:OnValueChanged\"]:1>\n", -- [2]
			},
			["type"] = "error",
			["locals"] = "(*temporary) = MultiLineEditBox1ScrollFrame {\n ScrollBar = MultiLineEditBox1ScrollFrameScrollBar {\n }\n 0 = <userdata>\n offset = 0\n obj = <table> {\n }\n}\n(*temporary) = 11458.90625\n(*temporary) = 11458.906079249\n(*temporary) = <function> defined =[C]:-1\n(*temporary) = <function> defined =[C]:-1\n(*temporary) = MultiLineEditBox1ScrollFrame {\n ScrollBar = MultiLineEditBox1ScrollFrameScrollBar {\n }\n 0 = <userdata>\n offset = 0\n obj = <table> {\n }\n}\n(*temporary) = 11458.906079249\n",
			["session"] = 3413,
			["counter"] = 2,
		}, -- [842]

Please provide any additional information below.

Been using both this and HeadCount2 for raid recording after finally getting rid of my last Ace2 mod: NRT. But such perma-freezes are unacceptable behavior, so have disabled Ouro Loot for good until this can be fixed.

Can't always remember in a raid situation not to touch something in a mod or it will cause you to lose everything since you started the session. As well as causing the rest of the raid to sit on their hands until you get back.

Hope you can fix it.

User When Change
Farmbuyer Nov 14, 2014 at 02:38 UTC Changed priority from Medium to Low
Farmbuyer Aug 25, 2011 at 07:40 UTC
Zidomo Aug 22, 2011 at 03:59 UTC Changed description:
  What version of the product are you using?

- r18 during the perma-freeze. Around v2r15p2-beta or so (I don't remember exactly) during the stack overflow.
+ r18 during the two perma-freezes. Around v2r15p2-beta or so (I don't remember exactly) during the stack overflow.
  Do you have an error log of what happened?
Zidomo Aug 22, 2011 at 03:55 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • 3 comments
  • Avatar of Farmbuyer Farmbuyer Aug 25, 2011 at 20:41 UTC - 0 likes

    Yeah, I've been thinking of adding a threshold that triggers a warning. Once a certain number of rows in the (input) loot tab is reached, the user is warned that he needs to click the MLEQDKP tab to generate output soon, and then clear the input.

    Originally, I wanted to make the various text output tabs each have an enable/disable toggle. In that situation, the warnings and limits and whatnot wouldn't even happen if the MLEQDKP tab was turned off.

  • Avatar of Zidomo Zidomo Aug 25, 2011 at 20:29 UTC - 0 likes

    @Farmbuyer: Go

    That's fine, if a design doesn't meet up with usage expectations, no problem. Haven't seen another raid tracker (including the ancient NRT) with such an issue, but again, no problem.

    But if such a limitation causes a hard WoW lockup on access to the tab with many stored raids, its still a blocker design defect. Perhaps disable the tab once stored raids go over a certain threshold? 2 weeks+ or whatever is the breakpoint for locking up on average. Or else automatically delete data shown through that tab (but not elsewhere) at the breakpoint.

  • Avatar of Farmbuyer Farmbuyer Aug 25, 2011 at 07:59 UTC - 0 likes

    I doubt that will get fixed soon. The XML generator does some recursion (being XML, it can't just append stuff to the end), and to be honest, it's just not designed to handle months' worth of loot all at once.

    The goal of the addon was always to generate text for an evening of raiding, maybe a week at a time, in order to post it somewhere within a relevant timeframe. You might consider generating text in smaller batches, and then either storing them in the addon (the "saved texts") or copying the texts out to a file somewhere.

    I've never been happy with the current XML generator; it was done like that for ease of implementation. I'll probably go back and redo it (even a couple dozen loot entries creates a noticeable hiccup when clicking that tab) but it's not going to be a priority for a while.

  • 3 comments

Facts

Last updated
Nov 14, 2014
Reported
Aug 22, 2011
Status
Accepted - Problem reproduced / Need acknowledged.
Type
Defect - A shortcoming, fault, or imperfection
Priority
Low - Might slip to a later milestone.
Votes
0

Reported by

Possible assignees