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.)