WowAce

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.

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.

@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.

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.