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

Since I am reweaving, prepareForMatching(..) is called multiple times, however it always call renumberStates() in the end, so I am a little confused too about why it breaks. Anyway, since it's working ok for me now, I would just keep it as is. I will add an additional comment to the set, stating that it must be a linked hash set.

Eric

> -----Original Message-----
> From: Majordomo list server [mailto:majordomo@comlab.ox.ac.uk] On
> Behalf Of Pavel Avgustinov
> Sent: Monday, October 23, 2006 1:08 PM
> To: abc@comlab.ox.ac.uk
> Subject: Re: [abc] RE: bug in TM codegen?
>
> The numbering of the nodes indeed relies on repeatable iteration order.
> I believe I wrote something to that effect in the comment; if not, I
> apologise. You'll find that the 'renumber' method simply iterates
> nodes, assigning incremental integers. This is by design.
>
> Still, surely iteration order should only change if you add nodes at a
> strange time, and I would have expected an additional call to
> 'renumber', to ensure consistency, would be all that's required.
>
> - P
>
> Eric Bodden wrote:
>
> >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:13:16 2006