Disable Grouping by Similar Errors?

Mike Ho's Avatar

Mike Ho

27 Jun, 2011 11:26 PM

Is there a way we can disable the grouping of "Similar Errors" into a single issue, and actually just list all unresolved issues on the dashboard?

We are finding that the grouping of similar issues is not working very accurately (it often times will group as "similar issues" errors that are completely different, and it will sometimes NOT group similar issues which are truly similar issues).

Plus, given our workflow of bug fixing, it'd actually be a lot easier of we can just deal with each issue individually and let our own team determine which ones are dupes and can be closed, etc.

Thanks!

  1. 2 Posted by Harold Gimenez on 28 Jun, 2011 02:01 AM

    Harold Gimenez's Avatar

    Hi Mike,

    There is no way to disable grouping of similar errors.

    It would be helpful to us to know what errors you believe are completely different, and which should've been grouped and didn't. Errors are currently considered unique if all of the following are equal: the error class, the last file and line number in the backtrace, the controller and action, and the server environment name.

    Thanks,
    -Harold

  2. 3 Posted by Mike Ho on 28 Jun, 2011 03:58 AM

    Mike Ho's Avatar

    Ah... so that might be the source of the issue then. How are you determining "last file and line number" in the backtrace?

    In iOS apps, the backtrace that is being saved is actually in reverse order, so the top-most function call on the call stack is actually the first line of the backtrace. And actually, given that all iOS apps are spun-up from the same one-line of code in main(), the bottom-most function call on the call stack (and the very last line of the backtrace) is always the same.

    Could this be one of the reasons we are seeing inconsistent grouping results?

  3. 4 Posted by Mike Ho on 28 Jun, 2011 04:07 AM

    Mike Ho's Avatar

    Actually... another note: sometimes, the top-most call in the stack trace is actually a framework-level call (e.g. something within the iOS SDK itself)... but the "bug" is actually from our user code making the call to the iOS SDK.

    So for example, this backtrace:

    CoreFoundation:0:in '0x319de63d __exceptionPreprocess + 96' libobjc.A.dylib:1:in '0x31d83c5d objc_exception_throw + 24' CoreFoundation:2:in '0x319e21bf -[NSObject(NSObject) doesNotRecognizeSelector:] + 102' CoreFoundation:3:in '0x319e1649 ___forwarding___ + 508' CoreFoundation:4:in '0x31958180 _CF_forwarding_prep_0 + 48' VeriFacts:5:in 'iVQ 0x00042cc9 VeriFacts iVQ + 269513' VeriFacts:6:in 'iVQ 0x00043433 VeriFacts iVQ + 271411' VeriFacts:7:in 'iVQ 0x000426ab VeriFacts iVQ + 267947' VeriFacts:8:in 'iVQ 0x00040d4d VeriFacts iVQ + 261453' UIKit:9:in '0x35b5a389 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 260' UIKit:10:in '0x35bbe0eb -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 130' Foundation:11:in '0x354be6d5 __NSFireDelayedPerform + 368' CoreFoundation:12:in '0x319b5a47 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14' CoreFoundation:13:in '0x319b7ecb __CFRunLoopDoTimer + 850' CoreFoundation:14:in '0x319b8845 __CFRunLoopRun + 1088' CoreFoundation:15:in '0x31948ec3 CFRunLoopRunSpecific + 230' CoreFoundation:16:in '0x31948dcb CFRunLoopRunInMode + 58' GraphicsServices:17:in '0x3559741f GSEventRunModal + 114' GraphicsServices:18:in '0x355974cb GSEventRun + 62' UIKit:19:in '0x35b34d69 -[UIApplication _run] + 404' UIKit:20:in '0x35b32807 UIApplicationMain + 670' VeriFacts:21:in 'iVQ 0x00062991 VeriFacts iVQ + 399761' VeriFacts:22:in 'iVQ 0x000027cc VeriFacts iVQ + 6092'

    is actually being set as being "similar" to an error with the following backtrace:

    CoreFoundation:0:in '0x344aaec1 __exceptionPreprocess + 96' libobjc.A.dylib:1:in '0x33975811 objc_exception_throw + 24' CoreFoundation:2:in '0x344aad15 +[NSException raise:format:arguments:] + 68' CoreFoundation:3:in '0x344aad4f +[NSException raise:format:] + 34' Foundation:4:in '0x3325b8b3 -[NSPlaceholderString initWithString:] + 78' Foundation:5:in '0x332740c3 +[NSString stringWithString:] + 30' VeriFacts:6:in 'iVQ 0x0005e315 0x0 + 385813' CoreFoundation:7:in '0x34452719 -[NSObject(NSObject) performSelector:withObject:withObject:] + 24' UIKit:8:in '0x31bd9fa7 -[UIApplication sendAction:fromSender:toTarget:forEvent:] + 82' UIKit:9:in '0x31c03c07 -[UIControl(Deprecated) sendAction:toTarget:forEvent:] + 34' UIKit:10:in '0x31b77937 -[UIControl(Internal) _sendActionsForEventMask:withEvent:] + 358' UIKit:11:in '0x31b8815f -[UITextField willDetachFieldEditor:] + 86' UIKit:12:in '0x31b764b3 -[UIFieldEditor becomeFieldEditorForView:] + 126' UIKit:13:in '0x31bc02fb +[UIFieldEditor releaseSharedInstance] + 62' UIKit:14:in '0x31bc028b -[UIApplication _purgeSharedInstances] + 22' UIKit:15:in '0x31b59855 -[UIApplication _handleApplicationSuspend:eventInfo:] + 1176' UIKit:16:in '0x31b2a301 -[UIApplication handleEvent:withNewEvent:] + 2200' UIKit:17:in '0x31b29901 -[UIApplication sendEvent:] + 44' UIKit:18:in '0x31b29337 _UIApplicationHandleEvent + 5110' GraphicsServices:19:in '0x3026c04b PurpleEventCallback + 666' CoreFoundation:20:in '0x3443fce3 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 26' CoreFoundation:21:in '0x3443fca7 __CFRunLoopDoSource1 + 166' CoreFoundation:22:in '0x3443256d __CFRunLoopRun + 520' CoreFoundation:23:in '0x34432277 CFRunLoopRunSpecific + 230' CoreFoundation:24:in '0x3443217f CFRunLoopRunInMode + 58' GraphicsServices:25:in '0x3026b5f3 GSEventRunModal + 114' GraphicsServices:26:in '0x3026b69f GSEventRun + 62' UIKit:27:in '0x31ad0123 -[UIApplication _run] + 402' UIKit:28:in '0x31ace12f UIApplicationMain + 670' VeriFacts:29:in 'iVQ 0x00062e51 0x0 + 405073' VeriFacts:30:in 'iVQ 0x00002dd8 0x0 + 11736'

    While both the bottom- and top-most call in both backtraces are actually more or less the same, you can see from the rest of the backtrace that these two errors are actually quite different.

    What's even more interesting is that they actually have two completely different error messages as well: NSInvalidArgumentException: -[QSListFormItem addFormItem:]: unrecognized selector sent to instance 0x6ac38d0 vs. NSInvalidArgumentException: * -[NSPlaceholderString initWithString:]: nil argument

    Hope that helps to shed some light on some of the issues we are seeing.

    Thanks!

  4. 5 Posted by Harold Gimenez on 28 Jun, 2011 01:31 PM

    Harold Gimenez's Avatar

    Thanks Mike, that definitely helps shed some light into what's going on.

  5. 6 Posted by mwhuss on 28 Jun, 2011 01:43 PM

    mwhuss's Avatar

    Mike, what version of the notifier are you using? Some time during 1.0 we
    added support for the action & controller. Have you tried with the latest
    version of the notifier?

    On Tue, Jun 28, 2011 at 9:31 AM, Harold Giménez <
    [email blocked]> wrote:

  6. 7 Posted by Mike Ho on 29 Jun, 2011 05:02 PM

    Mike Ho's Avatar

    Thanks for the tip -- I've upgraded and it looks like it is doing a MUCH better job of the grouping. Thanks so much!!!

    However... just a note (and this was an issue with the older version I was using as well) -- the controller is always blank. The action is now being propagated correctly, but the controller has been and continues to be "", even though I'm using the latest version of the notifier that I pulled from github.

    Let me know whenever you get a chance. Thanks for your help!

  7. 8 Posted by calebdavenport on 30 Jun, 2011 05:43 PM

    calebdavenport's Avatar

    You have to do a little bit of work to get the controller field to populate properly. If you use the setRootViewController: method of UIWindow when your application launches (available only in 4.0 or higher) then that field is populated by walking the controller tree automatically. If you only call addSubview: on your application's window then you have to implement the HTNotifierDelegate method called rootViewControllerForNotice. Once you do one of those your controller will populate for all exception notices (but not signal ones due to the complicate nature of UNIX signals)

  8. 9 Posted by Ryan on 15 Feb, 2013 06:45 PM

    Ryan's Avatar

    Hello, we are currently revisiting tickets that seem that have been resolved. If you have any further questions let us know. Send an Email to
    [email blocked].

    Thanks,
    Ryan

  9. Ryan closed this discussion on 15 Feb, 2013 06:45 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac