GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:27:46Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12070SMP primitives broken on power(pc)2019-07-07T18:27:46ZHerbert Valerio Riedelhvr@gnu.orgSMP primitives broken on power(pc)I originally noticed this when working on the AIX port (32-bit powerpc), and recently saw this also on Linux/powerpc64, which lead to talking to Peter Trommler who already had a suspicion:
Here's for example the CAS definition (in `<stg...I originally noticed this when working on the AIX port (32-bit powerpc), and recently saw this also on Linux/powerpc64, which lead to talking to Peter Trommler who already had a suspicion:
Here's for example the CAS definition (in `<stg/SMP.h>`):
```c
StgWord
cas(StgVolatilePtr p, StgWord o, StgWord n)
{
StgWord result;
__asm__ __volatile__ (
"1: ldarx %0, 0, %3\n"
" cmpd %0, %1\n"
" bne 2f\n"
" stdcx. %2, 0, %3\n"
" bne- 1b\n"
"2:"
:"=&r" (result)
:"r" (o), "r" (n), "r" (p)
:"cc", "memory"
);
return result;
}
```
The important detail is the lack any barrier instructions, such as `isync` at the end. This results in infrequent heap-corruptions which in turn result in all sorts of infrequent and hard to track down runtime-crashes (including in `ghc --make -j`) such as for instance
```
internal error: END_TSO_QUEUE object entered!
(GHC version 8.0.0.20160421 for powerpc64_unknown_linux)
```
Peter has already a patch in the works which simply replaces the atomic powerpc primitives with `__sync_*` intrinsics which turn out to be more portable than inline-asm. This would result in e.g.
```c
StgWord
cas(StgVolatilePtr p, StgWord o, StgWord n)
{
return __sync_val_compare_and_swap (p, o, n);
}
```
which then gets compiled as
```asm
000000000000004c <.cas>:
4c: 7c 00 04 ac sync
50: 7d 20 18 a8 ldarx r9,0,r3
54: 7c 29 20 00 cmpd r9,r4
58: 40 c2 00 0c bne- 64 <.cas+0x18>
5c: 7c a0 19 ad stdcx. r5,0,r3
60: 40 c2 ff f0 bne- 50 <.cas+0x4>
64: 4c 00 01 2c isync
68: 7d 23 4b 78 mr r3,r9
6c: 4e 80 00 20 blr
```
I've been testing the patch already and it seems to have made all issues I experienced so far disappear, as well as fixing the `concprog01` test which was also failing infrequently.8.0.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/11828Linker.c doesn't build on OS X due to signedness mismatch2019-07-07T18:28:22ZBen GamariLinker.c doesn't build on OS X due to signedness mismatch```
rts/Linker.c:6978:59: error:
error: assigning to 'unsigned char *' from 'char *' converts between pointers to integer types with different sign [-Werror,-Wpointer-sign]
oc->symbols[curSymbol].addr...```
rts/Linker.c:6978:59: error:
error: assigning to 'unsigned char *' from 'char *' converts between pointers to integer types with different sign [-Werror,-Wpointer-sign]
oc->symbols[curSymbol].addr = addr;
^ ~~~~
```
Apparently introduced by 90538d86af579595987826cd893828d6f379f35a.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11783Very large slowdown when using parallel garbage collector2019-07-07T18:28:34ZluispedroVery large slowdown when using parallel garbage collectorAs part of debugging some performance issues on an application I am writing, I concluded that the issue is in the parallel GC implemented in the GHC RTS. I extracted the code attached to make a self-contained use-case, but in my system t...As part of debugging some performance issues on an application I am writing, I concluded that the issue is in the parallel GC implemented in the GHC RTS. I extracted the code attached to make a self-contained use-case, but in my system the code runs in 16s when using a single thread, in 18s when using 6 threads but no parallel GC and in over a minute when using 6 threads with parallel GC!
The true slowdown in the full code is actually worse and relevant for the application (some steps take \>1 hour instead of \<1 minute!). Parts of the code do take full advantage of parallel processing, this is just one simple test case.
On some machines it seems worse than others and it seems that the input file (data.txt) needs to be quite large for the problem to really show up (the attached script generates a 16 million input file, this is still smaller than some of my real use cases, but I couldn't trigger it with only 1 million). Similarly, with 4 threads, the slowdown is detectable, but not as large.
While running, CPU usage is very high (I tested with 16 threads and it uses 16 CPUs continuously, top reports 1600% CPU).
Using '+RTS -A64m' is another way around the issue, but for the full application it is still not as effective as '+RTS -qg', so there still seems to be a performance issue here.8.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/11776RTS segfaults when printing profiling information which refers to unloaded ob...2019-07-07T18:28:35ZafarmerRTS segfaults when printing profiling information which refers to unloaded objectsRunning a profiled binary which loads/unloads objects via the RTS's linker results in a CCS tree with pointers to the shared objects. These references are not checked by checkUnload before unloading the object. Then, when the profiling r...Running a profiled binary which loads/unloads objects via the RTS's linker results in a CCS tree with pointers to the shared objects. These references are not checked by checkUnload before unloading the object. Then, when the profiling report is printed at the end of the program, a segfault occurs.
Plan:
1. Add a test case for this.
1. Modify checkUnload to prevent objects from being unloaded if the CCS tree points to them.
1. Modify generateCCSReport to prune the CCS tree after a report is printed.
1. Expose some way to generate a report on demand, so long-running programs don't keep every object loaded forever.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RTS segfaults when printing profiling information which refers to unloaded objects","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"afarmer"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Running a profiled binary which loads/unloads objects via the RTS's linker results in a CCS tree with pointers to the shared objects. These references are not checked by checkUnload before unloading the object. Then, when the profiling report is printed at the end of the program, a segfault occurs.\r\n\r\nPlan:\r\n\r\n1. Add a test case for this.\r\n2. Modify checkUnload to prevent objects from being unloaded if the CCS tree points to them.\r\n3. Modify generateCCSReport to prune the CCS tree after a report is printed.\r\n4. Expose some way to generate a report on demand, so long-running programs don't keep every object loaded forever.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1afarmerafarmerhttps://gitlab.haskell.org/ghc/ghc/-/issues/11487stg_ap_pp_fast doesn't pass the argument in the arity=1 case2019-07-07T18:30:13Zrwbartonstg_ap_pp_fast doesn't pass the argument in the arity=1 caseThe body of `stg_ap_pp_fast` looks like
```
arity = TO_W_(StgFunInfoExtra_arity(%GET_FUN_INFO(R1)));
ASSERT(arity > 0);
if (arity == 1) {
Sp_adj(-2);
W_[Sp+WDS(1)] = R3...The body of `stg_ap_pp_fast` looks like
```
arity = TO_W_(StgFunInfoExtra_arity(%GET_FUN_INFO(R1)));
ASSERT(arity > 0);
if (arity == 1) {
Sp_adj(-2);
W_[Sp+WDS(1)] = R3;
W_[Sp+WDS(0)] = stg_ap_p_info;
R1 = R1 + 1;
jump_SAVE_CCCS(%GET_ENTRY(UNTAG(R1)));
}
if (arity == 2) {
Sp_adj(0);
R1 = R1 + 2;
jump %GET_ENTRY(UNTAG(R1)) [R1,R2,R3];
} else {
Sp_adj(-3);
W_[Sp+WDS(2)] = R3;
W_[Sp+WDS(1)] = R2;
if (arity < 4) {
R1 = R1 + arity;
}
BUILD_PAP(2,2,stg_ap_pp_info,FUN);
}
```
where
```
// Jump to target, saving CCCS and restoring it on return
#if defined(PROFILING)
#define jump_SAVE_CCCS(target) \
Sp(-1) = CCCS; \
Sp(-2) = stg_restore_cccs_info; \
Sp_adj(-2); \
jump (target) [R1]
#else
#define jump_SAVE_CCCS(target) jump (target) [R1]
#endif
```
So in the arity=1 case the jump amounts to
```
jump (%GET_ENTRY(UNTAG(R1))) [R1]
```
R1 is the function to apply, but we don't pass its argument, R2!
Now, possibly by design, the calling convention of `stg_ap_pp_fast` is such that the first argument to apply is in R2, which is the same register that the function R1 will expect to find its argument in. So if nothing happens to disturb R2 (and possibly this is always the case with the NCG), then everything is fine. However, it's definitely not fine for the LLVM backend, which quite reasonably passes `undef` for the R2, R3, and R4 arguments when doing the jump. On arm/Android, LLVM decided to clobber `r8` (the physical register for R2) in the body of `stg_ap_ppp_fast` (which has the same problems as `stg_ap_pp_fast`).
This caused a crash for the following program:
```
main = print (read "3"::Int)
```
when built with `-debug`.
This appears to have been broken by commit f9265dd369b9e269349930012c25e670248f2a09 which changed the argument list for `jump_SAVE_CCCS` from `[*]` to `[R1]`.8.0.1gmainlandgmainlandhttps://gitlab.haskell.org/ghc/ghc/-/issues/11299T5435_gcc_v fails on ARM2023-02-14T11:22:19ZBen GamariT5435_gcc_v fails on ARMThe `rts/T5435_gcc_v` testcase sometimes fails on ARM. As far as I can tell there are two principle failure modes: hanging and segmentation faulting.The `rts/T5435_gcc_v` testcase sometimes fails on ARM. As far as I can tell there are two principle failure modes: hanging and segmentation faulting.8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11269powerpc64le: Build fails in rts/Linker.c2019-07-07T18:31:11ZPeter Trommlerptrommler@acm.orgpowerpc64le: Build fails in rts/Linker.cBuilding HEAD:
```
rts/Linker.c: In function ‘do_Elf_Rel_relocations’:
rts/Linker.c:4978:23: error:
error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
Elf_Addr P = ((Elf_Addr)targ) + o...Building HEAD:
```
rts/Linker.c: In function ‘do_Elf_Rel_relocations’:
rts/Linker.c:4978:23: error:
error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
Elf_Addr P = ((Elf_Addr)targ) + offset;
^
rts/Linker.c:4979:22: error:
error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
Elf_Word* pP = (Elf_Word*)P;
^
```
Fix coming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"powerpc64le: Build fails in rts/Linker.c","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Building HEAD:\r\n{{{\r\nrts/Linker.c: In function ‘do_Elf_Rel_relocations’:\r\n\r\nrts/Linker.c:4978:23: error:\r\n error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]\r\n Elf_Addr P = ((Elf_Addr)targ) + offset;\r\n ^\r\n\r\nrts/Linker.c:4979:22: error:\r\n error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]\r\n Elf_Word* pP = (Elf_Word*)P;\r\n ^\r\n}}}\r\n\r\nFix coming.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/11234GHCi on Windows segfaults2019-07-07T18:31:21ZTamar ChristinaGHCi on Windows segfaultsGHCi on Windows has had a segfault for while now on `x86_64`. During the upgrade of `GCC` in [D1123](https://phabricator.haskell.org/D1123) I noticed that test `prog003` was failing with a segfault.
Currently the segfault exist in both ...GHCi on Windows has had a segfault for while now on `x86_64`. During the upgrade of `GCC` in [D1123](https://phabricator.haskell.org/D1123) I noticed that test `prog003` was failing with a segfault.
Currently the segfault exist in both versions but on `x86` it's particularly easy to trigger.
In my case I can't even start ghci.
```
$ inplace/bin/GHC-stage2.exe --interactive
GHCi, version 7.11.20151213: http://www.haskell.org/ghc/ :? for help
Segmentation fault/access violation in generated code
```
The segfault does not seem to happen when linked to the debug rts, and running with `+RTS -Ds -RTS` doesn't report anything special.
Compiling with `devel2` so the rts gets compiled with `-g` the stack trace is not very useful.
```
(gdb) run --interactive
Starting program: /home/Tamar/ghc/inplace/bin/ghc-stage2 --interactive
[New Thread 108480.0x1960c]
[New Thread 108480.0x19b2c]
[New Thread 108480.0x19c30]
[New Thread 108480.0x1a0a8]
[New Thread 108480.0x1a93c]
[New Thread 108480.0x13954]
[New Thread 108480.0x14440]
GHCi, version 7.11.20151213: http://www.haskell.org/ghc/ :? for help
Program received signal SIGSEGV, Segmentation fault.
0x06843aa5 in ?? ()
(gdb) bt
#0 0x06843aa5 in ?? ()
#1 0x04b82cfc in ?? ()
#2 0x8d078902 in ?? ()
#3 0xc689fd47 in ?? ()
#4 0xff04c583 in ?? ()
#5 0x83c70065 in ?? ()
#6 0x0000033c in ?? ()
#7 0x00000008 in ?? ()
#8 0x04e9c689 in ?? ()
Backtrace stopped: Cannot access memory at address 0x47c70cc8
```
And the output of `p4`
```
(gdb) p4 0x06843aa5
0x6843ab0: 0x330073
0x6843aac: 0x790073 <c1CgU_info+131>
0x6843aa8: 0x6d005c <c1rsa_info+715>
0x6843aa4: 0x3a0045
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi on Windows segfaults","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"Phyx-"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"GHCi on Windows has had a segfault for while now on `x86_64`. During the upgrade of `GCC` in Phab:D1123 I noticed that test `prog003` was failing with a segfault.\r\n\r\nCurrently the segfault exist in both versions but on `x86` it's particularly easy to trigger.\r\n\r\nIn my case I can't even start ghci.\r\n\r\n{{{\r\n$ inplace/bin/GHC-stage2.exe --interactive\r\nGHCi, version 7.11.20151213: http://www.haskell.org/ghc/ :? for help\r\nSegmentation fault/access violation in generated code\r\n}}}\r\n\r\nThe segfault does not seem to happen when linked to the debug rts, and running with `+RTS -Ds -RTS` doesn't report anything special.\r\n\r\nCompiling with `devel2` so the rts gets compiled with `-g` the stack trace is not very useful.\r\n\r\n{{{\r\n(gdb) run --interactive\r\nStarting program: /home/Tamar/ghc/inplace/bin/ghc-stage2 --interactive\r\n[New Thread 108480.0x1960c]\r\n[New Thread 108480.0x19b2c]\r\n[New Thread 108480.0x19c30]\r\n[New Thread 108480.0x1a0a8]\r\n[New Thread 108480.0x1a93c]\r\n[New Thread 108480.0x13954]\r\n[New Thread 108480.0x14440]\r\nGHCi, version 7.11.20151213: http://www.haskell.org/ghc/ :? for help\r\n\r\nProgram received signal SIGSEGV, Segmentation fault.\r\n0x06843aa5 in ?? ()\r\n(gdb) bt\r\n#0 0x06843aa5 in ?? ()\r\n#1 0x04b82cfc in ?? ()\r\n#2 0x8d078902 in ?? ()\r\n#3 0xc689fd47 in ?? ()\r\n#4 0xff04c583 in ?? ()\r\n#5 0x83c70065 in ?? ()\r\n#6 0x0000033c in ?? ()\r\n#7 0x00000008 in ?? ()\r\n#8 0x04e9c689 in ?? ()\r\nBacktrace stopped: Cannot access memory at address 0x47c70cc8\r\n}}}\r\n\r\nAnd the output of `p4`\r\n\r\n{{{\r\n(gdb) p4 0x06843aa5\r\n0x6843ab0: 0x330073\r\n0x6843aac: 0x790073 <c1CgU_info+131>\r\n0x6843aa8: 0x6d005c <c1rsa_info+715>\r\n0x6843aa4: 0x3a0045\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/11223Runtime linker performs eager loading of all object files2021-11-11T17:51:13ZTamar ChristinaRuntime linker performs eager loading of all object filesThe runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting.
If a symbol is needed that isn't re-exported (e.g. `log1...The runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting.
If a symbol is needed that isn't re-exported (e.g. `log1p`) then this code can't be run in GHCi because it will result in a duplicate symbols error.
### A workaround
The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile.
```
128 emptyPLS :: DynFlags -> PersistentLinkerState
129 emptyPLS _ = PersistentLinkerState {
130 closure_env = emptyNameEnv,
131 itbl_env = emptyNameEnv,
132 pkgs_loaded = init_pkgs,
133 bcos_loaded = [],
134 objs_loaded = [],
135 temp_sos = [] }
136
137 -- Packages that don't need loading, because the compiler
138 -- shares them with the interpreted program.
139 --
140 -- The linker's symbol table is populated with RTS symbols using an
141 -- explicit list. See rts/Linker.c for details.
142 where init_pkgs = [rtsUnitId]
```
I've tried 2 approaches which haven't worked completely:
1. I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach.
1. I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors.
What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet.
### Example
```hs
-- LogFloat.hs
module Main (main) where
import Data.Number.LogFloat (log1p)
main :: IO ()
main = print $ log1p 1.0
```
`runGhc LogFloat.hs` will fail:
```
Loading package logfloat-0.13.3.3 ...
linking ...
LogFloat.hs: ...\x86_64-windows-ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p'
LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3'
```8.0.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/11108Weak references related crash2019-07-07T18:31:55ZSaulzarWeak references related crashI've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs):...I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs):
Most frequently just Segmentation fault (with no stack trace)
Occasionally this:
```
bench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44
(GHC version 7.10.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
and more rarely this:
```
bench: internal error: WEAK object entered!
(GHC version 7.10.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Weak references related crash","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs):\r\n\r\nMost frequently just Segmentation fault (with no stack trace)\r\n\r\nOccasionally this:\r\n{{{\r\nbench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44\r\n\r\n (GHC version 7.10.2 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted (core dumped)\r\n}}}\r\n\r\nand more rarely this:\r\n\r\n{{{\r\nbench: internal error: WEAK object entered!\r\n (GHC version 7.10.2 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAborted (core dumped)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1takano-akiotakano-akiohttps://gitlab.haskell.org/ghc/ghc/-/issues/11041EventLog write fails if entire buffer is not written2019-07-07T18:32:27ZsseveranceEventLog write fails if entire buffer is not writtenRecently I was trying to use ThreadScope to run down a performance issue. I ran into what I believe is a corner case with flushing the eventlog data to disk. The program was generating hundreds of millions of events every few minutes.
T...Recently I was trying to use ThreadScope to run down a performance issue. I ran into what I believe is a corner case with flushing the eventlog data to disk. The program was generating hundreds of millions of events every few minutes.
The function `printAndClearEventBuf` uses `fwrite` to flush the buffer to disk. What I observed is that with larger buffers it would only succeed in writing the first 4096 bytes. After it would print out its `debugBelch` message a number of times the program would crash. It does not crash if not run with the eventlog `-l` flag.
My understanding is that `fwrite` might need to be called in a loop to ensure that all data is written. `fwrite` is not guaranteed to always write the entire requested buffer.
I don't have a good test case for this, but if there is agreement about potential issues with flushing the buffer I am more than happy to provide a patch.8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10977Arm: Undeclared indentifier when compiling rts/Linker.c2019-07-07T18:32:49ZerikdArm: Undeclared indentifier when compiling rts/Linker.cI have a Jenkins job which builds GHC on armhf and just got this:
```
rts/Linker.c:6209:21: error:
error: ‘target_shndx’ undeclared (first use in this function)
if (oc->sections[target_shndx].kind == SECTIONKIND_OTHER) {
...I have a Jenkins job which builds GHC on armhf and just got this:
```
rts/Linker.c:6209:21: error:
error: ‘target_shndx’ undeclared (first use in this function)
if (oc->sections[target_shndx].kind == SECTIONKIND_OTHER) {
^
rts/Linker.c:6209:21: error:
note: each undeclared identifier is reported only once for each
function it appears in
`gcc' failed in phase `C Compiler'. (Exit code: 1)
```
Seems this is a result of 04e8366608 and the fix is pretty obvious.8.0.1erikderikdhttps://gitlab.haskell.org/ghc/ghc/-/issues/10955GHC on windows does not resolve DLL dependencies2019-07-07T18:32:55ZTamar ChristinaGHC on windows does not resolve DLL dependenciesGHC does not correctly tell the Windows Loader how to handle dependencies to dll's that are not on the standard windows load path:
1. The directory from which the application loaded.
1. The current directory.
1. The system directory. U...GHC does not correctly tell the Windows Loader how to handle dependencies to dll's that are not on the standard windows load path:
1. The directory from which the application loaded.
1. The current directory.
1. The system directory. Use the `GetSystemDirectory` function to get the path of this directory.
1. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
1. The Windows directory. Use the `GetWindowsDirectory` function to get the path of this directory.
1. The directories that are listed in the `PATH` environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
So what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder `bin` and then call GHC with:
`ghc -L$(PWD)/bin -lB`
the loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC on windows does not resolve DLL dependencies","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"Phyx-"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC does not correctly tell the Windows Loader how to handle dependencies to dll's that are not on the standard windows load path:\r\n\r\n1. The directory from which the application loaded.\r\n2. The current directory. \r\n3. The system directory. Use the `GetSystemDirectory` function to get the path of this directory. \r\n4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.\r\n5. The Windows directory. Use the `GetWindowsDirectory` function to get the path of this directory.\r\n6. The directories that are listed in the `PATH` environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.\r\n\r\nSo what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder `bin` and then call GHC with:\r\n\r\n`ghc -L$(PWD)/bin -lB` \r\n\r\nthe loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/10790amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes)2019-07-07T18:33:52Zkgardasamd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes)Sometimes between July 19 and August 11 GHC HEAD build on Solaris 11/AMD64 platform started to fail. The failure looks:
```
dll-split: out of memory (requested 1099512676352 bytes)
gmake[1]: *** [compiler/stage2/dll-split.stamp] Error 1...Sometimes between July 19 and August 11 GHC HEAD build on Solaris 11/AMD64 platform started to fail. The failure looks:
```
dll-split: out of memory (requested 1099512676352 bytes)
gmake[1]: *** [compiler/stage2/dll-split.stamp] Error 1
gmake: *** [all] Error 2
```
and may be seen here http://haskell.inf.elte.hu/builders/solaris-amd64-head/350/10.html
The symptoms of the failure looks similar to #10682 but as this is about ARM64/Linux I rather write separate bug report here since code involved is heavily \#ifdefed to be OS specific -- hence also Solaris fix will be different from ARM64/Linux one probably.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"amd64/solaris 11: dll-split: out of memory (requested 1099512676352 bytes)","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Sometimes between July 19 and August 11 GHC HEAD build on Solaris 11/AMD64 platform started to fail. The failure looks:\r\n{{{\r\ndll-split: out of memory (requested 1099512676352 bytes)\r\ngmake[1]: *** [compiler/stage2/dll-split.stamp] Error 1\r\ngmake: *** [all] Error 2\r\n}}}\r\nand may be seen here http://haskell.inf.elte.hu/builders/solaris-amd64-head/350/10.html\r\nThe symptoms of the failure looks similar to #10682 but as this is about ARM64/Linux I rather write separate bug report here since code involved is heavily #ifdefed to be OS specific -- hence also Solaris fix will be different from ARM64/Linux one probably.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1kgardaskgardashttps://gitlab.haskell.org/ghc/ghc/-/issues/10728Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options2019-07-07T18:34:17ZrrnewtonAdd e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS optionsAs discussed in this issue:
> https://github.com/commercialhaskell/stack/issues/680
stack is one example of a program that optimistically turned on "-N". Indeed, it feels like a reasonable and even safe option for a multithreaded prog...As discussed in this issue:
> https://github.com/commercialhaskell/stack/issues/680
stack is one example of a program that optimistically turned on "-N". Indeed, it feels like a reasonable and even safe option for a multithreaded program. Unfortunately, -N currently guarantees bad performance on large machines and especially on large machines with hyperthreading. No one should ship an executable with -N by default as of GHC 7.8 and 7.10 IMHO.
Unfortunately, even if stack did get a speedup at, say, 4 or 8 cores, it would not be good to ship it with "-N8" either. This would be an unreasonable choice on small, one or two core machines.
What we need is a way to say that the program can productively use parallelism up to a certain upper bound, but that fewer threads should be used if there are not enough cores available. I propose "-N\<=8" as a potential syntax.
Currently, this behavior can be achieved with `setNumCapabilities`/`getNumProcessors`, but I think it's worth a command line RTS option.8.0.1MarcelineVQMarcelineVQhttps://gitlab.haskell.org/ghc/ghc/-/issues/10593compilation failure on OpenBSD2019-07-07T18:35:06Zkgardascompilation failure on OpenBSDGHC HEAD as of June 30 2015 fails to compile on OpenBSD 5.7/5.8-beta with following error (I've cut off all warnings there):
```
"inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototy...GHC HEAD as of June 30 2015 fails to compile on OpenBSD 5.7/5.8-beta with following error (I've cut off all warnings there):
```
"inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate
-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes
/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/autogen -optc-O2 -optc-fomit-frame-pointer -optc-g
-optc-DRtsWay=\"rts_v\" -static -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-pa
ckage-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Linker.c -o rts/dist/build/Linker.o
In file included from rts/Linker.c:92:0: error:
[...]
rts/Linker.c: In function 'getSectionKind_ELF':
rts/Linker.c:5308:0: error:
error: 'SHT_INIT_ARRAY' undeclared (first use in this function)
rts/Linker.c:5308:0: error:
error: (Each undeclared identifier is reported only once
rts/Linker.c:5308:0: error:
error: for each function it appears in.)
rts/ghc.mk:243: recipe for target 'rts/dist/build/Linker.o' failed
gmake[1]: *** [rts/dist/build/Linker.o] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"compilation failure on OpenBSD","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"GHC HEAD as of June 30 2015 fails to compile on OpenBSD 5.7/5.8-beta with following error (I've cut off all warnings there):\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate\r\n-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes\r\n/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/autogen -optc-O2 -optc-fomit-frame-pointer -optc-g\r\n -optc-DRtsWay=\\\"rts_v\\\" -static -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-pa\r\nckage-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Linker.c -o rts/dist/build/Linker.o\r\n\r\nIn file included from rts/Linker.c:92:0: error: \r\n\r\n[...]\r\nrts/Linker.c: In function 'getSectionKind_ELF':\r\n\r\nrts/Linker.c:5308:0: error:\r\n error: 'SHT_INIT_ARRAY' undeclared (first use in this function)\r\n\r\nrts/Linker.c:5308:0: error:\r\n error: (Each undeclared identifier is reported only once\r\n\r\nrts/Linker.c:5308:0: error:\r\n error: for each function it appears in.)\r\nrts/ghc.mk:243: recipe for target 'rts/dist/build/Linker.o' failed\r\ngmake[1]: *** [rts/dist/build/Linker.o] Error 1\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/10433Fix load/store barriers in pre-ARMv7 builds2019-07-07T18:35:56ZthoughtpoliceFix load/store barriers in pre-ARMv7 buildsAs pointed out in #10244 and [D894](https://phabricator.haskell.org/D894), the fix we committed for this problem isn't 100% correct - from 753b156dc6b0c38b106c390952750fb800bf27e7:
```
#elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_AR...As pointed out in #10244 and [D894](https://phabricator.haskell.org/D894), the fix we committed for this problem isn't 100% correct - from 753b156dc6b0c38b106c390952750fb800bf27e7:
```
#elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv7)
// TODO FIXME: This case probably isn't totally correct - just because we
// use a pre-ARMv7 toolchain (e.g. to target an old Android device), doesn't
// mean the binary won't run on a newer ARMv7 system - in which case it
// needs a proper barrier. So we should rethink this
// - Reid
__asm__ __volatile__ ("" : : : "memory");
```
This is a reminder to fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix load/store barriers in pre-ARMv7 builds","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"As pointed out in #10244 and Phab:D894, the fix we committed for this problem isn't 100% correct - from 753b156dc6b0c38b106c390952750fb800bf27e7:\r\n\r\n{{{\r\n#elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv7)\r\n // TODO FIXME: This case probably isn't totally correct - just because we\r\n // use a pre-ARMv7 toolchain (e.g. to target an old Android device), doesn't\r\n // mean the binary won't run on a newer ARMv7 system - in which case it\r\n // needs a proper barrier. So we should rethink this\r\n // - Reid\r\n __asm__ __volatile__ (\"\" : : : \"memory\");\r\n}}}\r\n\r\nThis is a reminder to fix this.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10296Segfaults when using dynamic wrappers and concurrency2019-07-07T18:36:42ZbitonicSegfaults when using dynamic wrappers and concurrencyI had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function.
After much sweat I've managed to produce a self-contained program that exhibits the same beha...I had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function.
After much sweat I've managed to produce a self-contained program that exhibits the same behavior:
```
bitonic@clay /tmp/ptr-crash % uname -a
Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
bitonic@clay /tmp/ptr-crash % cabal configure --disable-library-profiling -w ghc-7.11.20150411
Resolving dependencies...
Configuring ptr-crash-0...
bitonic@clay /tmp/ptr-crash % cabal build
Building ptr-crash-0...
Preprocessing executable 'ptr-crash' for ptr-crash-0...
[1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr-crash-tmp/Main.o )
Linking dist/build/ptr-crash/ptr-crash ...
bitonic@clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS
[1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS
```
I'm running GHC HEAD on a Linux 64bit machine. In the larger program, I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I can reproduce it only on 7.10 and later.
More details (thanks to Sergei Trofimovich on \#ghc for helping me in investigating this):
- The segfault only happens when using `-N2` or more.
- Curiously, the segfault seems to happen much more often when compiling the program with `-g`.
- The segfault doesn't happen every time, I get it roughly half of the times on my machine.
- `strace`ing the program when segfaulting shows that all the threads crash together right after some calls to `mremap`. I've attached the end of the output of `strace`.
- `gdb`ing the program and breaking on `mremap` shows that all the calls to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` that shows this pattern.
- The segfault only happens with repeated calls to the dynamic wrapper and with certain timings, which explains the weird nature of the example (I kind of mimicked the behaviour of a C function we were calling from a proprietary C library). Note that the call to `sum_arr` is not really important and it's there just so that some time is spent in the callback -- the example works equally well if we convert the pointer to an Haskell vector and sum it from Haskell.
Sergei had a hunch that this had to do with thread-unsafe calls to `stgReallocBytes` in `enlargeStablePtrTable`.8.0.1jmejmehttps://gitlab.haskell.org/ghc/ghc/-/issues/10238Update libffi shortly before first GHC 8.0.1 RC2019-07-07T18:36:57ZHerbert Valerio Riedelhvr@gnu.orgUpdate libffi shortly before first GHC 8.0.1 RCMaking this ticket so I don't forget to check for the latest libffi release shortly before the first RC (like I missed that "libffi-3.2.1 was released on November 12, 2014" which would have been in time for 7.10.1RC1)
<details><summary>...Making this ticket so I don't forget to check for the latest libffi release shortly before the first RC (like I missed that "libffi-3.2.1 was released on November 12, 2014" which would have been in time for 7.10.1RC1)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Update libffi shortly before first GHC 7.12.1 RC","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"hvr"},"version":"","keywords":["libffi"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar","thoughtpolice"],"type":"Task","description":"Making this ticket so I don't forget to check for the latest libffi release shortly before the first RC (like I missed that \"libffi-3.2.1 was released on November 12, 2014\" which would have been in time for 7.10.1RC1)\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/10155[PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_642019-07-07T18:37:18Zstengel[PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effecti...The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this "free" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case.
The attached patch reorders the register access, so that the stack pointer is restored last. It's also shorter by one instruction.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"[PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this \"free\" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case.\r\n\r\nThe attached patch reorders the register access, so that the stack pointer is restored last. It's also shorter by one instruction.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1thoughtpolicethoughtpolice