Re: GHC status report

2 May 2014


      The problems I was seeing with ghci prior to 7.8 are similar to the
ones reported by Edward Kmett above: addresses were mapped
incorrectly. This was compounded by the fact that the
library used was not thread-safe, so there were two issues,
which may explain why -fno-ghci-sandbox did not help.

On Thu, May 1, 2014 at 8:09 PM, Dominick Samperi  wrote:
...
It turns out that the 7.8 update fixed problems that were NOT
fixed by using -fno-ghci-sandbox with earlier versions of ghci,
like 7.6.3, so this flag by itself did not address the issue. I
assumed (perhaps incorrectly) that a full explanation must
include the new dynamic linking support.
With 7.6.3 the problem arises when using FFI and embeded R, which
involves linking to its shared library libR.so. Linking seems to be
successful, but the program crashes when run, with a message
about C stack overflow and/or a segfault. (Note that this does not
happen when the program is compiled using ghc...only ghci has
the problem.)
On the stack space question, embedded R tries to detect when
C stack space is exhausted by inspecting the address of variables
allocated in a function call, using code something like
this (in R src/main/errors.c):
void (R_CheckStack)(void)
{
    int dummy;
    intptr_t usage = R_CStackDir * (R_CStackStart - (uintptr_t)&dummy;
    ...
}
The seg fault happens with ghci 7.6.3 with or without the flag
-fno-ghci-sandbox.
With 7.8.2 the seg fault happens if the flag -fno-ghci-sandbox is
omitted; with the flag everything works fine.
If I understand your last comment correctly linking to libR should
continue to work, even if you revert to static linking of Haskell compiled
code via RTS linker. Since you say this is the way things have always
been, perhaps the real explanation for why 7.8 fixed the issue is that
some bug was fixed along the way...
Note that R is a C library, so the C++ issues that Carter mentions are
not a factor here.
Thanks,
Dominick
On Thu, May 1, 2014 at 5:27 PM, Simon Marlow  wrote:
...
On 01/05/14 14:48, Dominick Samperi wrote:
...
The problem with some graphics libraries used via FFI (and other libraries
that are not thread-safe), if I understand the situation correctly, is
that ghci
forks a thread when it shouldn't, causing some programs to miscalculate
the available stack space (because they think there is only one thread).
...
The new dynamic linking support and the flag -fno-ghci-sandbox fixes
this problem, and I would not vote for the removal of these features.
So I understand how -fno-ghci-sandbox avoids problems with GUI libraries
that use thread-local state.  But how is dynamic linking involved here?
What improved in GHC 7.8 relative to 7.6 for you? And could you clarify
"miscalculate the available stack space"? What needs to calculate stack
space? Why? C stack space?
We can certainly make a smoother experience around -fno-ghci-sandbox for
using GUI libraries.
...
It is not clear to me from Simon's original post how linking to all of
those C++ libs can continue to work if dynamic linking is removed
in 7.10? Perhaps I misunderstand what you mean by "revert to
static linking"?
When I say "revert to static linking" I mean make GHCi static linked, and
have it load Haskell code compiled for static linking using the RTS linker
(like it did in 7.6).  Foreign libraries would still be loaded using the
system linker, as they always have been.
To be clear, I'm not officially proposing that we drop dynamic linking, but
I think it's worthwhile exploring the design space again, given that we know
dynamic linking has been tougher than we expected.
Cheers,
Simon
...
Thanks,
Dominick
On Wed, Apr 30, 2014 at 9:26 PM, George Colpitts
 wrote:
...
To elaborate, in the past, I had a lot of problems using libraries from
the
ghci prompt on the Mac but I haven't tried recently.
As an example, on the web page for the book the Haskell School of
Expression
it says:
Note for OS X users: running graphics applications from GHCi is no longer
supported. Instead, one has to compile a graphics program using GHC in
order
to run it (see example/GMIExamples.lhs for an example).
I had similar problems using the Yale Euterpea music program from ghci.
When
I inquired I was referred to https://ghc.haskell.org/trac/ghc/ticket/4244
and https://ghc.haskell.org/trac/ghc/ticket/781. I see that the latter is
now scheduled for 7.10.1
On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow  wrote:
...
On 30/04/2014 01:35, George Colpitts wrote:
...
It doesn't have anything about the dynamic linking changes made for
7.8.
I think it's worth mentioning the improvements we expect to get from
that. The highlights of the release notes do mention it, so maybe that
suffices.
In particular, I'm hoping that it is going to fix a lot of problems
with
using foreign libraries such as OpenGL from ghci. I could be wrong
about
that though.
I'd like to understand more about what those problems are.  As a data
point, at Facebook we're using static linking (I compiled GHC with
DYNAMIC_GHC_PROGRAMS=NO), we're loading upwards of 50 3rd-party C++
libraries and one gigantic shared library consisting of a ton of
in-house
C++ code, together with all our Haskell code into GHCi, and it works
perfectly.  The key to using the static linker is to not use it for C++
code
- you want all your external C++ code in shared libraries and load those
using the system linker.
Dynamic linking has been a huge headache in GHC, and it's not clear that
it's an overall improvement compared with the static linker.  Now that
7.8
is out of the way, it's time to have a conversation about whether we
want to
do dynamic linking again for 7.10, or revert to static linking.  I think
Austin is going to update
https://ghc.haskell.org/trac/ghc/wiki/DynamicGhcPrograms, and then we'll
see
where we stand.
Cheers,
Simon
...
On Tue, Apr 29, 2014 at 6:13 PM, Simon Peyton Jones
mailto:simonpj@microsoft.com> wrote:
As Austin has told us, there's a draft of the *GHC Status Report
for
     the HCAR*, here:____
https://ghc.haskell.org/trac/ghc/wiki/Status/May14____
Have we missed out something  you have been working hard on?  Do
     take a moment to add a bullet in an appropriate place (it's a
     wiki).  I'd like to be sure that we are giving credit to all the
     appropriate people, so please help us fix that too.  GHC is a team
     effort.____
Deadline is 1 May I think.____
Thanks____
Simon____
__ __
_______________________________________________
     ghc-devs mailing list
     ghc-devs@haskell.org mailto:ghc-devs@haskell.org
     http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs