J. Garrett Morris wrote:

On Thu, Oct 23, 2008 at 11:00 AM, Andrew Coppin wrote:

...

I was under the impression that this is impossible, so I'm now slightly worried.

I'm not sure why you'd think that:

import Foreign

Well yeah, if you directly access low-level stuff, it's quite easy to make your program crash. The point is... I'm not doing that. Gtk2hs is, but that's a well-tested library, so I very much doubt it's the source of the bug.

The point is... I'm not doing that. Gtk2hs is, but that's a well-tested

...

library, so I very much doubt it's the source of the bug.

so how would a bug in GTK or in libpng demonstrate itself ? i'm wondering, wouldn't it be a segfault ? does just wrapping them in some fancy haskell typed functions turn every library into a safe, typed haskell code ?

Sure it would, but the type system helps prevent programmers from misusing the (hopefully correctly implemented) functions and thus triggering an error due to bad input (ex: a pointer freed memory). And as Andrew said, GTK and its bindings are well tested so he is doubting that as the cause. I wouldn't rule it out so fast, but GHC has compiled pure code and crashed for me before, so its shouldn't be surprising either way. As for fixing this problem, is there a bit more detailed error you could provide, Andrew? Tom

In my experience it's pretty common for crashes to occur well after the original violation, if you stray off the path far enough into the stack or other fixed data structures. Have you tried reformulating without using unsafeWrite, but using the safe writeArray alternative, to ensure that it's not an accidental stack smash or other uncouth behavior? -Ross Andrew Coppin wrote:

Thomas DuBuisson wrote:

...

The point is... I'm not doing that. Gtk2hs is, but that's a well-tested library, so I very much doubt it's the source of the bug.

so how would a bug in GTK or in libpng demonstrate itself ? i'm wondering, wouldn't it be a segfault ? does just wrapping them in some fancy haskell typed functions turn every library into a safe, typed haskell code ?

Sure it would, but the type system helps prevent programmers from misusing the (hopefully correctly implemented) functions and thus triggering an error due to bad input (ex: a pointer freed memory). And as Andrew said, GTK and its bindings are well tested so he is doubting that as the cause. I wouldn't rule it out so fast, but GHC has compiled pure code and crashed for me before, so its shouldn't be surprising either way.

This is the first time I've ever seen a Haskell program crash. (Unless you purposely do something Very Bad to it - e.g., it crashes pretty good if you try to run it without the GTK+ DLLs available, or run it on an ancient version of Windows or something.)

...

As for fixing this problem, is there a bit more detailed error you could provide, Andrew?

The problem arives inside a large, complicated program. The program draws some stuff into an IOUArray, runs a convolution over it, and then uses the GDK to write into a Pixbuf, which it then saves to a PNG file. The IOUArray stuff is done using unsafeWrite, but that's the only "unsafe" function used in the program. Usually the program works flawlessly. However, if you ask it to draw to a certain combination of coordinates, the program crashes. It's output indicates that it's drawn to the IOUArray, it's run the convolution, and it's trying to save the PNG file... but then a message pops up saying "the generated code caused an access violation" and the program stops. (And sure enough, an incomplete PNG file exists in the filesystem - so it really has crashed part-way through writing it.)

Theoretically, feeding invalid coordinates to the program might make it run off the end of the IOUArray (or maybe off the beginning of it), but I don't see what that has to do with GTK+...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Bulat Ziganshin wrote:

Hello Andrew,

Thursday, October 23, 2008, 11:42:04 PM, you wrote:

...

Theoretically, feeding invalid coordinates to the program might make it run off the end of the IOUArray (or maybe off the beginning of it), but I don't see what that has to do with GTK+...

replace unsafe writes with simple ones and try again

It would be *so much* nicer if both of them had the same type signature... (But I won't hold my breath for that change to happen!)

Brandon S. Allbery KF8NH wrote:

On Oct 23, 2008, at 14:31 , Andrew Coppin wrote:

...

The point is... I'm not doing that. Gtk2hs is, but that's a well-tested library, so I very much doubt it's the source of the bug.

Gtk+, on the other hand, can be quite buggy.

Gtk+ buggy? Are we talking about the same Gtk+ that runs on the desktop of 50% of all the Linux machines on the plannet? Well, I've never noticed any problems with it... ;-)

Brandon S. Allbery KF8NH wrote:

On Oct 23, 2008, at 15:35 , Andrew Coppin wrote:

...

Gtk+ buggy?

Are we talking about the same Gtk+ that runs on the desktop of 50% of all the Linux machines on the plannet?

Well, I've never noticed any problems with it... ;-)

I've found it fairly easy to crash on multiple Linux distributions (never mind the non-Linux ones). Run it with all defaults, it's *probably* okay... don't try to configure it. (I used to crash the control center all the time just by trying to look at all the available themes, before I gave up and switched to KDE.)

Really? Well I've never ever seen GNOME crash. Hell, I run a GNOME desktop on a 0.01 GHz Amiga 1200 and it works! (Sure, it's slower than MS Vista on an 8086, but technically it "works"... just absurdly slowly...) And that's not even an Intel system.

newsham:

...

The point is... I'm not doing that. Gtk2hs is, but that's a well-tested library, so I very much doubt it's the source of the bug.

I don't understand why Haskell users believe (perhaps are too often led to believe) that haskell programs can't crash. Gtk2hs does a lot of native stuff. Gtk's been around for a long time, but so has a lot of other software that has lots of bugs still present in it. Often these bugs lead to memory corruption and crashes. Haskell does nothing to prevent this from happening (how could it?).

Haskell programs with particular constraints (i.e. pure, total Haskell, doesn't primarily call gtk...) -- Don

Quoth Tim Newsham:

...

Haskell programs with particular constraints (i.e. pure, total Haskell, doesn't primarily call gtk...)

Yup, and that's a great thing that we should be evangelizing to all potential users. No need to go overboard and tell them that there will never be a crash, though.. The robustness claim is strong enough without embellishment.

Pure, total Haskell programs may blow the stack. Just what is the concise, compelling, unembellished claim regarding Haskell's inherent robustness? Regards, John Dorsey

--- On Fri, 10/24/08, Derek Elkins wrote:

...

Just what is the concise, compelling, unembellished claim regarding Haskell's inherent robustness?

The concise, compelling, unembellished claim is: if your "pure*" Haskell program segfaults (or GPFs) then it's the implementation's fault, not yours. [unless your OS/Arch is stupid]

This isn't unique to Haskell, every memory-safe language has it.

* "pure" as in "100% pure Java" which has similar claims

But Java's 'claim' actually works out to be easier to reason about: generally, with Java, no matter what 3rd party code you are using, without looking at the source, you know the only way (excluding a JVM/platform bug) that your code will segfault or otherwise corrupt the runtime system is if the 3rd party code includes native libraries (i.e. is non-100% pure Java -- the third party code is more than just collection of jar files). Whereas with Haskell code, you can't really know if it is safe (in this sense) without looking at the code in the Haskell libraries you're using. A library that is 100% Haskell can be doing unsafe things *in Haskell*. Further, many safe Haskell libraries require the use of 'unsafe' functions, so there's no (afaik) simple rubric for determining if a library is safe, and hence whether a program will be segfault (or memory corruption) free. With the advent of the 'haskell platform' it seems to me that the situation could improve -- given that the platform has been 'blessed', you could reason that as long as you stick to libraries that are in the platform or libraries that are free of 'unsafe' functions or FFI (or any other known pitfalls), you've got a safe executable (and then, if it segfaults, you can blame the platform). It would be extremely clever if your build tool could take advantage of this and tell you whether your executable was 'safe' in this sense, based on its analysis of the packages (or even functions) used to build it. (Or perhaps this is already a solved problem and I just don't know about it!)

On Fri, 2008-10-24 at 19:22 +0100, Andrew Coppin wrote:

Tim Newsham wrote:

...

...

The point is... I'm not doing that. Gtk2hs is, but that's a well-tested library, so I very much doubt it's the source of the bug.

I don't understand why Haskell users believe (perhaps are too often led to believe) that haskell programs can't crash. Gtk2hs does a lot of native stuff. Gtk's been around for a long time, but so has a lot of other software that has lots of bugs still present in it. Often these bugs lead to memory corruption and crashes. Haskell does nothing to prevent this from happening (how could it?).

I entirely expect that this crash is due to Gtk2hs (well-tested though it may be) or one of its underlying dependencies (such as libpng).

Nope. Actually it was me being dumb with unchecked array access. Nothing wrong with GHC, GTK+ or even Gtk2hs.

I, for one, am completely unsurprised. Haskell doesn't make you smarter than you are when programming in C. If you are using unsafe functions you have a very significant burden of proof to acquire before you can say it is the compiler or run-time or a mature library, though there are certainly bugs in all of those.