geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sisson (JIRA)" <...@geronimo.apache.org>
Subject [jira] Created: (GERONIMO-1820) corrupted config.ser may cause NPE in ProgressBarStartupMonitor.repaint()
Date Sat, 08 Apr 2006 00:44:23 GMT
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


Mime
View raw message