!BugGrabber

41 - Very unexpected bug capturing behavior in latest alphas

What steps will reproduce the problem?

1. Have a single mod (in WoW 4.3 here) throw up a bug at logon. Have !BugGrabber catch it.

2. Reload the UI so that that particular mod bugs out at logon again.

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

Expected: for !BugGrabber to record bugs captured in different sessions to be recorded as separate bugs, if there is any difference at all between them. As !BugGrabber did up to r172.

Also, for bugs in the same session with identical "Message"s, but different "Local"s and/or "Stack"s, to be recorded as different bugs

Instead: bugs of the same type in the same mod (i.e. with the same "Message") that repeat in the next session are oddly added to the counter of the last session's bug with the same Message, instead of being recorded separately. Even if the Locals & Stack change between the sessions.

As well, bugs in the same mod in the same session with identical Messages, but different Locals & Stacks are also slapped on to the first incident's counter.

What version of the product are you using?

r181

Do you have an error log of what happened?

No errors.

Please provide any additional information below.

Have for the longest time been using the last-version-before-rewrite r172 with BugSack r247. Decided that WoW 4.3 live was as good a time as any to permanently move to the rewritten versions. Unfortunately after testing, its not happening here and I'm sure for others who are not fans of the new behavior.

For the issue above, the last version of NeonChat is bugged. At logon, instead of the bugs it throws be recorded as three separate ones (with !BugGrabber r172), it records it as one. When you relog, the error reappears, but with a higher counter. The Stack (& Local) doesn't change at all; it still has the same data from the previous session. Even if, say, a mod that was originally recorded in the Stack area you turned off before the next relog. Or other data is different (other than the Message).

I did thorough testing with r172/BugSack r247, then the current r181/BugSack r255 to see this.

This behavior puts a major crimp in usability. When either posting errors for authors or trying to debug the issue yourself, having errors in a mod that repeat but are not 100% similar & are not recorded with any difference between them makes debugging potentially a lot more hassle than it used to be with r172.

I can understand not wanting to increase SV space with similar errors. But when there are differences in the stacks/locals that are useful for debugging, this saving of space wastes a lot of debugging time.

User When Change
funkydude Oct 21, 2013 at 12:07 UTC Changed status from Accepted to Invalid
Rabbit Dec 07, 2011 at 02:58 UTC
Zidomo Dec 05, 2011 at 13:36 UTC Changed description:
  Please provide any additional information below.

- Have for the longest time been using the last-version-before-rewrite r172 with BugSack r247. Decided that WoW 4.3 live was as good a time as any to permanently move to the rewritten versions.
+ Have for the longest time been using the last-version-before-rewrite r172 with BugSack r247. Decided that WoW 4.3 live was as good a time as any to permanently move to the rewritten versions. Unfortunately after testing, its not happening here and I'm sure for others who are not fans of the new behavior.
  For the issue above, the last version of [[http://www.wowinterface.com/downloads/fileinfo.php?id=7838|NeonChat]] is bugged. At logon, instead of the bugs it throws be recorded as three separate ones (with !BugGrabber r172), it records it as one. When you relog, the error reappears, but with a higher counter. The //Stack// (& //Local//) doesn't change at all; it still has the same data from the previous session. Even if, say, a mod that was originally recorded in the //Stack// area you turned off before the next relog. Or other data is different (other than the //Message//).
Zidomo Dec 05, 2011 at 13:34 UTC
Zidomo Dec 05, 2011 at 13:33 UTC Changed description:
  Have for the longest time been using the last-version-before-rewrite r172 with BugSack r247. Decided that WoW 4.3 live was as good a time as any to permanently move to the rewritten versions.

- For the issue above, the last version of [[http://www.wowinterface.com/downloads/fileinfo.php?id=7838|NeonChat]] is bugged. At logon, instead of the bugs it throws be recorded as three separate ones (with the current !BugGrabber versions), it records it as one. When you relog, the error reappears, but with a higher counter. The Stack (& Local) doesn't change at all; it still has the same data from the previous session. Even if, say, a mod that was originally recorded in the Stack area you turned off before the next relog. Or other data is different (other than the Message).
+ For the issue above, the last version of [[http://www.wowinterface.com/downloads/fileinfo.php?id=7838|NeonChat]] is bugged. At logon, instead of the bugs it throws be recorded as three separate ones (with !BugGrabber r172), it records it as one. When you relog, the error reappears, but with a higher counter. The //Stack// (& //Local//) doesn't change at all; it still has the same data from the previous session. Even if, say, a mod that was originally recorded in the //Stack// area you turned off before the next relog. Or other data is different (other than the //Message//).
- I did thorough testing with r172/BugSack r247, then r181/BugSack r255 to see this.
+ I did thorough testing with r172/BugSack r247, then the current r181/BugSack r255 to see this.
  This behavior puts a major crimp in usability. When either posting errors for authors or trying to debug the issue yourself, having errors in a mod that repeat but are not 100% similar & are not recorded with any difference between them makes debugging potentially a lot more hassle than it used to be with r172.
- I can understand not wanting to increase SV space with similar errors. But when there are differences in the stacks/locals that are useful for debugging, this saving of space wastes time.
+ I can understand not wanting to increase SV space with similar errors. But when there are differences in the stacks/locals that are useful for debugging, this saving of space wastes a lot of debugging time.
Zidomo Nov 30, 2011 at 19:31 UTC Changed description:
  Have for the longest time been using the last-version-before-rewrite r172 with BugSack r247. Decided that WoW 4.3 live was as good a time as any to permanently move to the rewritten versions.

- For the issue above, the last version of [[http://www.wowinterface.com/downloads/fileinfo.php?id=7838|NeonChat]] is bugged. At logon, instead of the bugs it throws be recorded as three separate ones (with the current !BugGrabber versions), it records it as one. When relog, the error reappears, but with a higher counter. The Stack (& Local) doesn't change at all; it still has the same data from the previous session. Even if, say, a mod that was originally recorded in the Stack area you turned off before the next relog. Or other data is different (other than the Message).
+ For the issue above, the last version of [[http://www.wowinterface.com/downloads/fileinfo.php?id=7838|NeonChat]] is bugged. At logon, instead of the bugs it throws be recorded as three separate ones (with the current !BugGrabber versions), it records it as one. When you relog, the error reappears, but with a higher counter. The Stack (& Local) doesn't change at all; it still has the same data from the previous session. Even if, say, a mod that was originally recorded in the Stack area you turned off before the next relog. Or other data is different (other than the Message).
  I did thorough testing with r172/BugSack r247, then r181/BugSack r255 to see this.
Zidomo Nov 30, 2011 at 19:30 UTC
Zidomo Nov 30, 2011 at 19:21 UTC Create

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

  • 3 comments
  • Avatar of Archarodim Archarodim Mar 04, 2012 at 15:36 UTC - 0 likes

    I agree on separating bugs from different sessions.

    However I don't see the point in creating a separate log when the stack or local change.

    Usually when you have a repeating error, the original problem stays the same. What happens after the first occurrence is just pure nonsense, the original error is always the most useful to fix the problem. The counter is also a valuable information, an information that will be lost if an error is treated as a new one if the locals or stack aren't exactly the same.

    Moreover, in some conditions the stack and locals may be slightly different between each occurrence of a repeating error, in that case you might end up with 500 separate records for the same error.

  • Avatar of Rabbit Rabbit Mar 04, 2012 at 01:13 UTC - 0 likes

    Please read the entire message, as it gets more positive at the end :P

    What you have to realise is that the locals table was thrown on by sylvanaar or some random person, it's not something I really care about at all.

    You know I've worked with many high-profile addons since vanilla, and I must say that even after he added the locals to the bugsack details, I've never even LOOKED at them while investigating a bug in other addons. I can always see what the issue is from the error message and stack.

    I have to say here, Zidomo, that perhaps it's time you start contributing code directly - after all, all my projects are open source. I don't care enough about the locals to put any effort in.

    I DO, however, care about the code - so if you want to contribute then I would gladly help you out and review changes and help you understand the codebase. Education is always a noble and worthwhile goal, and I would gladly spend my time on that.

  • Avatar of Zidomo Zidomo Dec 05, 2011 at 13:34 UTC - 0 likes

    Changed back type to a Defect as it is in fact "A shortcoming...".

  • 3 comments

Facts

Last updated
Oct 21, 2013
Reported
Nov 30, 2011
Status
Invalid - This was not a valid report.
Type
Defect - A shortcoming, fault, or imperfection
Priority
Medium - Normal priority.
Votes
1

Reported by

Possible assignees