GHC status report
Dominick Samperi
djsamperi at gmail.com
Fri May 2 05:57:49 UTC 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 <djsamperi at gmail.com> 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 <marlowsd at gmail.com> 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
>>> <george.colpitts at gmail.com> 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 <marlowsd at gmail.com> 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
>>>>>> <simonpj at microsoft.com <mailto:simonpj at 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 at haskell.org <mailto:ghc-devs at haskell.org>
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>
More information about the ghc-devs
mailing list