Thomas DuBuisson wrote:
So if you have such a specific portion of the code you think is to
blame, perhaps you could simple comment that out (return () instead of
write the file) and see if it crashes? I understand people avoidance
of brute force guess problem-compile-test cycles, but it seems you
have good evidence supporting this guess.
Yeah, I can try different optimisation levels and so forth.
I'm actually wondering if my code is writing off the end of an array and
this "just happens" to hit some data structure used by GTK+? (In which
case, minute changes in linkage, etc., would disturb the bug.)
Does anybody know of any tools for definitely pinning down stuff like
this? Surely C programmers have their code crash several hundred times a
day due to bugs like this...
Also, be sure the thunks are evaluated - if the writing of the file
is what is forcing the evaluation (and thus triggering the condition)
then you need to separate these two cases.
That's the fun part about Haskell, eh? ;-)
However, in this instance, there's that much explicit mutation in the
I/O monad on unboxed (and therefore strict) arrays that I'm pretty sure
that isn't the problem. By the time the save-PNG function is called, the
data already exists in the address space managed by GTK+. It has to, or
GTK+ wouldn't be able to save it.
Unless my *pure* code is somehow generating an access violation - which
would surely indicate an actual compiler *bug*... (This seems laughably
unlikely.)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
