RE: [abc] RE: bug in TM codegen?

The problem seems to be that if the iteration order is unpredictable (as with a regular hash set), we generate code that breaks at runtime. In particular, the nodes are numbered differently. Would you like two jimple outputs to compare?

Eric

> -----Original Message-----
> From: Majordomo list server [mailto:majordomo@comlab.ox.ac.uk] On
> Behalf Of Pavel Avgustinov
> Sent: Monday, October 23, 2006 12:57 PM
> To: abc@comlab.ox.ac.uk
> Subject: Re: [abc] RE: bug in TM codegen?
>
> I'm somewhat confused about how that change in TMStateMachine could
> have produced the problem you reported. TMStateMachine is, unless I'm
> very mistaken, a highly compile-time concept. It is our representation
> of the NFA, which is in effect partially evaluated to produce
> specialised code.
> There is no representation of the state machine at runtime. So, if this
> were indeed the cause of your issue, I would expect a compile-time NPE
> rather than a runtime one.
>
> Having said that, personally I tend to use LinkedHashSets for their
> predictable iteration order whenever possible -- we've been bitten too
> often by nondeterministic iteration-order bugs.
>
> - Pavel
>
> Eric Bodden wrote:
>
> >Ok, I found out what was causing this. In TMStateMachine I had
> replaced the LinkedHashSet for nodes with an IdentityHashSet.
> Apparently however the indexing codegen relies on the iteration order
> of this hash set. (I am not entirely sure in what way, but it seems to
> be the case. - Any thoughts?) So I just switched back to LinkedHashSet
> and that did the trick.
> >
> >
> >Eric
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Eric Bodden
> >>Sent: Monday, October 23, 2006 12:16 PM
> >>To: 'abc@comlab.ox.ac.uk'
> >>Subject: RE: bug in TM codegen?
> >>
> >>Please ignore my previous mail. It works properly with the HEAD
> >>version. So it's a fault on my side. Sorry!!
> >>
> >>Eric
> >>
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Eric Bodden
> >>>Sent: Monday, October 23, 2006 12:05 PM
> >>>To: 'abc@comlab.ox.ac.uk'
> >>>Subject: bug in TM codegen?
> >>>
> >>>Hi.
> >>>
> >>>I found something that looks a lot like a bug in the code
> generation.
> >>>First I thought it was me doing something silly but the same happens
> >>>
> >>>
> >>in
> >>
> >>
> >>>the main abc branch, too.
> >>>
> >>>If I just compile the attached tracematch with the abc standard
> >>>options, and then run ASyncIteration, I get the following exception:
> >>>
> >>>mucuna ~/workspaces/abc/Test/out $ java -cp .:../../abc-
> >>>
> >>>
> >>tmopt/lib/abc-
> >>
> >>
> >>>runtime.jar ASyncIteration Exception in thread "main"
> >>>java.lang.NullPointerException
> >>> at Constraint$tracematch$0.lookup1(Jasmin)
> >>> at Constraint$tracematch$0.queue(Jasmin)
> >>> at
> >>>ASyncIteration$SyncCheck.afterReturning$1(ASyncIteration.java)
> >>> at ASyncIteration.main(ASyncIteration.java:18)
> >>>
> >>>This happens regardless of whether indexing is enabled or disabled,
> >>>
> >>>
> >>so
> >>
> >>
> >>>I assume that the bug is in ASyncIteration and not in the conjuct or
> >>>disjunct class.
> >>>
> >>>I have the generated jimple attached. It would be great if you guys
> >>>could look into this ASAP because it prevents some of my benchmarks
> >>>from running.
> >>>
> >>>Cheers,
> >>>Eric
> >>>
> >>>--
> >>>Eric Bodden
> >>>Sable Research Group, McGill University Montréal, Québec, Canada
> >>>
> >>>
> >>>
> >
> >
> >
> >
> >
>
Received on Mon Oct 23 18:01:03 2006