[e-lang] Strange lock-ups with simple E program
Thomas Leonard
tal at it-innovation.soton.ac.uk
Mon Nov 16 04:42:04 PST 2009
For anyone else having trouble with this, applying this patch is also
necessary as a work-around:
diff --git a/src/esrc/org/erights/e/elang/launcher/eLauncherAuthor.emaker b/src/esrc/org/erights/e/elang/launcher/eLauncherAuthor.emaker
index ac2e605..040d25d 100644
--- a/src/esrc/org/erights/e/elang/launcher/eLauncherAuthor.emaker
+++ b/src/esrc/org/erights/e/elang/launcher/eLauncherAuthor.emaker
@@ -90,7 +90,8 @@ Other E options:
def makeVat := auths["makeVat"]
def name := fname.split("/").last()
- def parserVat := makeVat.make("headless", `parsing $name`)
+ #def parserVat := makeVat.make("headless", `parsing $name`)
+ def parserVat := makeVat.getCurrentVat()
def makeParseFunc :=
makeParseFuncAuthor(auths["makeELexer"])
Otherwise, E sometimes fails to start. This happens maybe one time in a
hundred on my Linux system, but more often than not on the Mac. Why does
parsing happen in its own vat?
The error looks like this (I added code to display the sending context):
=== 2009-10-27T16:38:47.053Z (PendingEvent.report:PendingEvent.java:108) WRN
causality: Problem in turn <<Vat start in <runs in start>>,2>: [[[ SendingContext :
--- sent by: <Vat start in <runs in start>>:1(SCsend)java.lang.Throwable: just tracing causality
--- at org.erights.e.elib.vat.StackContext.<init>(StackContext.java:52)
--- at org.erights.e.elib.vat.SendingContext.<init>(SendingContext.java:69)
--- at org.erights.e.elib.vat.SendingContext.<init>(SendingContext.java:52)
--- at org.erights.e.elib.vat.PendingEvent.<init>(PendingEvent.java:44)
--- at org.erights.e.elib.vat.PendingDelivery.<init>(PendingDelivery.java:64)
--- at org.erights.e.elib.vat.Vat.qSendAllOnly(Vat.java:359)
--- at org.erights.e.elib.vat.Vat.sendAllOnly(Vat.java:143)
--- at org.erights.e.elib.prim.E.sendAllOnly(E.java:425)
--- at org.erights.e.elib.vat.PendingDelivery.innerRun(PendingDelivery.java:99)
--- at org.erights.e.elib.vat.PendingEvent.run(PendingEvent.java:74)
--- at org.erights.e.elib.vat.HeadlessRunner.run(HeadlessRunner.java:174)
--- at java.lang.Thread.run(Thread.java:619)
---
]]]
--vvvv--
Failed: OldFarRef may only be smashed: <Far ref>
- DelayedRedirector#run(Object)
. <a DelayedRedirector>(<Far ref>)
java.lang.RuntimeException: Failed: OldFarRef may only be smashed: <Far ref>
at org.erights.e.develop.assertion.T.fail(T.java:85)
at org.erights.e.elib.ref.OldFarRef.setTarget(OldFarRef.java:105)
at org.erights.e.elib.ref.EProxyResolver.resolve(EProxyResolver.java:189)
at org.erights.e.elib.ref.EProxyResolver.resolve(EProxyResolver.java:201)
at org.erights.e.elib.ref.DelayedRedirector.run(DelayedRedirector.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.erights.e.elib.prim.InstanceMethodNode.innerExecute(InstanceMethodNode.java:111)
at org.erights.e.elib.prim.JavaMemberNode.execute(JavaMemberNode.java:187)
at org.erights.e.elib.prim.E.callAll(E.java:164)
at org.erights.e.elib.vat.PendingDelivery.innerRun(PendingDelivery.java:96)
at org.erights.e.elib.vat.PendingEvent.run(PendingEvent.java:74)
at org.erights.e.elib.vat.HeadlessRunner.run(HeadlessRunner.java:174)
at java.lang.Thread.run(Thread.java:619)
--^^^^--
It's probably not relevant to this, but the other change I made to trunk
was to enable caching of modules:
diff --git a/src/jsrc/org/erights/e/elang/interp/ImportLoader.java b/src/jsrc/org/erights/e/elang/interp/ImportLoader.java
index 82a4865..c3d1115 100644
--- a/src/jsrc/org/erights/e/elang/interp/ImportLoader.java
+++ b/src/jsrc/org/erights/e/elang/interp/ImportLoader.java
@@ -198,7 +198,7 @@ class ImportLoader extends BaseLoader implements JOSSPassByConstruction {
// isConfinedPtr[0] = Ref.isDeepFrozen(result);
// XXX Leave it this way for now until we figure out the caching
// issue.
- isConfinedPtr[0] = false;
+ isConfinedPtr[0] = true; // TAL: too slow!
return result;
}
I guess this weakens the security somewhat, but we were running out of
memory without the change. Will this affect anything in the standard
library? i.e. does anything rely on getting a new instance for every
import? Is there a better way to solve this?
Thanks,
On Mon, 2009-07-27 at 17:02 +0100, Thomas Leonard wrote:
> Hi Mark,
>
> Thanks for looking into it. It's not urgent; I'm just prototyping things
> at the moment and using multiple vats in one process for ease of
> testing.
>
>
> 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
More information about the e-lang
mailing list