GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:05:04Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15404ghc-8.6 uninstallable on macos due to hard coded libgmp directory2019-07-07T18:05:04ZTrevor L. McDonellghc-8.6 uninstallable on macos due to hard coded libgmp directoryIt is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path.
See the offending...It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path.
See the offending `LC_LOAD_DYLIB` command here:
```
$ jtool -l libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib
LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT
Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal)
Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs)
Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal)
Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals)
Mem: 0x0004df760-0x0004e0f40 __TEXT.__const
Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info
LC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA
Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs)
Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs)
Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs)
Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs)
Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const
Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data
Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill)
LC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT
LC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib
LC 04: LC_DYLD_INFO
LC 05: LC_SYMTAB
Symbol table is at offset 0x6a5348 (6968136), 118090 entries
String table is at offset 0x873d78 (8863096), 3241616 bytes
LC 06: LC_DYSYMTAB
81438 local symbols at index 0
35948 external symbols at index 81438
704 undefined symbols at index 117386
No TOC
No modtab
1380 Indirect symbols at offset 0x8727e8
LC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA
LC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0
LC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0
LC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib
LC 11: LC_LOAD_DYLIB @rpath/libHSinteger-gmp-1.0.2.0-ghc8.6.0.20180714.dylib
LC 12: LC_LOAD_DYLIB @rpath/libHSghc-prim-0.5.3-ghc8.6.0.20180714.dylib
LC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib
LC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib
LC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0
LC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3
LC 17: LC_RPATH @loader_path/../rts
LC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions
LC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348)
```
The other offenders are `libHSbinary` and `libHSinteger-gmp`.
Without changing these load commands, you'll get the following error:
```
$ ./configure --prefix=...
$ make install
<snip>
dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib
Referenced from: ./libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib
Reason: image not found
make[1]: *** [install_packages] Abort trap: 6
make: *** [install] Error 2
```
I tried passing the `--with-gmp-libraries` option to `configure`, but that did not help.
I guess this is just a packaging problem, but figured you should be aware before the official release...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-8.6 uninstallable on macos due to hard coded libgmp directory","status":"New","operating_system":"","component":"None","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path.\r\n\r\nSee the offending `LC_LOAD_DYLIB` command here:\r\n\r\n{{{\r\n$ jtool -l libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib\r\nLC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT\r\n Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal)\r\n Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs)\r\n Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal)\r\n Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals)\r\n Mem: 0x0004df760-0x0004e0f40 __TEXT.__const\r\n Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info\r\nLC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA\r\n Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs)\r\n Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs)\r\n Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs)\r\n Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs)\r\n Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const\r\n Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data\r\n Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill)\r\nLC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT\r\nLC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib\r\nLC 04: LC_DYLD_INFO\r\nLC 05: LC_SYMTAB\r\n Symbol table is at offset 0x6a5348 (6968136), 118090 entries\r\n String table is at offset 0x873d78 (8863096), 3241616 bytes\r\nLC 06: LC_DYSYMTAB\r\n 81438 local symbols at index 0\r\n 35948 external symbols at index 81438\r\n 704 undefined symbols at index 117386\r\n No TOC\r\n No modtab\r\n 1380 Indirect symbols at offset 0x8727e8\r\n\r\nLC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA\r\nLC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0\r\nLC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0\r\nLC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib\r\nLC 11: LC_LOAD_DYLIB @rpath/libHSinteger-gmp-1.0.2.0-ghc8.6.0.20180714.dylib\r\nLC 12: LC_LOAD_DYLIB @rpath/libHSghc-prim-0.5.3-ghc8.6.0.20180714.dylib\r\nLC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib\r\nLC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib\r\nLC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0\r\nLC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3\r\nLC 17: LC_RPATH @loader_path/../rts\r\nLC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions\r\nLC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348)\r\n}}}\r\n\r\nThe other offenders are `libHSbinary` and `libHSinteger-gmp`.\r\n\r\nWithout changing these load commands, you'll get the following error:\r\n\r\n{{{\r\n$ ./configure --prefix=...\r\n$ make install\r\n<snip>\r\ndyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib\r\n Referenced from: ./libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib\r\n Reason: image not found\r\nmake[1]: *** [install_packages] Abort trap: 6\r\nmake: *** [install] Error 2\r\n}}}\r\n\r\nI tried passing the `--with-gmp-libraries` option to `configure`, but that did not help.\r\n\r\nI guess this is just a packaging problem, but figured you should be aware before the official release...","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/152711e1000000000 :: Double yields 0.0 instead of Infinity2019-07-07T18:13:30Zclaude1e1000000000 :: Double yields 0.0 instead of Infinity(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd...(This bug report is about the incorrect result not the poor performance.)
Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64):
```
$ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e100000000 :: Double
Infinity
(5.70 secs, 68,552 bytes)
Prelude> 1e1000000000 :: Double
0.0
(69.35 secs, 60,088 bytes)
```
Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases.
More precisely,
```
Prelude> 1e646457008 :: Double
Infinity
(40.80 secs, 64,272 bytes)
Prelude> 1e646457009 :: Double
0.0
(40.46 secs, 60,088 bytes)
```
Note:
```hs
(floor $ 2^31 / logBase 2 10 + 16) == 646457009
```
This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?).
Standalone test program:
```hs
main = do
print 1e646457008
print 1e646457009
```
Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help).
```
$ ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set +s
Prelude> 1e646457008 :: Double
Infinity
(415.26 secs, 17,908 bytes)
Prelude> 1e646457009 :: Double
Infinity
(417.66 secs, 17,820 bytes)
Prelude> 1e746457298 :: Double
Infinity
(490.00 secs, 17,820 bytes)
Prelude> 1e1000000000 :: Double
GNU MP: Cannot allocate memory (size=419438600)
Aborted
$
```
`ghci-8.0.2` on Debian Buster amd64 exhibits the problem also.8.6.3Zhou FangyiZhou Fangyihttps://gitlab.haskell.org/ghc/ghc/-/issues/15105`typecheckModule` from GHC API crashes on MacOS for files with TH2019-07-07T18:14:15ZAlec Theriault`typecheckModule` from GHC API crashes on MacOS for files with THI believe this is the same issue that is causing manually built `haddock` and `doctest` to crash on MacOS when fed TH (originally reported https://github.com/haskell/haddock/issues/767 and https://github.com/sol/doctest/issues/199).
I'v...I believe this is the same issue that is causing manually built `haddock` and `doctest` to crash on MacOS when fed TH (originally reported https://github.com/haskell/haddock/issues/767 and https://github.com/sol/doctest/issues/199).
I've attached a minimal program that uses the GHC API and exhibits the same problem.
```
$ ghc-8.4.2 -package ghc -package containers -package ghc-paths Prog.hs
[1 of 1] Compiling Main ( Prog.hs, Prog.o )
Linking Prog ...
$ ./Prog Main-no-TH.hs -package template-haskell
$ ./Prog Main-TH.hs -package template-haskell
Prog:
lookupSymbol failed in relocateSection (RELOC_GOT)
/usr/local/lib/ghc-8.4.2/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands'
Prog: Prog: unable to load package `integer-gmp-1.0.2.0'
```
In case it isn't clear, I do not expect `Main-TH.hs` to crash `Prog`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`typecheckModule` from GHC API crashes on MacOS for files with TH","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I believe this is the same issue that is causing manually built `haddock` and `doctest` to crash on MacOS when fed TH (originally reported https://github.com/haskell/haddock/issues/767 and https://github.com/sol/doctest/issues/199).\r\n\r\nI've attached a minimal program that uses the GHC API and exhibits the same problem.\r\n\r\n{{{\r\n$ ghc-8.4.2 -package ghc -package containers -package ghc-paths Prog.hs\r\n[1 of 1] Compiling Main ( Prog.hs, Prog.o )\r\nLinking Prog ...\r\n$ ./Prog Main-no-TH.hs -package template-haskell\r\n$ ./Prog Main-TH.hs -package template-haskell\r\nProg:\r\nlookupSymbol failed in relocateSection (RELOC_GOT)\r\n/usr/local/lib/ghc-8.4.2/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands'\r\nProg: Prog: unable to load package `integer-gmp-1.0.2.0'\r\n}}}\r\n\r\nIn case it isn't clear, I do not expect `Main-TH.hs` to crash `Prog`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/14758Retainer profiler can overflow the C stack2019-07-07T18:15:44ZBen GamariRetainer profiler can overflow the C stackI'm not entirely sure what conditions trigger this, but I am observing a reliable segmentation fault with a program with large heap compiled with 8.4.1-alpha3 and run with retainer profiling enabled. Judging by the fact that the crashing...I'm not entirely sure what conditions trigger this, but I am observing a reliable segmentation fault with a program with large heap compiled with 8.4.1-alpha3 and run with retainer profiling enabled. Judging by the fact that the crashing instruction is a `mov _, ($rsp)`, I'm reasonable certain that the issue is a C stack overflow. The top of the stack looks like,
```
#0 0x000000000249212c in retainClosure (c0=0x42af3459b8, cp0=cp0@entry=0x42af347000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1488
#1 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347000, bitmap=<optimized out>, size=<optimized out>, p=0x42af347260) at rts/RetainerProfile.c:1209
#2 retainStack (c=c@entry=0x42af347000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347370) at rts/RetainerProfile.c:1350
#3 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686
#4 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3473e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695
#5 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3473e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347690) at rts/RetainerProfile.c:1209
#6 retainStack (c=c@entry=0x42af3473e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347750) at rts/RetainerProfile.c:1350
#7 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345d88, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686
#8 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3477c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695
#9 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3477c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347a70) at rts/RetainerProfile.c:1209
#10 retainStack (c=c@entry=0x42af3477c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347b30) at rts/RetainerProfile.c:1350
#11 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3481a8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686
#12 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af347ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695
#13 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347ba0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347e50) at rts/RetainerProfile.c:1209
#14 retainStack (c=c@entry=0x42af347ba0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347f10) at rts/RetainerProfile.c:1350
#15 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348408, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686
#16 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695
#17 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af349000, bitmap=<optimized out>, size=<optimized out>, p=0x42af3492b0) at rts/RetainerProfile.c:1209
#18 retainStack (c=c@entry=0x42af349000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349370) at rts/RetainerProfile.c:1350
#19 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348668, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686
#20 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3493e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695
#21 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3493e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349690) at rts/RetainerProfile.c:1209
#22 retainStack (c=c@entry=0x42af3493e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349750) at rts/RetainerProfile.c:1350
#23 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3488c8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686
#24 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3497c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695
#25 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3497c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349a70) at rts/RetainerProfile.c:1209
#26 retainStack (c=c@entry=0x42af3497c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349b30) at rts/RetainerProfile.c:1350
#27 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686
#28 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695
...
```
and this goes on for at least 30000 frames. It looks very much like this is a bug in the retainer profiler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1-alpha1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Retainer profiler can overflow the C stack","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1-alpha1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm not entirely sure what conditions trigger this, but I am observing a reliable segmentation fault with a program with large heap compiled with 8.4.1-alpha3 and run with retainer profiling enabled. Judging by the fact that the crashing instruction is a `mov _, ($rsp)`, I'm reasonable certain that the issue is a C stack overflow. The top of the stack looks like,\r\n{{{\r\n#0 0x000000000249212c in retainClosure (c0=0x42af3459b8, cp0=cp0@entry=0x42af347000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1488 \r\n#1 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347000, bitmap=<optimized out>, size=<optimized out>, p=0x42af347260) at rts/RetainerProfile.c:1209 \r\n#2 retainStack (c=c@entry=0x42af347000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347370) at rts/RetainerProfile.c:1350 \r\n#3 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 \r\n#4 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3473e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 \r\n#5 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3473e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347690) at rts/RetainerProfile.c:1209 \r\n#6 retainStack (c=c@entry=0x42af3473e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347750) at rts/RetainerProfile.c:1350 \r\n#7 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345d88, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 \r\n#8 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3477c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 \r\n#9 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3477c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347a70) at rts/RetainerProfile.c:1209 \r\n#10 retainStack (c=c@entry=0x42af3477c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347b30) at rts/RetainerProfile.c:1350 \r\n#11 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3481a8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 \r\n#12 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af347ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 \r\n#13 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347ba0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347e50) at rts/RetainerProfile.c:1209 \r\n#14 retainStack (c=c@entry=0x42af347ba0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347f10) at rts/RetainerProfile.c:1350 \r\n#15 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348408, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 \r\n#16 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 \r\n#17 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af349000, bitmap=<optimized out>, size=<optimized out>, p=0x42af3492b0) at rts/RetainerProfile.c:1209 \r\n#18 retainStack (c=c@entry=0x42af349000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349370) at rts/RetainerProfile.c:1350 \r\n#19 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348668, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 \r\n#20 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3493e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 \r\n#21 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3493e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349690) at rts/RetainerProfile.c:1209 \r\n#22 retainStack (c=c@entry=0x42af3493e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349750) at rts/RetainerProfile.c:1350 \r\n#23 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3488c8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 \r\n#24 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3497c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 \r\n#25 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3497c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349a70) at rts/RetainerProfile.c:1209 \r\n#26 retainStack (c=c@entry=0x42af3497c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349b30) at rts/RetainerProfile.c:1350 \r\n#27 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 \r\n#28 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 \r\n...\r\n}}}\r\nand this goes on for at least 30000 frames. It looks very much like this is a bug in the retainer profiler.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3Alexander VershilovAlexander Vershilov