Community
Participate
Working Groups
The following stack reports 71 matches, which is too many. I wonder if we need to require a more strict match on the first stack frame, e.g. ignore the sourceline (since line numbers change often), but require the fully qualified type name and method name to match. -- Error Log -- Date: Sun Jul 30 12:07:01 PDT 2006 Message: Could not create editor via factory: org.eclipse.mylar.internal.bugzilla.ui.tasklist.BugzillaReportEditorFactory@149544d Severity: Error Plugin ID: org.eclipse.mylar.core Stack Trace: java.lang.NullPointerException at org.eclipse.mylar.internal.bugzilla.ui.editor.ExistingBugEditor.addAttachContextButton(ExistingBugEditor.java:269) at org.eclipse.mylar.internal.bugzilla.ui.editor.ExistingBugEditor.addRadioButtons(ExistingBugEditor.java:174) at org.eclipse.mylar.internal.tasks.ui.editors.AbstractRepositoryTaskEditor.createActionsLayout(AbstractRepositoryTaskEditor.java:1205) at org.eclipse.mylar.internal.tasks.ui.editors.AbstractRepositoryTaskEditor.createFormContent(AbstractRepositoryTaskEditor.java:472)
This issue is probably best addressed by improving the stack trace parsing to be independant of the formatting. If we match stack trace lines against a regular expression which allows for arbitrary spacing and newlines, it should fix this problem.
Created attachment 47033 [details] Screen shot Mik, it looks like the formatting of the stack trace is getting messed up from a copy/paste. This causes the parsing to stop at just the first line of the stack trace which is what gets searched for. This could be a problem when people copy a stack trace from a web browser for example. The screen shot shows the search with the formatting fixed and one search result.
BTW, jrockit vm produces different stack traces...
(In reply to comment #3) > BTW, jrockit vm produces different stack traces... > Yeah, I just realized that gcj does as well. I guess we'll have to find a common subset of attributes to improve the stack trace parsing. For now, only Sun style stack traces will parse corectly.
Created attachment 47381 [details] Regex match stacktrace Improves stack trace matching with regular expressions. Stack trace matching is now independant of line formatting (from copy/paste, etc..), spacing, and is compatible with multiple jvms style stack traces. I added a few new test cases to test the stack trace parsing as well.
Patch applied and verified with bugs222 bug 41. Good tests. Does this resolve the bug? You should create a new report for JRockit stack traces if this doesn't address those, and we'll prioritize according to demand.
This completes the bug. I googled stack traces from various JVMs (including jrockit). It should work with everyone I saw including: sun ibm bea (jrockit) gcj/gij jamvm sablevm kaffe ikvm cacao jikes
Did you add a test case for each format? A good way to do that is to have multiple tests run one helper method with different stack trace strings so that it is easy to understand and to update. That would be fantastic because it would insulate us from changes.
I didn't add separate cases for each of them because most of them are very similar, the pattern matching is based on a subset of the similarities. Some of them just have different information in the brackets at the end of the line or use "/" instead of "." in the namespaces. I can add a few more test cases to be sure all of the features from each type are covered.
That would be great, and it totally makes sense only to cover a subset. Please name the tests according to the vendor name to make it obvious where to go to update when something changes.
Created attachment 47546 [details] Adds tests to cover all known stack trace formats Each test lists the JVMs which share that type of stack trace formatting and includes a small comment indicating what makes that stack trace format different from others.
Created attachment 47547 [details] mylar/context/zip
Patch applied, good tests.
