[ http://issues.apache.org/jira/browse/GERONIMO-1820?page=comments#action_12373748 ]
Vasily Zakharov commented on GERONIMO-1820: ------------------------------------------- Well, I couldn't reproduce the problem on Geronimo 1.0. Probably it got fixed. > corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint() > ------------------------------------------------------------------------- > > Key: GERONIMO-1820 > URL: http://issues.apache.org/jira/browse/GERONIMO-1820 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: startup/shutdown > Versions: 1.0-M5 > Reporter: John Sisson > Priority: Trivial > Fix For: 1.2 > > Noticed this email to the dev list (for M5) that didn't get a response. Need > to determine if this bug still exists. > Hello, all. > Recently, I accidentally corrupted the config.ser file in > bin/server.jar. It was my fault in this case, but this can also happen > in the presence of ill-formed scripts that manipulate files in > bin/server.jar or as a result of some bug in building procedures. > Geronimo error handling/diagnostics in that situation were not intuitive > to help me resolve the problem. I believe that an intuitive error > message is possible to help other users that might experience corrupted > config.ser files or other problem at the initial startup phase. > Here's how it looks: > C:\Geronimo> java -jar bin\server.jar > Booting Geronimo Kernel (in Java 1.4.2_04)... > java.lang.NullPointerException > at > org.apache.geronimo.system.main.ProgressBarStartupMonitor.repaint()V(Pro > gressBarStartupMonitor.java:362) > at > org.apache.geronimo.system.main.ProgressBarStartupMonitor.serverStartFai > led(Ljava.lang.Exception;)V(ProgressBarStartupMonitor.java:344) > at > org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:277) > at > org.apache.geronimo.system.main.Daemon.<init>([Ljava.lang.String;)V(Daem > on.java:78) > at > org.apache.geronimo.system.main.Daemon.main([Ljava.lang.String;)V(Daemon > .java:316) > To reproduce it, you can just write some trash to > bin/server.jar/META-INF/config.ser and try to run Geronimo as shown > above. > Note that there's completely no information in the stack about why the > crash really occured. I investigated, and here's what I found. > Looks like the bug is in > org.apache.geronimo.system.main.Daemon.doStartup() method. I here > describe the bug basing on 1.0 M5 version (including source code) I've > downloaded, using the line numbers to reference the code parts. > The doStartup() method is a big try-catch block. The catch block looks > like this: > 275 } catch (Exception e) { > 276 if(monitor != null) { > 277 monitor.serverStartFailed(e); > 278 } > 279 e.printStackTrace(); > 280 System.exit(3); > 281 throw new AssertionError(); > 282 } > As you can see, monitor.serverStartFailed() method is called (277) if > monitor is not null. And monitor is always non-null as it is initialized > in initializeSystem() method (116, 118) that is called from constructor > (73) before doStartup() method is called (78). In other words, > monitor.serverStartFailed() method is always called. > monitor object is really an instance of > org.apache.geronimo.system.main.ProgressBarStartupMonitor class, and its > serverStartFailed() method looks like this: > 343 currentOperation = "Startup failed"; > 344 repaint(); > 345 out.println(); > 346 problem.printStackTrace(out); > It calls repaint() method, which uses the configStatus field (362, 363) > which is initialized by foundConfigurations() method (64). > Now, we get back to Daemon.doStartup() method and see where > monitor.foundConfigurations() method is called. It's line 219. > It means that, if some exception occurs in lines 124 to 219 (in my > example, it's line 149), the exception handler (277) would throw a > NullPointerException (because monitor.configStatus field is not > initialized) and woudn't have a chance to report the real problem (279). > If we, for example, comment out line 277: > 275 } catch (Exception e) { > 276 if(monitor != null) { > 277 // monitor.serverStartFailed(e); > 278 } > 279 e.printStackTrace(); > 280 System.exit(3); > 281 throw new AssertionError(); > 282 } > we immediately get the proper stack: > C:\Geronimo> java -jar bin\server.jar > Booting Geronimo Kernel (in Java 1.4.2_04)... > java.io.StreamCorruptedException: invalid stream header > at java.io.ObjectInputStream.readStreamHeader()V(Unknown Source) > at > java.io.ObjectInputStream.<init>(Ljava.io.InputStream;)V(Unknown Source) > at > org.apache.geronimo.system.main.Daemon.doStartup()V(Daemon.java:147) > at > org.apache.geronimo.system.main.Daemon.<init>([Ljava.lang.String;)V(Daem > on.java:78) > at > org.apache.geronimo.system.main.Daemon.main([Ljava.lang.String;)V(Daemon > .java:316) > Of course, this situation doesn't normally occur, but in case of some > configuration error or file corruption finding out the problem becomes > impossible without the source code analysis. > I believe that this is a diagnostics bug in the current Geronimo stack. > Perhaps the line 279 should appear before line 276 so that the error > condition stack trace would be reported prior to the > NullPointerException from repaint(). Also the overall structure of error > handling in doStartup() method may be changed to avoid > NullPointerException at all. > Thanks. > Vasily Zakharov, Intel Managed Runtime Division -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
