andrewcoppin at btinternet.com
Thu Oct 23 16:26:04 EDT 2008
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
More information about the Haskell-Cafe