>We had the Problem that a packaged EXE suddenly terminates without writing
>a walkback.log or even executing the exit methods. The development image
>runs fine, also we tried to package with and without reduction, but the
>problem persists.
>
>We found out that building in some message boxes to trace the point of the
>failure moves that point beyond and beyond.
>
>After a long search we found the reason:
>
>If the compiled method code stored in the library differs from the compiled
>method code when you compile the same source again, you have a possible
>candidate for this sudden death syndrom. We wrote a little tool which
>compiles all methods in selected Applications and compares the compiled
>method with the stored. If a difference occurs, the tool optionally stores
>this compiled method again.
>snip
Thomas --
Bytecode differences is certainly one possible known problems that can
caused sudden dealth. What I don't quite understand is that how can
the same compiler generates bytecodes in an inconsistence manner.
Some of the bytecode differences that we've known in certain cases
happened in standard class like Dictionary or Set, which to me make no
sense at all. If it happens in highly optimized code or non-kernel
classes, it makes some sense. This behavior is very worrisome for
stable application because why should we do a bytecode check everytime
we package our runtime?
Anyway, what you described is only one way of having sudden dealth.
In our case, the problem is due to a called DLL function that has a
memory problem. It happens in *both* development and packaged runtime
which is different from the bytecode differences scenario.
There is a third type for sudden dealth that we're known of is
VMTRAP. I have posted a question here before but unfortunately I did
not get any answer at all. Anyway, we've found that when an VMTRAP
occurs, sometimes we don't see the VMTRAP.IMG. Having this file is
quite meaningless to us since we can't do anything but at least we can
send it to IBM for further probing.
-- Mark