Opened 10 years ago

Closed 10 years ago

#3789 closed bug (fixed)

Segfault and -dstg-lint errors using FFI and -XEmptyDataDecls

Reported by: judahj Owned by:
Priority: high Milestone: 6.12.2
Component: Compiler (NCG) Version: 6.12.1
Keywords: Cc:
Operating System: MacOS X Architecture: x86
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I encountered a segfault when working with some FFI code. I eventually discovered that this code also makes -dstg-lint complain.

With the below files, I can reproduce the segfault and -dstg-lint issues using ghc-6.12.1 and ghc-6.10.3 on OS X 10.6.2. The segfault goes away if I use -fvia-C, -O, or if I build on OS X 10.5.7.

The segfault also goes away if I use a unit type () instead of -XEmptyDataDecls.

$ ghc --make test-segfault.hs foreign.c -XForeignFunctionInterface \
        -XEmptyDataDecls -fforce-recomp && ./test-segfault 
[1 of 2] Compiling Types            ( Types.hs, Types.o )
[2 of 2] Compiling Main             ( test-segfault.hs, test-segfault.o )
Linking test-segfault ...
About to create...
Segmentation fault


#include <stdio.h>
#include <stdlib.h>

void *
c_createFoo (int x) {
    fprintf(stderr,"Creating foo...\n");
    int *p = malloc(sizeof(int));
    *p = x;
    return p;


module Types where

import Foreign.Ptr
import Foreign.C.Types

-- Replacing this line with the following one prevents the segfault,
-- but not the -dstg-lint error.
data Foo_
-- type Foo_ = ()

foreign import ccall safe c_createFoo :: CInt -> IO (Ptr Foo_)

createFoo :: Int -> IO (Ptr Foo_)
createFoo dtype = c_createFoo (toEnum dtype)


module Main where

import Types

main = do
    putStrLn "About to create..."
    createFoo 1
    putStrLn "Created."

The -dstg-lint error is somewhat long, but I can paste it if you're unable to reproduce it.

Change History (7)

comment:1 Changed 10 years ago by simonmar

Milestone: 6.12.2
Priority: normalhigh

comment:2 Changed 10 years ago by simonpj

I'm afraid the STG Lint failures reflect a bug in STG Lint, not in the program. I've fixed STG Lint:

Mon Jan  4 13:46:59 PST 2010
  * Fix bugs in STG Lint
  The Stg Lint failure reported in Trac #3789 were bogus.
  This patch fixes STG Lint, which must have been unused
  for ages.

    M ./compiler/stgSyn/StgLint.lhs -18 +13

However, the underlying seg-fault is unaffected. Since it happens with -fasm but not with -fvia-C it must be in the code generator.

I believe that the machine code (and STG code) generated from type Foo_ = () and data Foo_ should be identical. A good first step would be to see how they differ.


comment:3 Changed 10 years ago by simonmar

Unable to reproduce the segfault on x86/Linux (Ubuntu 9.10) with either 6.10.4 or 6.12.1. Can anyone else reproduce it? Is it MacOS X only perhaps?

comment:4 Changed 10 years ago by igloo

I can't reproduce it on OS X here, but then I only have 10.5, and judahj says it only happens for him on 10.6.

comment:5 Changed 10 years ago by igloo

I've merged the "Fix bugs in STG Lint" patch to the 6.12 branch.

comment:6 Changed 10 years ago by simonmar

Just a hunch, but I wonder if this is now fixed as a result of

Sat Feb 27 17:39:51 GMT 2010  Ian Lynagh <>
  * Fix trac #2578
  We define empty datatypes as not being enumerations, which means the
  empty blocks aren't generated.

Could someone on OS X test?

comment:7 Changed 10 years ago by judahj

Resolution: fixed
Status: newclosed

The test runs for me without crashing using ghc-6.13.20100321. So I guess that patch (or one like it) fixed the problem.

Note: See TracTickets for help on using tickets.