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 <djsamp...@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 <marlo...@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.colpi...@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 <marlo...@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 >>>>>> <simo...@microsoft.com <mailto:simo...@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 >>>> >> _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs