After further experimentation, I have confirmed that none of the following
seem to affect whether a crash occurs (I tried with each option enabled
or disabled):

   Inlining
   Exception trace
   Check for Void target
   Dead code removal
   No precompilation used

Since the crash occurs when using "ec -loop", I assume this is not a
multi-threading bug, since I don't think multithreading is used in this case.
I also found that the crash occurs if the first and third compiles are
finalizes and the middle one is a melt.  And my instructions for reproducing
the crash show that it occurs when there are no compilation errors in
any of the 3 compiles.

Here is another crash I got while running under dbx.

t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 0xaaef1cb
0x0aaef1cb: _get_exit_frame_monitor+0x2663da7:	movl     %edx,(%esi)
(dbx) where
current thread: t@1
  [1] 0xaaef1cb(0xacea7e0, 0x80466f8, 0xaaef0e4, 0x11e6e2b1), at 0xaaef1cb 
  [2] 0xaaef0e4(0x11e6e2b1, 0x52, 0x80466f8, 0xaaef04e), at 0xaaef0e4 
  [3] 0xaaef0e4(0x11e6e2a0, 0x7, 0x14, 0xaaef24e), at 0xaaef0e4 
  [4] chunk_coalesc(0x11b14e18, 0x8046760, 0x10, 0xaaee3d6), at 0xaaef2cd 
  [5] 0xaaee5f4(0x11b14e18, 0xacea7e0, 0x80467a8, 0xaaee398), at 0xaaee5f4 
  [6] rel_core(0x0, 0xacea7e0, 0x8046838, 0xaaf06c7, 0xd9bb1e8, 0x0), at 0xaaee3b7 
  [7] 0xaaf20e7(0xd9bb1e8, 0x0, 0xaf83328, 0x0, 0x21, 0xaf83348), at 0xaaf20e7 

Clearly, things are very messed up.  When I ran this same case without
dbx, the result was a panic cascade.

Full trace attached as stack18.txt.