No, no, it does not look bad at all. The address looks strange but
#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]: 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