May 2014 - ghc-tickets

[GHC] #8935: Obscure linker bug leads to crash in GHCi
by GHC 02 May '14

02 May '14

#8935: Obscure linker bug leads to crash in GHCi ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a build of GHC (with `DYNAMIC_GHC_PROGRAMS=NO`) that exhibits the following crash: {{{ $ ghc -e 'System.Environment.getEnvironment' <segfault> }}} I tracked it down, eventually, to a bad reference to the symbol `environ` from `__hscore_environ` in `libraries/base/includes/HsBase.h`. Somehow, `environ` had got linked to the wrong address. Lots more investigation lead me to discover this: `internal_dlsym()` in `Linker.c` tries to look up a symbol in all the different shared libraries we have loaded so far, one by one. (see be497c202b790999c3fd0ddc4a4176b8cf6acf7e). Unfortunately, this seems to break things in my case. Here's a simple test program that works on Ubuntu 12.04: {{{ #include <dlfcn.h> #include <stdio.h> char *so = "/usr/lib/x86_64-linux-gnu/libgmp.so"; char *so2 = "/usr/lib/x86_64-linux-gnu/libpthread.so"; extern char**environ; int main(int argc, char *argv[]) { void *deflt, *hdl; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); printf("environ = %p\n", &environ); printf("dlsym(deflt, \"environ\") = %p\n", dlsym(deflt,"environ")); hdl = dlopen(so, RTLD_LAZY); printf("dlsym(\"libgmp\", \"environ\") = %p\n", dlsym(hdl,"environ")); hdl = dlopen(so2, RTLD_LAZY); printf("dlsym(\"libpthread\", \"environ\") = %p\n", dlsym(hdl,"environ")); } }}} And the output: {{{ environ = 0x601040 dlsym(deflt, "environ") = 0x601040 dlsym("libgmp", "environ") = 0x2aaaab290568 dlsym("libpthread", "environ") = 0x601040 }}} Note that the value we get from looking up `environ` in `libgmp` is different to the others. The correct value is `0x601040`. gdb thinks that `0x2aaaab290568` is also `environ`: {{{ (gdb) p4 0x2aaaab290568 0x2aaaab290580 <buflen.9817>: 0x0 0x2aaaab290578: 0x0 0x2aaaab290570 <miss_F_GETOWN_EX>: 0x0 0x2aaaab290568 <environ>: 0x0 }}} but note that it contains zero. The real one is: {{{ (gdb) p4 0x601040 0x601058: 0x0 0x601050 <dtor_idx.6533>: 0x0 0x601048 <completed.6531>: 0x0 0x601040 <environ@@GLIBC_2.2.5>: 0x7fffffffe268 }}} In GHC we're loading `libgmp` when we load the `integer-gmp` package, and this causes future references to `environ` to go wrong. I've locally fixed this by changing `internal_dlsym` to `dlsym`, but since there was a reason to make this change in the first place I haven't pushed it to master. Suggestions welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #9065: Segfault in a memory-heavy program
by GHC 02 May '14

02 May '14

#9065: Segfault in a memory-heavy program ----------------------------------+---------------------------------- Reporter: rotsor | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I've got a program compiled with GHC 7.6.3 crashing with "Segmentation fault". It does not crash with GHC 7.8.2 so the bug might have been fixed already. This is the backtrace I'm getting from gdb: {{{ #0 0x00000000004a0450 in alloc_mega_group () #1 0x00000000004a0930 in allocGroup.part.1 () #2 0x00000000004c3c00 in alloc_todo_block () #3 0x00000000004c3d73 in todo_block_full () #4 0x0000000000403df9 in evacuate () #5 0x00000000004051e4 in scavenge_block () #6 0x00000000004bf785 in scavenge_loop () #7 0x00000000004a16c5 in GarbageCollect () #8 0x0000000000499d6f in scheduleDoGC.isra.21 () #9 0x000000000049a81d in scheduleWaitThread () #10 0x000000000049e1be in real_main () #11 0x000000000049e2bc in hs_main () #12 0x0000000000418a8b in main () }}} The problem only triggers when I run the program on large input values: it uses 7Gb of memory and dies after 7 minutes of runtime. The version compiled with 7.8.2 exhibits similar memory usage pattern, but successfully completes within 15 minutes. Compiler command line I use: {{{ ghc -O2 -rtsopts eu468 }}} RTS command line: {{{ ./eu468 +RTS -K1000000000 }}} The program in question is eu468.hs at https://github.com/Rotsor/euler.git. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack
by GHC 01 May '14

01 May '14

#8933: process007: internal error: checkStackFrame: weird activation record found on stack ------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: process007 Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------------- On an unregisterised compiler process007 segfaults in all WAYS. Here is a stack trace from a run with {{{+RTS -DS}}} on an x86_64 machine: {{{ Starting program: /home/trp/research/ghc- unreg/ghc-7.8/libraries/process/tests/process007 +RTS -DS [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". cap 0: initialised process007: internal error: checkStackFrame: weird activation record found on stack (0x7ffff69050b8 281051976). (GHC version 7.8.0.20140324 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 #1 0x00007ffff6a96cd8 in abort () from /lib64/libc.so.6 #2 0x00000000008172af in rtsFatalInternalErrorFn ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).", ap=0x7fffffffd968) at rts/RtsMessages.c:170 #3 0x0000000000816ee7 in barf ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).") at rts/RtsMessages.c:42 #4 0x00000000008355e2 in checkStackFrame (c=0x7ffff69050b8) at rts/sm/Sanity.c:165 #5 0x000000000083560a in checkStackChunk (sp=0x7ffff69050b8, stack_end=0x7ffff6905390) at rts/sm/Sanity.c:177 #6 0x0000000000836100 in checkSTACK (stack=0x7ffff6905000) at rts/sm/Sanity.c:497 #7 0x0000000000836254 in checkTSO (tso=0x7ffff6905390) at rts/sm/Sanity.c:535 #8 0x000000000082625a in threadStackOverflow (cap=0xd79740 <MainCapability>, tso=0x7ffff6905390) at rts/Threads.c:500 #9 0x000000000082226a in schedule ( initialCapability=0xd79740 <MainCapability>, task=0xd9a4e0) at rts/Schedule.c:528 #10 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcc0) at rts/Schedule.c:2346 #11 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcc0, p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500 #12 0x00000000008272de in real_main () at rts/RtsMain.c:63 #13 0x00000000008273d1 in hs_main (argc=3, argv=0x7fffffffde48, main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...) at rts/RtsMain.c:114 #14 0x000000000040849f in main () }}} Running without the RTS flags: {{{ Program received signal SIGSEGV, Segmentation fault. 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81 81 f = (StgFunPtr) (f)(); (gdb) where #0 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81 #1 0x0000000000822022 in schedule ( initialCapability=0xd79740 <MainCapability>, task=0xd9a470) at rts/Schedule.c:463 #2 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcd0) at rts/Schedule.c:2346 #3 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcd0, p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500 #4 0x00000000008272de in real_main () at rts/RtsMain.c:63 #5 0x00000000008273d1 in hs_main (argc=1, argv=0x7fffffffde58, main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...) at rts/RtsMain.c:114 #6 0x000000000040849f in main () }}} The value of f in StgRun looks strange the first three bytes are the same as basereg {{{0xd79758}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7