"Exit code: ExitFailure 11" when trying yesod devel

[Daniel Santa Cruz]

Hello all,

I have tried to start my journey into Haskell web development tonight, but I seem to have hit a few snags. I'm on a Mac, using OS X 10.7.3, with ghc 7.4.1 installed via homebrew, and cabal-install-0.14.0 installed from source.

On a completely clean ghc install (i.e. after removing ~/.ghc and ~/.cabal), an attempt at: "cabal install yesod-platform" failed, due to language-javascript requiring a version of happy >= 1.18.5 but could not be found. Interestingly, installing happy by itself installs 1.18.9. Attempting an install of the yesod-platform after that seemed to work like a charm.

I then followed the instructions to create a scaffolded site via "yesod init", specifying sqlite as my database. Trying to do "yesod devel" on my site complained about persistence-sqlite missing, which was trivial to fix -- I assume that this is not installed when doing the yesod-platform because there are multiple options available. Once that was done, I tried to do the "yesod devel" again, only to be met with:

> yesod devel

Yesod devel server. Press ENTER to quit

Resolving dependencies...

Configuring demo-0.0.0...

Rebuilding application...

Building demo-0.0.0...

Preprocessing library demo-0.0.0...

Registering demo-0.0.0...

Starting development server: runghc -package-confdist/package.conf.inplace devel.hs

Starting devel application

Devel application launched: http://localhost:3000

Exit code: ExitFailure 11

Did I miss something along the way? Is there any other debugging information I can provide?

Thanks,

Daniel

[Luite Stegeman]

On Fri, May 4, 2012 at 4:25 AM, Daniel Santa Cruz <dst...@gmail.com> wrote:

> Yesod devel server. Press ENTER to quit
> Resolving dependencies...
> Configuring demo-0.0.0...
> Rebuilding application...
> Building demo-0.0.0...
> Preprocessing library demo-0.0.0...
> Registering demo-0.0.0...
> Starting development server: runghc -package-confdist/package.conf.inplace
> devel.hs
> Starting devel application
> Devel application launched: http://localhost:3000
> Exit code: ExitFailure 11

This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
to make a smaller test case, or to find out more about why this
happens. If you do, please report, perhaps we can narrow it down to
open a ticket.

The only fix I've found is downgrading to GHC 7.0.4, a few weeks ago
the latest STABLE snapshots still had this problem, so unless we can
find this soon, this will probably be a problem in the next Haskell
platform release.

luite

[Michael Snoyman]

Just to confirm: does this issue only exist on Mac? I just tested on a
Linux machine (LMDE 64-bit) with no issues.

Michael

[Luite Stegeman]

On Fri, May 4, 2012 at 1:20 PM, Michael Snoyman <mic...@snoyman.com> wrote:

> Just to confirm: does this issue only exist on Mac? I just tested on a
> Linux machine (LMDE 64-bit) with no issues.

Yes, mac only, possibly only 64 bit. (System here: OS X 10.7.3, 64 bit
GHC, xcode 4.3 with llvm-gcc i686-apple-darwin11-llvm-gcc-4.2 (GCC)
4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) )

luite

[Greg Weber]

I recommend using a VM (not just for Haskell, but anything you would
deploy to Linux) on Mac if you have 8G of memory (and can easily spare
some for your VMs). When the new Haskell Platform comes out I want to
create a downloadable VM.

Greg Weber

[Michael Snoyman]

While that might be a good short term solution to the problem, and good general advice for making sure code runs smoothly on the production server, it's not a good long term response to this problem. Mac users should be able to run Yesod locally. Hopefully our GSoC project will help fix this, but if anyone running a Mac has time to try and isolate this bug, I'd appreciate it.

[Luite Stegeman]

On Fri, May 4, 2012 at 3:34 PM, Michael Snoyman <mic...@snoyman.com> wrote:
> While that might be a good short term solution to the problem, and good
> general advice for making sure code runs smoothly on the production server,
> it's not a good long term response to this problem. Mac users should be able
> to run Yesod locally. Hopefully our GSoC project will help fix this, but if
> anyone running a Mac has time to try and isolate this bug, I'd appreciate
> it.
>

I've already spent some time on this, but so far without any success.
I've tried gdb and valgrind (the latter needs some extra syscall
wrappers to support the ghc runtime on 64 bit OS X), but haven't been
able to narrow it down in any way. Does anyone have suggestions for
strategies or tools that might help here? Valgrind reports some
invalid memory accesses, but haskell being haskell, getting
information about where and why is a whole different matter...

luite

[Michael Snoyman]

I have no advice, and without a Mac, can't really help too much. It might be worth turning to the cafe or the GHC team for some advice at this point. At the very least, it's good if they know that there's some regression in the 7.4 series.

Michael

[Greg Weber]

Have you tried the new profiling-based stack trace feature? I have not yet.

[Luite Stegeman]

On Fri, May 4, 2012 at 3:44 PM, Michael Snoyman <mic...@snoyman.com> wrote:

> I have no advice, and without a Mac, can't really help too much. It might be
> worth turning to the cafe or the GHC team for some advice at this point. At
> the very least, it's good if they know that there's some regression in the
> 7.4 series.

I've asked/mentioned this in the #ghc irc channel a few times but
without any results (Simon Marlow is often there). No ticket yet
because the test case (default yesod scaffold) isn't terribly useful
for tracking down the bug.

luite

[Luite Stegeman]

On Fri, May 4, 2012 at 3:49 PM, Greg Weber <gr...@gregweber.info> wrote:
> Have you tried the new profiling-based stack trace feature? I have not yet.

Haven't tried it yet, but i thought that would only help with stack
traces from haskell exceptions, not with segfaults. Do you know if it
should?

luite

[Greg Weber]

With profiling there should be some kind of information on how the
program is executing that is always present. It should be possible to
log function calls while the program is running. This is all
theoretical though, I haven't tried it. Probably I am giving really
bad advice :)

[Lyndon Maydwell]

This is the exact issue I'm trying to resolve now.

I've built 4 different versions of GHC as updating GHC seemed to
resolve it in the past. The problem seems to be related to runghc on
devel.hs as I was able to launch the server fine when I used the
binary. I'll be more than happy to help resolve this as I love Yesod
when it's all working smoothly, but it is a real pain when a large
chunk of time is taken up dealing with this issue.

On Wed, Jun 20, 2012 at 4:34 PM, srhb <sbro...@gmail.com> wrote:
> Hi,

>
> On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:
>>
>> This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
>> to make a smaller test case, or to find out more about why this
>> happens. If you do, please report, perhaps we can narrow it down to
>> open a ticket.
>
>

> This error still persists on GHC 7.4.2
>
> -- Sarah

[Michael Snoyman]

I'd like to get this resolved as well, but I have no access to a Mac system, and even if I did, my complete lack of experience on that platform probably wouldn't help.

Here's a simple question: are you able to compile and run devel.hs?

Michael

[Lyndon Maydwell]

I seem to recall being able to do this earlier today, although I can't
confirm as I've blown away my Haskell install again.

[Rodrigo Gadea]

On Wed, Jun 20, 2012 at 6:57 AM, Lyndon Maydwell <mayd...@gmail.com> wrote:

I seem to recall being able to do this earlier today, although I can't
confirm as I've blown away my Haskell install again.

Yeh, don't tell anyone but Haskell's package system (cabal et al.) really sucks. I don't think the "reinventing the wheel" approach is valid here, scale is showing that despite of "programming / sysadmin-on-spare-time", the package system has to be reviewed in order to keep "growing" on a "stable manner". That said (as the *ssh*le of Torvalds said), I find darcs way better than git (it's more bazaar-esque), so it's surprising (to me) that having a such a good vcs they didn't spoke between them. (Heading to AR (tomorrow) - will see if I can make it for Rants Friday).

[Lyndon Maydwell]

It looks like I probably recalled incorrectly :)

The compiled version of devel.hs has the same issue, although there is
no error code listed on exit.

Example session:

lyndon@endpin ~/temp/Foo yesod devel

Yesod devel server. Press ENTER to quit
Resolving dependencies...

Configuring Foo-0.0.0...
Rebuilding application...
Building Foo-0.0.0...
Preprocessing library Foo-0.0.0...
[1 of 8] Compiling Settings.Development ( Settings/Development.hs,
dist/build/Settings/Development.o )
[2 of 8] Compiling Model ( Model.hs, dist/build/Model.o )
[3 of 8] Compiling Settings ( Settings.hs, dist/build/Settings.o )
[4 of 8] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs,
dist/build/Settings/StaticFiles.o )
[5 of 8] Compiling Foundation ( Foundation.hs, dist/build/Foundation.o )
[6 of 8] Compiling Import ( Import.hs, dist/build/Import.o )
[7 of 8] Compiling Handler.Home ( Handler/Home.hs,
dist/build/Handler/Home.o )
[8 of 8] Compiling Application ( Application.hs, dist/build/Application.o )
Registering Foo-0.0.0...

Starting development server: runghc
-package-confdist/package.conf.inplace devel.hs
Starting devel application
Devel application launched: http://localhost:3000
Exit code: ExitFailure 11

lyndon@endpin ~/temp/Foo ghc --make devel.hs
[1 of 1] Compiling Main ( devel.hs, devel.o )
Linking devel ...
lyndon@endpin ~/temp/Foo ./devel

Starting devel application
Devel application launched: http://localhost:3000

Migrating: CREATE TABLE "user"("id" INTEGER PRIMARY KEY,"ident"
VARCHAR NOT NULL,"password" VARCHAR NULL,CONSTRAINT "unique_user"
UNIQUE ("ident"))
Migrating: CREATE TABLE "email"("id" INTEGER PRIMARY KEY,"email"
VARCHAR NOT NULL,"user" INTEGER NULL REFERENCES "user","verkey"
VARCHAR NULL,CONSTRAINT "unique_email" UNIQUE ("email"))
lyndon@endpin ~/temp/Foo ./devel

Starting devel application
Devel application launched: http://localhost:3000

lyndon@endpin ~/temp/Foo

[Michael Snoyman]

Could you try removing the forkIO call in `main` in devel.hs? Also, what happens if you keep the file the same, but compile with -threaded?

[Lyndon Maydwell]

ForkIO and -threaded changes don't seem to have had any impact.

[Ricardo Boccato Alves]

Not sure if this helps, but I only got this error with the 64bit
version of the Haskell Platfom (2012.2.0.0), when I switched to the
32bits version the problem stopped.

I am a Haskell newbie, but if there are any tests you want me to do
I'll be happy to help. I am using a MacBookPro Core2 duo, 4GB with OSX
10.7 (lion).

[]s,

[Max Cantor]

I got this alot when using cabal dev.  Since I started using hsenv (formerly virthualenv) and regular yesod devel the problem went away.

Max

[Vincent Ambo]

This error only happens when using the 64bit version of GHC.

Am 20.06.2012 um 10:34 schrieb srhb:

Hi,

On Friday, May 4, 2012 6:37:24 AM UTC+2, Luite Stegeman wrote:

This is probably a bug in GHC 7.4.1. Unfortunately I haven't been able
to make a smaller test case, or to find out more about why this
happens. If you do, please report, perhaps we can narrow it down to
open a ticket.

[Lyndon Maydwell]

I am also running a 64 bit GHC.

I'm leaning more towards GHC issue than Yesod issue at this point but
that's just a guess :)

[Michael Snoyman]

Based on everything I've heard, it *is* a GHC issue. I think Luite has
said as much in the past. The problem is that we don't have a simple
test case to reproduce. I do think that it would be worthwhile filing
a report with GHC and explain that we haven't been able to whittle the
problem down yet, and see if they have any advice.

[Lyndon Maydwell]

I'd love to file a report, but as you say, the test case is so broad
at the moment that I fear it would be next to useless. I've actually
got a spare Mac that I can set up and provide a shell to if anyone
wants to try to help narrow it down but doesn't have a Mac available.

[Michael Snoyman]

If you're able to set up such a server, please let me know, I'd like
to take a crack at this. No guarantees on *when* I could...

Michael

[Lyndon Maydwell]

I've been attempting to set up the box with Lion so that the
environment matches the one where I've been experiencing the issues,
however there is a hard-coded ram minimum.

I'll let you know once I've found a work-around or upgraded the ram.

[Felipe Almeida Lessa]

On Fri, Jun 29, 2012 at 1:30 PM, Andy Kitchen <kitche...@gmail.com> wrote:
> It's almost certainly a ghc bug
> but is it triggered when one tries to do sql migrations. So it could
> actually be the sqlite3 driver.

Can you reproduce it with persistent-postgresql or persistent-mysql?

Cheers,

--
Felipe.

[Andy Kitchen]

I'm not sure one will get a lot of information out of that experiment.

If you can be more specific about the question that you are trying to answer

I may be able to help devise some procedure.

Oh FYI, This is a program that doesn't segfault crash when compiled and run

but does crash when run with runghc/ghci on 7.4.2 on mac os x.

[Andy Kitchen]

Also, bad news, program runs fine under gdb.

ran with a guarded memory allocator, no dice,

didn't detect any bad memory use.

[Andy Kitchen]

I've the output of valgrind and dtruss, no smoking gun.

valgrind --leak-check=yes --trace-children=yes /opt/local/lib/ghc-7.4.2/runghc -f /opt/local/bin/ghc bug.hs > valgrind.out 2>&1

sudo dtruss -f /opt/local/lib/ghc-7.4.2/runghc -f /opt/local/bin/ghc bug.hs >dtruss.out 2>&1

[Michael Snoyman]

Given that you've worked this bug down to a much simpler reproducing
case, would it be possible to file a bug with GHC?

Michael

[Andy Kitchen]

Given that you've worked this bug down to a much simpler reproducing
case, would it be possible to file a bug with GHC?

If you think that is best, please do Michael. I'm not comfortable

submitting it as a bug because I don't really know much

about the internals of persistent and yesod. There is still

a moderate probability that this is just a latent bug in persistent-sqlite.

BSD/Mac OS X are different enough to expose quite a few bugs in

event battle tested code.

Kindest regards

AK

[Daniel Trebbien]

I tried your test case, but did not see an error.

$ ghc bug.hs

...

$ ./bug

$

Running under gdb, "Program exited normally."

Is there something that I should try?

Daniel Trebbien

On Friday, June 29, 2012 12:30:33 PM UTC-4, Andy Kitchen wrote:

Well, it turns out that it was relatively simple to isolate where in Yesod the bug is triggered.

Here is a minimal program that causes the segfault. It's almost certainly a ghc bug

but is it triggered when one tries to do sql migrations. So it could actually be the sqlite3 driver. 

On Friday, May 4, 2012 12:25:21 PM UTC+10, Daniel Santa Cruz wrote:

Hello all,

I have tried to start my journey into Haskell web development tonight, but I seem to have hit a few snags. I'm on a Mac, using OS X 10.7.3, with ghc 7.4.1 installed via homebrew, and cabal-install-0.14.0 installed from source.

On a completely clean ghc install (i.e. after removing ~/.ghc and ~/.cabal), an attempt at: "cabal install yesod-platform" failed, due to language-javascript requiring a version of happy >= 1.18.5 but could not be found. Interestingly, installing happy by itself installs 1.18.9. Attempting an install of the yesod-platform after that seemed to work like a charm.

I then followed the instructions to create a scaffolded site via "yesod init", specifying sqlite as my database. Trying to do "yesod devel" on my site complained about persistence-sqlite missing, which was trivial to fix -- I assume that this is not installed when doing the yesod-platform because there are multiple options available. Once that was done, I tried to do the "yesod devel" again, only to be met with:

> yesod devel

Yesod devel server. Press ENTER to quit

Resolving dependencies...

Configuring demo-0.0.0...

Rebuilding application...

Building demo-0.0.0...

Preprocessing library demo-0.0.0...

Registering demo-0.0.0...

Starting development server: runghc -package-confdist/package.conf.inplace devel.hs

Starting devel application

Devel application launched: http://localhost:3000

Exit code: ExitFailure 11

Did I miss something along the way? Is there any other debugging information I can provide?

Thanks,

Daniel

[Alan Pogrebinschi]

I'm seeing this bug (OSX 10.7.4, GHC 7.4.1 64-bit) and I have no dependency on persistent-sqlite. Using persistent-mysql though.

Regards,

Alan

[Lyndon Maydwell]

Thanks Andy.

The reduced test-case seems to trigger the bug for me.

I'll see if I can reduce it any further.

[Luite Stegeman]

On Sun, Jul 1, 2012 at 3:14 PM, Lyndon Maydwell <mayd...@gmail.com> wrote:
> Thanks Andy.
>
> The reduced test-case seems to trigger the bug for me.
>
> I'll see if I can reduce it any further.

The crash occurs in the open call of the sqlite example, somewhere in
initializing sqlite in foreign code. no yesod dependencies are needed.
the haskell side of things looks ok, there might be some heap
corruption...

luite

[Luite Stegeman]

Ok, new test case, looks like it has to do with global structs:

# gcc -c str.c
# ghci strhs.hs str.o
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) str.o ... done
final link ... done
Ok, modules loaded: Main.
Prelude Main> main
Segmentation fault: 11
# ghc strhs.hs str.c
Linking strhs ...
# ./strhs
x: 0
x: 1

luite

[Luite Stegeman]

Test case works fine on linux btw, both ghci and as a compiled binary

[Lyndon Maydwell]

Confirmed with gcc, and clang.

i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.9.00)
Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)

[Lyndon Maydwell]

Looks like this is somehow related to the ghci / runhaskell wrapper as
ghc --interactive doesn't segfault:

lyndon@endpin ~/temp/bug2 ghc --interactive strhs.hs str.o

GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) str.o ... done
final link ... done

[1 of 1] Compiling Main ( strhs.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
x: 0
x: 1
*Main>
Leaving GHCi.

lyndon@endpin ~/temp/bug2 ghci strhs.hs str.o

GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) str.o ... done
final link ... done

[1 of 1] Compiling Main ( strhs.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
[1] 24729 segmentation fault ghci strhs.hs str.o
exit 139

[Luite Stegeman]

On Sun, Jul 1, 2012 at 4:04 PM, Lyndon Maydwell <mayd...@gmail.com> wrote:
> Looks like this is somehow related to the ghci / runhaskell wrapper as
> ghc --interactive doesn't segfault:

It does here, but sometimes it runs fine

luite

[Lyndon Maydwell]

After repeated runs it segfaulted. Probably some unallocated memory
access causing the nondeterminism?

[Luite Stegeman]

On Sun, Jul 1, 2012 at 4:41 PM, Lyndon Maydwell <mayd...@gmail.com> wrote:
> After repeated runs it segfaulted. Probably some unallocated memory
> access causing the nondeterminism?

Not sure, i think it might have something to do with the GHCi linker
not playing nice with global data. Issue is reported as ghc ticket
#7040 ( http://hackage.haskell.org/trac/ghc/ticket/7040 ), with a
slightly simplified version of the test case.

luite