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:08:05 2006