trying to track down cause of a crash-- selinux? gtk? ghc?

[Garrett Mitchener]

I wrote a multithreaded GUI program for a research project using gtk2hs,
and it works fine on fedora 17, which uses ghc 7.0.4.  It crashes almost as
soon as it starts when compiled and run on fedora 18 (ghc 7.4.1).  There's
a message on the console that it was killed because of a segmentation fault
and that's about all it tells me.  I tracked down the code that causes
crash, and it seems to happen because I add an action to the gtk loop:

timeoutAddFull action ...

and the crash happens when the action runs the first time.  I thought it
was a bug in ghc 7.4.1, because I found a bug report that talks about a
crash involving STM and multithreading, and supposedly was fixed in 7.4.2.
So I set up a virtual machine and installed fedora 18 then upgraded it to
rawhide to try my program under 7.4.2.  But, the same crash happens on my
rawhide machine.

However, it happened that I had to disable selinux on my rawhide machine
using the boot command line because something started going wrong, still
not sure what (hey, it's rawhide).  Now my program does not crash.  I just
tested this on my fedora 18 laptop (still ghc 7.4.1) using both the version
compiled on fedora 18 and the files from where I compiled it on rawhide:
when I disable selinux, my program runs fine, but when it's enabled (even
if set to permissive rather than enforcing) my program seg faults.

There's nothing useful in /var/log/messages, no indication of what selinux
is unhappy about.  I did find this:
http://www.haskell.org/pipermail/haskell-cafe/2007-August/031120.html but
at least in that problem, there was a definite error message about memory
mapping, and I'm not getting one.

So as best I can tell, ghc 7.4.1&2 must both be doing something strange,
maybe marking some piece of memory as data instead of code, maybe when
performing calls to gtk, maybe in building thunks for use by
timeoutAddFull, and eventually triggering a security problem.

My program is huge, and I'm trying to narrow down the problem, but it must
be some unexpected interaction between ghc's newer run time systems, gtk,
and selinux.

I've posted a bug report with a small program that generates the same error:

http://hackage.haskell.org/trac/ghc/ticket/7629

In the mean time, has anyone else run into this problem?

-- Garrett Mitchener

[Jens-Ulrik Petersen]

Hi Garrett - this is new to me. 

Does setroubleshoot show anything? Usually it does when there is an attempted selinux
violation. 

You might also want to try asking the gtk2hs upstream if they know anything about this -
they might have some idea. 

I can try to look at your report from ghc trac later perhaps. 

Anyway feel free to open a Fedora bug to track it - even though it might not be specific
to Fedora. 

Jens 

>  So as best I can tell, ghc 7.4.1&2 must both be doing something
>  strange, maybe marking some piece of memory as data instead of code,
>  maybe when performing calls to gtk, maybe in building thunks for use
>  by timeoutAddFull, and eventually triggering a security problem. 
>  :
>  http://hackage.haskell.org/trac/ghc/ticket/7629