Naturally, the one job that was incorrect was the release job.

The Docker image doesn't have libdw installed.

This avoids bugs in the `process` library during bootstrapping.

Travis Whitaker authored 5 years ago and Ben Gamari committed 5 years ago

(cherry picked from commit 67738db1)

Strangely, the comment next to this code already alluded to the fact
that even simply eta-expanding will sacrifice laziness. It's quite
unclear how we regressed so far.

See #18151.

(cherry picked from commit 2b89ca5b)

Previously we would implicitly convert the difference between two words
to an int, resulting in an integer overflow on 64-bit machines.

Fixes #16992

(cherry picked from commit c00c81a5)

`Ordering` needs to be wired in for use in the built-in `CmpNat` and
`CmpSymbol` type families, but somehow it was never added to the list
of `wiredInTyCons`, leading to the various oddities observed
in #18185. Easily fixed by moving `orderingTyCon` from
`basicKnownKeyNames` to `wiredInTyCons`.

Fixes #18185.

(cherry picked from commit 66bd24d1)

Artem Pelenitsyn authored 5 years ago and Ben Gamari committed 5 years ago

author: claude (https://gitlab.haskell.org/trac-claude)

The correct threshold for log1mexp is -(log 2) with the current specification
of log1mexp. This change improves accuracy for large negative inputs.

To avoid code duplication, a small helper function is added;
it isn't the default implementation in Floating because it needs Ord.

This patch does nothing to address that the Haskell specification is
different from that in common use in other languages.

(cherry picked from commit af5e3a88)

Moritz Angermann authored 5 years ago and Ben Gamari committed 5 years ago

libm is just an empty shell on musl, and all the math functions are contained in
libc.

(cherry picked from commit b4550748)

Moritz Angermann authored 5 years ago and Ben Gamari committed 5 years ago

Some archives contain so called linker objects, with the affectionate
.lo suffic.  For example the musl libc.a will come in that form.  We
still want to load those objects, hence we should not discard them and
look for .lo as well.  Ultimately we might want to fix this proerly by
looking at the file magic.

(cherry picked from commit 3fd12af1)

Moritz Angermann authored 5 years ago and Ben Gamari committed 5 years ago

See also: https://static.docs.arm.com/ihi0056/g/aaelf64.pdf

(cherry picked from commit 4a158ffc)

This reverts commit b12faad0.

(cherry picked from commit 481e3174)

Fixes #17995.

Sergei Trofimovich authored 5 years ago and Ben Gamari committed 5 years ago

Before the change ./configure detected numa support automatically
withoun a nice way to disable autodetection.

The change adds `--enable-numa` / `--disable-numa` switch to
override the default. If `--enable-numa` is passed and `libnuma`
is not present then configure will fail.

Reported-by: Sergey Alirzaev
Bug: https://github.com/gentoo-haskell/gentoo-haskell/issues/955


Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit 78afc2c9)

This read causes NULL dereferencing when len is 0.

Fixes #17909

In the reproducer in #17909 this bug is triggered as follows:

- SimplOpt.dealWithStringLiteral is called with a single-char string
  ("=" in #17909)

- tailFS gets called on the FastString of the single-char string.

- tailFS checks the length of the string, which is 1, and calls
  mkFastStringByteString on the tail of the ByteString, which is an
  empty ByteString as the original ByteString has only one char.

- ByteString's unsafeUseAsCStringLen returns (NULL, 0) for the empty
  ByteString, which is passed to mkFastStringWith.

- mkFastStringWith gets hash of the NULL pointer via hashStr, which
  fails on empty strings because of this bug.

(cherry picked from commit cb1785d9)

Reading a timerfd may return 0: https://lkml.org/lkml/2019/8/16/335.

This is currently undocumented behavior and documentation "won't happen
anytime soon" (https://lkml.org/lkml/2020/2/13/295).

With this patch, we just ignore the result instead of crashing. It may
fix #18033 but we can't be sure because we don't have enough
information.

See also this discussion about the kernel bug:
https://github.com/Azure/sonic-swss-common/pull/302/files/1f070e7920c2e5d63316c0105bf4481e73d72dc9

(cherry picked from commit 12789d3a)

As noted in #18105, previously this resulted in a rather intrusive error
message. This is in contrast to the general expectation that search
paths are merely places to look, not places that must exist.

Fixes #18105.

(cherry picked from commit 24af9f30)

(cherry picked from commit 4875d419)

As noticed in #17962, the make build system currently does this (see
3ce0e0ba) but the change was never ported to Hadrian.

(cherry picked from commit eba58110)

This is definitely a hack but it's probably the best we can do for now.
Hadrian does the right thing here by passing --export-dynamic only to
the linker.

(cherry picked from commit 2290eb02)

emptyModBreaks contains a bottom and consequently it's important that we
don't use it unless necessary.

(cherry picked from commit f684a7d5)

(cherry picked from commit 22c2713b)

Tamar Christina authored 6 years ago and Ben Gamari committed 5 years ago

(cherry picked from commit fb031b9b)

Also fix the markup in the general note at the top of the module.  Haddock
(usability trade-off), does not support multi-line emphasised text.

Fixes #17785

Here's how the problem occurs:

- In generation 0 we have a TSO that is finished (i.e. it has no more
  work to do or it is killed).

- The TSO only becomes reachable after collectDeadWeakPtrs().

- After collectDeadWeakPtrs() we switch to WeakDone phase where we don't
  move TSOs to different lists anymore (like the next gen's thread list
  or the resurrected_threads list).

- So the TSO will never be moved to a generation's thread list, but it
  will be promoted to generation 1.

- Generation 1 collected via mark-compact, and because the TSO is
  reachable it is marked, and its `global_link` field, which is bogus at
  this point (because the TSO is not in a list), will be threaded.

- Chaos ensues.

In other words, when these conditions hold:

- A TSO is reachable only after collectDeadWeakPtrs()
- It's finished (what_next is ThreadComplete or ThreadKilled)
- It's retained by mark-compact collector (moving collector doesn't
  evacuate the global_list field)

We end up doing random mutations on the heap because the TSO's
global_list field is not valid, but it still looks like a heap pointer
so we thread it during compacting GC.

The fix is simple: when we traverse old_threads lists to resurrect
unreachable threads the threads that won't be resurrected currently
stays on the old_threads lists. Those threads will never be visited
again by MarkWeak so we now reset the global_list fields. This way
compacting GC does not thread pointers to nowhere.

Testing
-------

The reproducer in #17785 is quite large and hard to build, because of
the dependencies, so I'm not adding a regression test.

In my testing the reproducer would take a less than 5 seconds to run,
and once in every ~5 runs would fail with a segfault or an assertion
error. In other cases it also fails with a test failure. Because the
tests never fail with the bug fix, assuming the code is correct, this
also means that this bug can sometimes lead to incorrect runtime
results.

After the fix I was able to run the reproducer repeatedly for about an
hour, with no runtime crashes or test failures.

To run the reproducer clone the git repo:

    $ git clone https://github.com/osa1/streamly --branch ghc-segfault

Then clone primitive and atomic-primops from their git repos and point
to the clones in cabal.project.local. The project should then be
buildable using GHC HEAD. Run the executable `properties` with `+RTS -c
-DZ`.

In addition to the reproducer above I run the test suite using:

    $ make slowtest EXTRA_HC_OPTS="-debug -with-rtsopts=-DS \
        -with-rtsopts=-c +RTS -c -RTS" SKIPWAY='nonmoving nonmoving_thr'

This enables compacting GC always in both GHC when building the test
programs and when running the test programs, and also enables sanity
checking when running the test programs. These set of flags are not
compatible for all tests so there are some failures, but I got the same
set of failures with this patch compared to GHC HEAD.