<div dir="ltr">Is it possible your analysis is depending on the order of graph traversal? That is, do you ever use in-hash on the hasheq, and if so is it possible the results of your analysis would change if in-hash produced hash table entries in a different order? Same for in-hash-keys or in-hash-values, obviously. </div><div class="gmail_extra"> <div>Carl Eastlund</div> <div class="gmail_quote">On Tue, Aug 27, 2013 at 6:58 PM, J. Ian Johnson <<a href="mailto:ianj@ccs.neu.edu" target="_blank">ianj@ccs.neu.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Weird you can't repro. I only use hasheq when I know the keys are symbols, or the table is local and only used for a graph traversal (where the graph is not changing during traversal). -Ian <div class="HOEnZb"><div class="h5">----- Original Message ----- From: "Matthew Flatt" <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> To: "J. Ian Johnson" <<a href="mailto:ianj@ccs.neu.edu">ianj@ccs.neu.edu</a>> Cc: "dev" <<a href="mailto:dev@racket-lang.org">dev@racket-lang.org</a>> Sent: Tuesday, August 27, 2013 6:33:02 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] Output value of program changes depending on whether I pretty-print an opaque struct value I haven't been able to get a different result by changing printing. One thing that printing might do, however, is assign `eq?`-based hash codes to objects that did not already have them. That assignment, in turn, could affect the order in which objects appear later in a hash table. I hacked Racket to make the internal hash-code generator count down instead of up, and I was able to get a different result that way. Are you using `eq?`-based hashing at all? Could there be some dependency on the order of values within a hash table (or hash set)? At Tue, 27 Aug 2013 14:02:50 -0400 (EDT), "J. Ian Johnson" wrote: > This is mostly an mflatt-only problem. > > My analysis framework is now using a generic dictionary for its abstract heap, > and depending on whether or not I pretty-print this heap before continuing on > analyzing, the result of the analysis changes (sound versus unsound). I found > the problem doing some printf debugging, and when fixed, I tried removing the > print statements. The answer changed. There must be some problem in the C code > somewhere, because this is just bonkers. > > (Note: I've had previous bugs where rewriting a (begin (void) e) => e caused a > similar value-changing bug. Updating the compiler to head fixed it at that > point. I'm running yesterday's HEAD now, though.) > > <a href="https://github.com/dvanhorn/oaam/tree/thocon" target="_blank">https://github.com/dvanhorn/oaam/tree/thocon</a> > > See the ;; mflatt: comment in code/kcfa.rkt > > To see the problem, > racket code/run-benchmark.rkt --lcg benchmarks/temp-c/sort2.sch > > Thanks, > -Ian > _________________________ > Racket Developers list: > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </div></div></blockquote></div> </div>