[GHC] #8935: Obscure linker bug leads to crash in GHCi

GHC ghc-devs at haskell.org
Tue May 6 21:22:03 UTC 2014


#8935: Obscure linker bug leads to crash in GHCi
-------------------------------------+------------------------------------
        Reporter:  simonmar          |            Owner:  simonmar
            Type:  bug               |           Status:  patch
        Priority:  high              |        Milestone:  7.8.3
       Component:  Runtime System    |          Version:  7.8.1-rc2
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  GHCi crash        |       Difficulty:  Rocket Science
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by trommler):

 Replying to [comment:33 simonmar]:
 > > No, no, it does not look bad at all. The address looks strange but
 that is caused by the fact that it was created by the dynamic linker. Look
 at *defl_env and *env in the second program in comment:25. The addresses
 match and I checked they really point to the environment array!
 >
 > Well, every time we call `dlsym` passing the handle of a `dlopen`'d
 library, we get a bogus result.  This happens for both `libgmp` and
 `libpthread` (after modifying the `libpthread` path to point to the real
 .so, not the linker script).

 Yes, that is consistent with what I expect from our previous experiments.

 I don't say I understand yet why the dynamic linker gives us a broken
 symbol and if this behavior is correct. What I know is that the dynamic
 linker treats weak symbols the same as strong symbols. And then there is a
 conflict: In the program there is a symbol `environ` created by the static
 linker and now there is another symbol `environ` and that is not permitted
 and instead of failing we get this `NULL` pointer.

 I bet all libraries that depend on libc directly or indirectly will
 exhibit the behavior we see.

 But that was not my point. I wanted to say, when we look for `environ` in
 `RTLD_DEFAULT` we will get a properly set up pointer to the environment.
 My second test program (in comment:25) was meant to demonstrate that this
 is also true when we do not refer to `environ` in the program itself.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8935#comment:34>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list