Community
Participate
Working Groups
When clicking this bug, eclipse will generate a bug report automatically. The Build it, plugins info, jvm info, OS info, log info and all other information required (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-text-home/development/bug-incomplete.htm) is all generated automatically. All I have to do is explain the bug, not the environment information.
firefox, google and windows can report bug info automatically
I think eclipse should automatically connect bugs.eclipse.org, all the information is transparently provided to the bug database.eclipse.org, so bugs.eclipse.org will know which version of eclipse has which bugs.
An issue I see with this is that many products are built on top of eclipse. It seems likely that we would be inundated with bug reports that are not related to the plug-ins developed by eclipse.
Hi Thomas Watson, You are right. I think you should also provide a mechanism for report bugs of plugins to their developer. Each plugin should have their own bug report channel provided by eclipse. When clicking the "Bug Report" button, eclipse can let the user to choose which plugin provider to report. If someone is using SWT Designer, he my report the bug to www.swt-designer.com by email or web or some protocal provided by eclipse. If someone is using MyEclipse, the user could report the bug to http://www.myeclipseide.com/ by email or or web or other method some protocal provided by eclipse. The bug report may be an XML document or an zip file which can be processed by a program, you can reduce you work on bug process, all bugs will be categoried by Errors, Exceptions, classes that generate the Errors and Exceptions, or categoried by some other way automatically. You can also provide an protocal to forward the mis-reported bug report to their plugin developer automatically. For example: A report contains the following: com.myeclipxeide.j2ee.ejb.MyEclipseEJBException com.myeclipxeide.j2ee.ejb.EJBParser .......... ........... This kind of bug will be automatically forward to www.myeclipseide.com, eclipse develope team will not even see this report. FireFox has an "Report Bug" on the Help menu, I don't think firefox team is inundated by bug report. The "Report Bug" bug will only make firefox better and better, make the bugs less and less.
Windows will also report crash information to microsoft.com, no matter whether the crashed program is developed by microsoft. Is Microsoft inundated by bug report? I don't think so.
I think "Bug report" button will save you lots of time in fixing bugs by providing more detailed bug information such as eclipse version, OS info, JVM info, log and many other info.
This is an interesting idea. The main complication is in properly attributing the problem. Many problems occur in, for example, the UI plugin but they are actually because of a problem in some other plugin. So getting the initial blame right is critical. This likely falls under the Servicability plan item (bug 106193) Moving to UI as this function would have to live up there where the user can see it.
Passing to MvM - where should this go?
Good questions, so the points are: - we can't just put in a button that logs to the eclipse bugzilla unless we only provide this support during development and not in the Eclipse SDK final downloads - if we want flexible support we need api to submit the but to a certain place - we are past M5 so can not add new API. - also something along these lines has been done elsewhere, michael valenta did Team do something like this once?
We never had anything that reported bugs. We had a tech preview for managing bug history (i.e. arrange your bugs of interest in a tree viewer). The browsing of bugs was all done using the SWT browser.
Regarding Comment 7 from Jeff. I agree. What we can do , in this componentized solutions, is to give the blame to the component raising the exception first (in this case UI). Which could look at it and then route it But, I would suggest component should 'protect' themselves (Assert or other) with API trace and validation (easier said than done I know) So in this case, and in Utopia world, UI would have thrown an Assert exception which would prove the contract has been broken by another component. This would work OK if the parameter is the issue. This will become more difficult if the culprit is an object modified way before by another component and not passed as a parameter. But in this case, the parameter object owner should trace who modified it and when. So yes, there is a 2 phase situation (which could be done by the 'send button') 1) get the signs (log/trace) 2) reproduce the problem which starts appropriate traces based on previous ------- example: A-> calls B and the object which is teh issue is C A->B and passes C B throws NPE or other error B is 'IT' A->B and passes C B throws Assert exception A is 'IT' A->B and does not pass C A throws error accessing C (example getting a IFile returns something different) We need to parse the log and Trace the C component to see who modified it Thoughts ?
I think this would be suitable as a nice fragment/plug-in/fragment that is delivered with development builds (N,I,S,M). IMHO there are different topics involved her. 1. Quality Feedback This is actually what Microsoft, Mozilla and a lot other application provide. The action that generates the report is in almost all cases triggered by a real crash. In the Java world this would probably mean an exception as it would be impossible to catch VM crashes caused by 3rd party native libs. The information of this action is only useful to the producer of the exception. A user will actually not know who caused the exception. Thus, there has to be some kind of analysation to compute and locate the receiver of the report. It would be a great benefit if a click-stream of the last xxx user interactions could be provided in the report. The implementation would not be easy because it has to be generalized. An option would be to provide only the APIs and the product producer is responsible for exposing this. For example, in RAD all reports would go to IBM Rational, in MyEclipse all would go to MyEclipse, etc. The receiver will be fixed and he would be responsible for sorting and analyzing the reports. I currently don't see Eclipse in the role of delivering support for this functionality. 2. User Feedback User feedback is mostly not triggered by a crash or an exception. It's triggered by the user because he noticed some unexpected behavior and wants to report this. In most cases you can assume that the user knows who is causing this (for example, the Java editor or the Problems view, etc.) and who should receive the feedback (in the example above Eclipse.org). Of course it would be nice if we would also have some kind of click-stream here that a user can attach to the report. But the most useful thing in this case would just be a nice little two step wizard that collects a subject, a description and some classification info. Based on this a Bugzilla entry is generated and additional info (like the log file and the configuration) is attached to the bug report. This implementation could be highly Eclipse specific. No need to exposes APIs (at least not in a first implementation).
I am thinking we could allow plugin provider to replace the 'list' in the ErrorDialog class with their own UI. And then they provide the 'send bug' button. We could retrive the plugin handler from the IStatus. I have not investigated the 'flight recorder option' or 'feedback option'
We had a short discussion about this and came to the conclusion that providing a "report bug" button is a hard problem. Here are some issues: - privacy: stack traces or directory paths could contain sensitive information - blaming is hard as already pointed out in comment #7 - this could generate tons of data that someone would need to store and aggregate - bugzilla does not seem to be the right channel for automated bug reports I should explain the last point in more detail: A good bug report consists of context (a), reproducible steps (b), expected behaviour (c) and actual behaviour (d). When the error dialog is opened, we can help with (a) and (d) but not (b) and (c). Don't get me wrong, I don't want to shoot this down. In fact, I would like to be able to receive feedback about errors in the field, but this would have to be discussed at the Eclipse.org level (assuming that they would be where all that data ends up). I have filed bug 144035 against Community/Callisto to discuss this further. For this bug, I would like to propose focusing on what we can do to improve the end user experience with the error dialog without requiring server-side infrastructure. I have updated the bug title accordingly.
Here are some realistic steps we could take to improve the end user experience with the error dialog: - move the PDE Error Log view down into Eclipse Platform - link the error dialog with the error log view, making it easy to open the error log view from the dialog, or displaying the same information in the dialog itself - provide actions in the error log view's context menu that collects key information and puts it onto the Clipboard or into a file, so that it can be put in bugzilla or maybe other bug report systems if it's an RCP application. The key information should include the OS and window system, version numbers, the stack trace, etc. - Help the user to direct the bug report to the appropriate address by including contact information or "bug reporting instructions" with every plug-in or feature that could be displayed in the error log view or along with the stack trace. For example, for each line in the stack trace it should be possible to find the containing plug-in or feature and display its preferred bug reporting URL.
Hello :) Yep, let's keep the discussion going :) - privacy: stack traces or directory paths could contain sensitive information <ce> true, the user should review what is going to be sent first</ce> - blaming is hard as already pointed out in comment #7 <ce> well... :) if you take the hard path of stating: the leaf component in the embedded stack trace is the one to blame... We should at least have 80% If it is not the one to blame, then this component should 'protect itself' in the future OR We let the user decide who to send it to </ce> - this could generate tons of data that someone would need to store and aggregate <ce> true, what is the issue here ? Some of Database logs at 1.2 Terabytes (sic) after a week of trace... </ce> - bugzilla does not seem to be the right channel for automated bug reports <ce> please elaborate. My proposal is to have plugin developer extend the ErrorDialog providing their own feedback mechanism </ce> I should explain the last point in more detail: A good bug report consists of context (a), reproducible steps (b), expected behaviour (c) and actual behaviour (d). When the error dialog is opened, we can help with (a) and (d) but not (b) and (c). <ce> I disagree :) <I hear some eclipse developer say.. oh no, not again> My feeling is, if you have proper trace and context you do not need b or at least you can automate that But you are right in a send, this is no the 'bug report dialog' goal to get traces it is merely a viewer of the error and a place holder to be extended </ce> Here are some realistic steps we could take to improve the end user experience with the error dialog: - move the PDE Error Log view down into Eclipse Platform <ce> Yes, goad idea, and provide extensions then :) Now this only work with .log, what about products who have their own logs ? </ce> - link the error dialog with the error log view, making it easy to open the error log view from the dialog, or displaying the same information in the dialog itself <ce> Yeah, I am find if the extension is either in the dialog or the view, as long as I can extend an error with a behavior for my plugin </ce> - provide actions in the error log view's context menu that collects key information and puts it onto the Clipboard or into a file, so that it can be put in bugzilla or maybe other bug report systems if it's an RCP application. The key information should include the OS and window system, version numbers, the stack trace, etc. <ce> I believe there is already a bug opened for that https://bugs.eclipse.org/bugs/show_bug.cgi?id=130157 </ce> - Help the user to direct the bug report to the appropriate address by including contact information or "bug reporting instructions" with every plug-in or feature that could be displayed in the error log view or along with the stack trace. For example, for each line in the stack trace it should be possible to find the containing plug-in or feature and display its preferred bug reporting URL. <ce> yes I am fine with that It is true that if I have a error view, (stack trace) and I have a possibility to 'hook a behavior' for each line (based on package or error id) I could survive the change :) </ce> So, in a nutshell, if we move the behavior from the Dialog to the view and we are able to extend the view, this may be even better as we can have persistence of info. This said, how do we go about error/logs/traces NOT in .log ? :) TPTP seems to have a LOG ANALYZER ... do we link to them ?
I was just thinking Some may ask : How would multiple error dialog extensions be handled / prioritized? In a product, wouldn't you want to show the nice error dialog even in cases where the plugin id starts with org.eclipse? True... ummm... I believe there are 3 issues here 1) showing the good proper information when a dialog opens. Talking to some of my coworker and some customers, we believe users mainly do not care about the error. They want to know how it will impact their work and how to fix it. A link to a webpage, fix or description on how to work around the problem is sufficient. Then some user may want to look at the error which leads me to #2 2) From the error, users can search the infocenter and find a longer description of what is happening (providing we have unique message ID... but this is another story :) In any case, this is the issue raised above: How to show a dialog with multiple error. If this does not help, then we go to #3 3) User will want to send as much info as possible to their help desk (could it be internal to their company or a 3rd party or the company that delivered the product they are using... ). And this is the 'bug button issue' This said, I re-looked at the ErrorDialog methods... They still take a IStatus Which could usually be a simple Status or MultiStatus instance. Interestingly, one can create its own implementor of Status... maybe a path to explore - A Status will only contain one plugin ID, so we are cool - A MultiStatus will contain a hierarchy of Status or MultiStatus right ? in any case, the Root IStatus is the one responsible for rendering, the same way the catch block that does not throw any Throwable is responsible for handling the error... So it is the responsibility of the root IStatus to render either all embedded statuses (same behavior for exception, I can just printStackTrace my exception or the all stack of exceptions) or decide to call the 'exception renderer' for each embedded exception. This said, this is only for #2 above. For #1, it is the responsibility of the IStatus handler to render the description and so on (same behavior for exception handling). Of course #1 and #2 are optional, some handler may decide to NOT handle either #1 or #2, in which case we fall back to default behavior Now, in terms of UI, and trust me this is not my forte :) so feel free to bash me :) The ErrorDialog should stay as it is. When an error is shown the IStatus Handler will decide what to render. If the user clicks on Details, then we draw some kind of tree *------------------------------------------------* | | | | *--*-----------------------------------------*---* | | | (a) | | | |----------------------------------------------- | | | | | | | | (b) | (c) | | | | | | | | | | *---------*--------------------------------------* (a) is the same as before, error message, info etc (b) could be a tree where selecting the root shows #1 in (c) and the rest is actually the chain of exceptions (optional decided by the root handler) Selecting each exception will either call the specific handler for this exception or the Root handler (same behavior as catching exception). Info will be shown in (c) The same provider could hook into TPTP to launch the Log Analyzer... or more... More to add: I got feedback that for certain RCP app, we would need a ErrorDialog pre-processor and broker couple reasons 1- some error should be rendered somewhere else than the ErrorDialog, example in the status bar 2- some error should never be seen by the user but sent to the admin 3- some error should be remotely logged with out the user knowing (example a central RCP app in a company, when an error occurs they want the help desk to know it right away...) <of course, this implies security... but Microsoft and Firefox do it) So in and out, I believe if we have pre hook and UI framework in ErrorDialog we could solve #1 and #2 Now.... for #3... well I need to do more work on that... I hear the issue.... - It may be easier for RCP or Product based on eclipse as the user usually buys support with it - It may be harder when a user has a product and some components that he/she also bought... - Much harder for eclipse :D. SWT can throw an exception because an application was badly coded... Now realize that Microsoft and Firefox only send bug automatically in case of a crash, possibly a good use of org.eclipse.ui.application.WorkbenchAdvisor#eventLoopException ? End of Friday night’s thoughts… :)
We have to watch the idea of sending things automatically - most users get (understandably) concerned when information gets sent without thier explicit permission. We could only do it with permission. Right now we have 3 ways of showing errors in the UI 1) Error Dialog (single error) 2) Jobs Error Dialog (which collects errors) 3) Error log All 3 of these show different things 1) An error explicitly called from code 2) Any IStatus with a code of IStatus.ERROR from a job 3) Anything written to the .log All of these should be brought under the same mechanism - i.e. all accessible to the user. I think a view is a pretty good idea. It could show entries in the .log and also hold onto errors shown in the first two cases. I generally don't beleive in "hidden" errors. If it is enough of a problem to be logged somewhere it is one that should be shown to the user so that they can report it. I understand however that not everyone else sees it this way - for instance Debug logs connection errors as does Team and these pretty clearly don't need to be in the users face all of the time. I think we should keep it open ended as you guys seem to be suggesting - i.e. let the error system provider decide how to let the user proceed. Copying to the clipboard is a no brainer - we should allow that for sure.
re: <ce> well... :) if you take the hard path of stating: the leaf component in the embedded stack trace is the one to blame... We should at least have 80%... </ce> If the plug-in has API that states "argument 'aString' can not be null", and then calls aString.length() length on it, that plug-in should *not* be blamed for the NPE. It also does not have to protect itself from the potentially null argument that gets passed in. It certainly *can*, but if all it is going to do is slow down the system to replace one stack trace with a slightly better one, it's not clear that's useful.
Mike, I hear what you say about slowing to vrifying... but here is what happens Component A calls component B and passes null The javadoc states you cannot pass null Component B does not check Component B blows up The stack trace show: NPE in component B The customer will call the developer of component B and state: You have a bug The developer takes a couple hours/minutes to answer and states: go see component A Ultimately, we all agree the user should contact Component A Now this can be done: 1) Component B includes an assert (I agree it slows code) 2) Once the stack is received, a tool analyzes the error, realizes the javadoc states <null nor premitted> and is *smart* anough to tell the user: yeah, you have a NPE in Component B, but you know what component A sent null, and based on the javadoc I have it should not, so I believe you should contact Owner of component A IMHO this is not something Eclipse should do (at least not in 3.3 :) I still believe in defensive coding, either in the code OR in the 'problem determination' So , in a nutshell, I would leave the code the way it is, but provide hooks for 'analysis of the error' and let the user decide what they want to do... [who to send to, what to send etc...] Thoughts ? :)
I just thought of something, I do not know how much you know SWT <grin> :) but it throws a very nice error stating SWT is not the issue org.eclipse.swt.SWTException: Invalid thread access Eveeryone in support knows (and you can search Google) that it means: 'do not bug SWT for this issue, but bug the caller of SWT because they did not follow the contract and they called SWT in a non-UI thread' So I still believe 1) if component owenr does not want to protect its component, that is fine.. but they may be called 2) The 'log analyzer tooling' or 'error analyzing tooling' that can be hooked on a error can become smart (in this example I suppose we would tag the caller of SWT as the most probable culprit) 3) ultimately, let the user decide who to send the bug to (each plugin developer will have its hook to bug report) and what to send (same thing, all plugin developer could create a 'collector' code that will gather relevant data) 4) sending the info is plugin or feature specific (some may decide email, some will do FTP, some will do bugzilla... some may even override all and decide to send that to their in-house support team) Chris
Unfortunately, because the workbench is the bottom of the stack for many of the things that happen in Eclipse, "*they* may be called" will translate to "*we* would get many spurrious bug reports". This would be painful, but might be ok, if it meant that at least users were happy, but I suspect they would just get frustrated that the tool would be consistently pointing them at the wrong problem owner (and we would not necessarily be able to direct them to the right one, unless the issue was obvious). Really, I have thought about this quite a lot, and it isn't worth doing "auto-assigning of blame" unless we can figure out how to actually get it right; the added cost in both our development time (since we are the L1 support team), and the raw bandwidth costs at eclipse.org, would be too high.
re: org.eclipse.swt.SWTException: Invalid thread access Many of the native OS functions they call will general protection fault (or equivalent) if you invoke them from the wrong thread. The same is true for passing in bogus arugments. In addition, the set of functions that will do this varies by OS. Given that, they really didn't have any choice about protecting themselves, but clearly crashing the VM is different than getting an NPE.
I 'violently' agree eclipse should NOT provide a 'auto-assign of blame'. Products should :) (meaning RCP app in an company or products based on eclipse or RCP) Eclipse community is probably interested in hard JVM crash caused by Eclipse natives though (like firefox and Microsoft do). And Eclipse may provide a hook for that, no ? What I auggest is : provide Eclipse exploiters to hook any bug report facility they want :) And as Tod says, it could be UI hooks or CallbackHooks or already existing hooks (log viewer, workbenchAdvisor etc...) I agree we should not 'send everything to eclipse.org' , but from a user perspective, here is how it works today 1) John is a business analyst and is developping a process using a RCP application 2) a NPE occurs as suggested before 3) John gets an error stating NPE in ... followed by a stack trace What does John do now ? John does not even know where the log is, what the error mean or how to contact its Support team... John does not even know what FTP means... (true story, trust me) So :) 1) no auto blame from Eclipse code 2) I like comment #15 from Boris and comment #18 from Tod 3) the only thing I am missing are the UI hook in ErrorDialog, MessageDialog and Jobs Error Dialog (If I have that, I am all set :) 4) I may also need a 'log/error' listener, in case I want to process the error differently than te plugin provider decided (example. I am the main application, I want all error to 'never be shown to the user' but be forwarded to my company help desk) Do you all think it is Eclipse's goal to provide 1) Hook for product to provide their own serviceability tooling 2) a way to gather Eclipse relevant data (bug 130157) And if Eclipse wants to provide their own hook to #1, then so be it ? :) If not, that is fine... Cheers
To maintain the spirit of violent agreement, I also: - am strongly in favour of doing something better than we are currently - think Boris is on the right track in comment #15 - agree with Tod's concerns/comments - think the whole strategy should be more pluggable. I just want us to make sure that we don't accidentally do something that prevents us from being able to make progress. Imagine naively putting in a button that makes it trivial to send a stack dump to Eclipse.org (or to an RCP app developer) every time there is a crash, then shipping the app and afterwards finding out that some browser upgrade has caused *every* user to blow up. Yes, we want to know about it, no we don't want a million people to send a 100K file to us (or anyone else).
Whaou :) We seem to have found some agreement :) To add to that, I am willing (and hopefully able :) to code some part How do we go about that ? We wait for 3.2 to ship and you folks to take deserved holidays ? Or do we open separate bugzilla and discuss design there ?
We had a discussion about this bug, and I will post some notes from the meeting in separate comments to make it easier to discuss them separately. Sorry for the delay (the meeting was over a week ago), I had this sitting around for some time and kept forgetting to copy it over to bugzilla.
Many ways of showing errors =========================== Here is a list of all the ways in which we currently show errors: 0) startup logging before the UI is available --> config, application error 1) logging errors to the log file --> Core support 2) error status from jobs --> with UI asynchronous errors, some of which are expected failures 3) application --> new error dialog synchronous messages about expected failures 4) uncaught exception asynchronous errors that are not expected - particularly nasty: OutOfMemoryError 5) PDE -> show log 6) JVM crash --> launcher dialog - the #3 type of errors is different from the others in two ways: - usually reports expected failures (for example I can not connect) - the expectation is that this is blocking and shows a dialog, so we probably cannot change that behaviour
Guide the User ============== The goal is to guide the user as to what to do in the case of an error. We need a story that works for the Eclipse Platform/SDK with any number of installed plug-ins and features, possibly from third parties. It is a little easier to do this for a (closed) Eclipse-based product because there is just one place - the WorkbenchAdvisor - that knows best what to do in case of an error. We discussed the following requirements (coming from Christophe): - ability to replace the IStatus before the error dialog is shown (for example, log into the status bar, send error to server - concern was: how to make sure that errors are not lost - ability to provide custom content in the details part of the error dialog - pluggable error reporting policies - based on a stack trace, how do know which "error handler" to invoke? - are error handlers singleton in the whole application - the user should have a choice to whom to report the bug
Thoughts, Directions for Future work ==================================== - we may build on the user assistance work and the "?" button in the dialogs - precise blaming is not always necessary. See what is going on now on bugs bugs get reassigned - we can help the user make a decision by displaying relevant information about the involved plug-ins - to enable this, let each plug-in specify a URL where the user can report errors / get support - make the error dialog more pluggable - investigate a "log bus" where listeners could watch for what is being logged - what happens with an SDK and third-party plug-ins, who do we report to if the third party is unknown - what happens in a commercial product and open source plug-ins are installed - Applications tend to write into multiple log files using various APIs. We need to understand why these other log mechanisms are being used and if we can improve the eclipse one (provide a facade api for logging and some customizability)
Just a follow up, should we discuss more or is it in plan or are we looking for community to help and drive ? :)
(In reply to comment #31) > Just a follow up, should we discuss more or is it in plan or are we looking for > community to help and drive ? :) I don't know what the plan says about this but it can't hurt if you drive for now. ;-)
*** Bug 178515 has been marked as a duplicate of this bug. ***
*** Bug 113847 has been marked as a duplicate of this bug. ***
*** Bug 118492 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
