Hello,
I am trying to load a Haskell module in a C program as a
dynamically-loaded plugin via FFI.
I am able to compile and link successfully, but I find the following crash.
#0 0x7f16147da9e7 in ?? () from /usr/lib/ghc/libHSrts_debug-ghc7.4.1.so
#1 0x7f16147e0970 in hs_init_ghc ()
: 19 March 2009 05:00
To: Zachary Turner
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Crash in GHCI - what is the correct behavior
here?
On Wed, Mar 18, 2009 at 10:55 PM, Zachary Turner
wrote:
Regarding the "black hole detection", is GHCI supposed to exit
after pr
On Wed, Mar 18, 2009 at 10:55 PM, Zachary Turner wrote:
> Regarding the "black hole detection", is GHCI supposed to exit after
> printing ? Or is just supposed to print then return to a GHCI
> prompt? Here's a transcript:
>
> C:\Documents and Settings\Zach>ghci
> GHCi, version 6.10.1: http://ww
On Wed, Mar 18, 2009 at 11:46 PM, Luke Palmer wrote:
> 2009/3/18 Zachary Turner
>
>> Basically just learning haskell, I would have posted this in the beginners
>> list but since it involves a segfault of GHCI, I figured it might be worth
>> posting here.
>>
>> I was trying to get a good understa
2009/3/18 Zachary Turner
> Basically just learning haskell, I would have posted this in the beginners
> list but since it involves a segfault of GHCI, I figured it might be worth
> posting here.
>
> I was trying to get a good understanding of local variable scoping issues,
> so I tried the follow
Basically just learning haskell, I would have posted this in the beginners
list but since it involves a segfault of GHCI, I figured it might be worth
posting here.
I was trying to get a good understanding of local variable scoping issues,
so I tried the following:
f :: (Num a) => a -> a
f x =
We have a program that uses the GHC API to dynamically compile and run new
code.
We're using GHC 6.10.1
Under GHCi it works fine under OSX, but when running it on Windows, I get
Loading package ghc-prim ...
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
_hs_gtWord
--- On Fri, 10/24/08, Derek Elkins <[EMAIL PROTECTED]> 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
>
On Fri, 2008-10-24 at 17:16 -0400, John Dorsey wrote:
> 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 nee
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
> >
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,
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
s
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 nat
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+...
replac
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 nati
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 be
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 o
On Thu, Oct 23, 2008 at 1:26 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> 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...
Curiously, the tool I often use with C/C++ to
D.V. wrote:
On Thu, Oct 23, 2008 at 10:30 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
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
Now that's cool. I wish my Amiga still worked.
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
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
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
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 ?
d
On Oct 23, 2008, at 15:35 , Andrew Coppin wrote:
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
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 t
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.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PRO
> 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
>
> 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.
so how would a bug in GTK or in libpng demonstrate itself ?
J. Garrett Morris wrote:
On Thu, Oct 23, 2008 at 11:00 AM, Andrew Coppin
<[EMAIL PROTECTED]> 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
On Thu, Oct 23, 2008 at 11:00 AM, Andrew Coppin
<[EMAIL PROTECTED]> 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
fail :: IO Int
fail = peek nullPtr
main = fail >>= print
/g
--
I am in here
_
Well what do you know? I have actually managed to write a pure Haskell
program that generates an actual access violation when run! o_O
I was under the impression that this is impossible, so I'm now slightly
worried.
The weird thing is, I spent 4 hours using the program without issue.
However
Brandon S. Allbery KF8NH wrote:
On Jan 28, 2008, at 17:33 , Jamie Love wrote:
Shouldn't haskell pick up that there is no 'mod' for Word8? I mean,
shouldn't I get a nicer error message?
Hm? mod works fine for Word8, unless you specify a multiple of the
type's bound. I think it's still har
Just to clarify, I know it was my mistake, and so I'm not blaming
Haskell or Ghc. The first few times you realise the compiler isn't a
magic wand that stops you being silly are the hardest.
Jamie Love wrote:
Oh, I see
I wasn't thinking through the code (and I'm still in the honeymoon
phase
Oh, I see
I wasn't thinking through the code (and I'm still in the honeymoon phase
with Haskell, thinking it can do no wrong).
Don Stewart wrote:
jamie.love:
Ah, of course.
Thanks. I removed the hPut and it runs smoothly. I had forgotten that
haskell chooses the types dynamical
On Jan 28, 2008, at 17:33 , Jamie Love wrote:
Shouldn't haskell pick up that there is no 'mod' for Word8? I
mean, shouldn't I get a nicer error message?
Hm? mod works fine for Word8, unless you specify a multiple of the
type's bound. I think it's still hard for compilers to catch that
jamie.love:
>Ah, of course.
>
>Thanks. I removed the hPut and it runs smoothly. I had forgotten that
>haskell chooses the types dynamically.
>
>Shouldn't haskell pick up that there is no 'mod' for Word8? I mean,
>shouldn't I get a nicer error message?
Well, it inferred Word
Ah, of course.
Thanks. I removed the hPut and it runs smoothly. I had forgotten that
haskell chooses the types dynamically.
Shouldn't haskell pick up that there is no 'mod' for Word8? I mean,
shouldn't I get a nicer error message?
Don Stewart wrote:
jamie.love:
Hi there,
Not sure wh
jamie.love:
> Hi there,
>
> Not sure where to raise bugs in hackage libraries, so I'm posting here.
> If there is a better place, please let me know.
>
> The following code crashes with a divide by zero error when using the
> package 'binary-0.4.'
>
Oh, hehe. \x -> x `mod` 256 doesn't work i
jamie.love:
> Hi there,
>
> Not sure where to raise bugs in hackage libraries, so I'm posting here.
> If there is a better place, please let me know.
>
> The following code crashes with a divide by zero error when using the
> package 'binary-0.4.'
Can you repeat this with binary 0.4.1 please?
I should point out that this is on GHC 6.8.2 compiled from source on a
Mac powerpc.
Jamie Love wrote:
Hi there,
Not sure where to raise bugs in hackage libraries, so I'm posting
here. If there is a better place, please let me know.
The following code crashes with a divide by zero error w
Hi there,
Not sure where to raise bugs in hackage libraries, so I'm posting here.
If there is a better place, please let me know.
The following code crashes with a divide by zero error when using the
package 'binary-0.4.'
module Main where
import IO
import Data.Binary
import Data.Binary.P
41 matches
Mail list logo
