[e-lang] Strange lock-ups with simple E program

[Thomas Leonard]

OK, I think I'm making progress here. In BootRefHandler.packageArg(), we
have:

            //arg is EVENTUAL (or was at the time of the test), and is not
            //handled by a BootRefHandler, so we treat it as a promise in the
            //src vat.

            BootRefHandler handler = new BootRefHandler(src, arg);
            DelayedRedirector rdr = new DelayedRedirector(handler.myResolver);
            //handler and rdr are in the dest vat
            Object[] args = {packageArg(rdr, dest, src, currentVat)};
            src.qSendAllOnly(arg, false, "__whenMoreResolved", args);
            //Is it ok to ignore the E.sendOnly return result here?
            return handler.myResolver.getProxy();

DelayedRedirector will create either OldFarRef or OldRemotePromise
objects, depending on whether "arg" has identity when it checks in its
constructor.

OldRemotePromise.setTarget will accept anything, but OldFarRef.setTarget
complains if you try to set it.

Adding a sleep makes it print the error message in all cases:

diff --git a/src/jsrc/org/erights/e/elib/vat/BootRefHandler.java b/src/jsrc/org/erights/e/elib/vat/BootRefHandler.java
index e6d0818..4ca874a 100644
--- a/src/jsrc/org/erights/e/elib/vat/BootRefHandler.java
+++ b/src/jsrc/org/erights/e/elib/vat/BootRefHandler.java
@@ -239,6 +239,15 @@ class BootRefHandler implements EProxyHandler {
             //handled by a BootRefHandler, so we treat it as a promise in the
             //src vat.
 
+           // TAL: but if it has an identity by the time we create BootRefHandler,
+           // then it will be an OldFarRef, not an OldRemotePromise, and subscribing to
+           // __whenMoreResolved will only cause trouble...
+
+           try {
+                   Thread.sleep(200);
+           } catch (Exception ex) {
+           }
+
             BootRefHandler handler = new BootRefHandler(src, arg);
             DelayedRedirector rdr = new DelayedRedirector(handler.myResolver);
             //handler and rdr are in the dest vat

I'm not sure what the correct fix is, though.


On Sun, 2009-07-26 at 19:56 -0700, Mark Miller wrote:
> Hi Thomas, I haven't found the bug yet, but I have narrowed it down to
> a race condition bug in the boot-comm system. Your same stress test,
> with your
> 
>     def seedVat := seedVatAuthor(<unsafe>)
> 
> replaced by
> 
>     introducer.onTheAir()
>     def seedVat := seedVatAuthor(<unsafe>).virtualize(introducer)
> 
> seems to never lock up. The only difference between these is that the
> latter uses captp instead of boot-comm. In the boot comm case, the
> form of lock up looks like a lost signal: all vats are quiescent
> waiting for a message. I have also discovered many things that the bug
> is not ;). Unfortunately, the clues so far seem to point to a
> multi-threading race condition bug.
> 
> Unfortunately, I won't have time for further investigation for another
> week. If you're blocked on this, might the above change be a useful
> workaround for you?
> 


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal at it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk