Community
Participate
Working Groups
Using build I20060329-0010, I got an NPE which messages starts with: eclipse.buildId=I20060118-0800 This is the case in the Session Data panel of the Event Details dialog, and in the exported log as well. Interestingly enough, other errors of today in the same eclipse show the appropriate build id, including one that is another instance of the same error. I will attach the complete log for reference.
Created attachment 37213 [details] Error log The first error shows a wrong build id.
I still see this from time to time, also with different buildIds for entries logged during the same Eclipse session. Could be a problem with .log file rotation. I'm running I20070123-1715, and below are the two most recent entries from the Error Log view. Interestingly, the latest message (with the wrong buildId) contains "This is a continuation of log file C:\e\w\development\.metadata\.bak_0.log". --- eclipse.buildId=I20070116-1510 java.version=1.5.0_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_CH Framework arguments: -showlocation Command-line arguments: -data C:\e\w\development -clean -consolelog -console -showlocation -debug C:\e\w\debug-options.properties This is a continuation of log file C:\e\w\development\.metadata\.bak_0.log Created Time: 2007-01-22 15:44:50.636 Warning Mon Jan 29 10:22:59 CET 2007 Ignored attempt to add saveable that was already registered org.eclipse.core.runtime.AssertionFailedException: unknown saveable: org.eclipse.compare.internal.CompareEditor$CompareSaveable@12d6a87 from part: org.eclipse.compare.internal.CompareEditor@12d6a87 at org.eclipse.ui.internal.SaveablesList.logWarning(SaveablesList.java:177) at org.eclipse.ui.internal.SaveablesList.addModel(SaveablesList.java:107) at org.eclipse.ui.internal.SaveablesList.addModels(SaveablesList.java:279) at org.eclipse.ui.internal.SaveablesList.handleLifecycleEvent(SaveablesList.java:211) at org.eclipse.compare.internal.CompareEditor$2.run(CompareEditor.java:284) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) --- eclipse.buildId=I20070123-1715 java.version=1.5.0_10 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_CH Framework arguments: -showlocation Command-line arguments: -data C:\e\w\development -clean -consolelog -console -showlocation -debug C:\e\w\debug-options.properties Error Sun Jan 28 17:33:11 CET 2007 Problems reported while synchronizing CVS Workspace. 53 of 72 resources were synchronized.
The build id is only logged when we write a !SESSION entry. This should only be done on the very first log entry for the session and once for each time we rotate a log. Each time we write the !SESSION entry we simply get the configuration property eclipse.buildId to write the build id to the log. The only way this could change in the rotated log is if the config property changed since the last time we saved a !SESSION entry. A log file may contain multiple sessions that use different builds. In that case each session will record the different build id used. It seems like this is the case in the attached log.
Created attachment 57745 [details] Log file for comment 2 I got the entries in comment 2 from PDE's Error Log view (opened event details and clicked the copy button). I took a closer look at the .log file and found out that the .log file is actually OK -- it's just the Error Log view that tries to foist a wrong id on me.
Moving to PDE/UI, since the problem is only in the Error Log view.
This annoys me every time I use the Error Log view.
(In reply to comment #6) > This annoys me every time I use the Error Log view. and bug 188334 makes me sad :(
tagging bugday
Created attachment 82399 [details] mylyn/context/zip
(In reply to comment #6) > This annoys me every time I use the Error Log view. Markus, does this issue still happen to you? I tried with files attached to bug but everything seems correct.
(In reply to comment #10) > Markus, does this issue still happen to you? I don't use the unreliable copy button any more. => I can't say whether this has been fixed in the new Error Log view or not. To verify whether this has really been fixed, one would have to take the .log from comment 4, put it into a workspace of an old build (3.3 should still have the bug) and check whether this really reproduces the bug. Then do the same with a recent build to verify if it has been fixed.
(In reply to comment #11) > To verify whether this has really been fixed, one would have to take the .log > from comment 4, put it into a workspace of an old build (3.3 should still have > the bug) and check whether this really reproduces the bug. Then do the same > with a recent build to verify if it has been fixed. that's what I did and couldn't reproduce neither in 3.3 or HEAD.
> that's what I did and couldn't reproduce neither in 3.3 or HEAD. Then let's close this bug. I think I've just been in a situation that would have made this problem appear in 3.3 (log file was rotated and I then started up with a new build), but it was fine now in I20080327-2251.
