[jira] Closed: (GERONIMO-1820) corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint()

["John Sisson (JIRA)" <de...@geronimo.apache.org>]

     [ http://issues.apache.org/jira/browse/GERONIMO-1820?page=all ]
     
John Sisson closed GERONIMO-1820:
---------------------------------

    Fix Version: 1.0
                     (was: 1.2)
     Resolution: Fixed

Fixed in rev 344299.

> 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.0

>
> 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