2010/9/25 Sim IJskes - QCG <[email protected]> > On 09/25/2010 01:59 PM, Patricia Shanahan wrote: > >> On 9/25/2010 3:02 AM, Sim IJskes - QCG wrote: >> >>> On 09/25/2010 11:45 AM, Jonathan Costers wrote: >>> >>>> as you can derive from this snippet: >>>> >>> >>> Thanks, but are we debugging the VM or the part we have influence on. >>> Did we cause a sequence error in the build process or not? Is this >>> caused by assuming some kind of state, without initializing? >>> >>> Gr. Sim >>> >>> >> Or it could even be both a build script problem and a tools problem. >> > > > We >> could have a problem in the build that creates an unusual situation that >> is handled incorrectly, causing a crash rather than an error report. >> > > My intuition tells me this is the case. A VM should not crash. It does, and > it look very much like a problem i had, where i had 2 builds overlap, and > the second build, cleaned away the jars the first build used. I also had > lookalike problems when i used a class for the first time in a > shutdownhandler (Runtime.addShutdownHook). > > Nothing like this is happening during the River build, to my knowledge. Everything is done sequentially ...
I would expect the VM to throw some kind of Error, but thats obviously not > the case. > > The number of threads in the threaddump is very small, so either its near > startup or shutdown. > > The unices i used, had a tendency to start all daemons first and then allow > user login, but nowadays the gui is started while the daemons are starting, > (If i could find the time, i would create a singleuser unix instance without > any daemons, to run as a test slave for hudson). > > Gr. Sim > >
