Opened 8 months ago

Closed 7 months ago

#15068 closed bug (fixed)

Small number of test case failures on Ubuntu Bionic (GCC 7.3)

Reported by: jrp Owned by:
Priority: highest Milestone: 8.4.3
Component: Compiler (CodeGen) Version: 8.4.1
Keywords: Cc: osa1
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Incorrect result at runtime Test Case: T13658 T14779a T14779b T14868 debug parsing001
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D4654
Wiki Page:

Description

A few tests (T13658 T14779a T14779b T14868 debug parsing001) fail running validate using HEAD and 8.4.1. They produce output similar to that shown below.

I am not quite sure how to test with clang. Just setting and exporting the environment variable CC to /usr/bin/clang (6) and running validate seemed to produce similar failures.

I was unable to try with LLVM because that now seems to be on version 6, which doesn't build.

=====> cgrun004(normal) 290 of 6344 [0, 0, 0]
cd "/tmp/ghctest-lx7q03iz/test   spaces/./codeGen/should_run/cgrun004.run" &&  "/home/jrp/Projects/ghc/bindisttest/install   dir/bin
/ghc" -o cgrun004 cgrun004.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-gr
oups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  
Wrong exit code for debug()(expected 0 , actual 2 )
Stdout ( debug ):
== Dbg ==
src<debug.hs:(3,1)-(5,29)>
src<debug.hs:3:9>
src<debug.hs:4:9>
src<debug.hs:5:13-17>
src<debug.hs:5:14>
src<debug.hs:5:21-29>
src<debug.hs:5:25-29>
src<debug.hs:5:26>
src<debug.hs:5:9-17>
src<debug.hs:5:9-29>
src<debug.hs:6:1-21>
Makefile:12: recipe for target 'debug' failed
Stderr ( debug ):
/tmp/ghc152350_0/ghc_2.s: Assembler messages:

/tmp/ghc152350_0/ghc_2.s:1364:0: error:
     Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'

/tmp/ghc152350_0/ghc_2.s:1393:0: error:
     Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'

/tmp/ghc152350_0/ghc_2.s:1422:0: error:
     Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'

/tmp/ghc152350_0/ghc_2.s:1451:0: error:
     Error: invalid operands (.debug_frame and .note.GNU-stack sections) for `-'
`gcc' failed in phase `Assembler'. (Exit code: 1)
make[1]: ./debug: Command not found
make[1]: *** [debug] Error 127
*** unexpected failure for debug(normal)

The tool versions are:

GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-16ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/x86_64-linux-gnu-as --with-ld=/usr/bin/x86_64-linux-gnu-ld --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3) 

Attachments (2)

testsuite_summary.txt (9.9 KB) - added by jrp 8 months ago.
testsuite_summary.2.txt (11.0 KB) - added by jrp 8 months ago.
validate --slow result

Download all attachments as: .zip

Change History (43)

comment:1 Changed 8 months ago by bgamari

Priority: normalhighest

Hmm, this is bad news. Presumably this is a due to a toolchain change which we should try to get ahead of since it will no doubt propagate to other distributions soon enough.

comment:2 Changed 8 months ago by jrp

By the way, the ghc available on Ubuntu is only 8.0.2-11 (which means that it cannot build HEAD). The haskell platform package is from 2014.

LLVM is 6, so you also need to install 5 to get LLVM builds, although I seem that there is some testing going on to update support #15024 That was tested against 8.4.1. I got more errors on HEAD and did not pursue further.

comment:3 Changed 8 months ago by ulysses4ever

As far as Ubuntu concerned, the way to use reasonable version of modern GHC is hvr's ppa, so I wouldn't bother about official repo's version too much.

Changed 8 months ago by jrp

Attachment: testsuite_summary.txt added

comment:4 Changed 8 months ago by jrp

OK. Thanks. I failed to spot that in the documentation here.

I've also run a "slow" test from the current HEAD. This throws up many more test suite failures, probably because I didn't install Haddock, or various libraries. The summary is attached.

comment:5 Changed 8 months ago by jrp

Today, the failures are up to:

TEST="T13658 T14779a T14779b T14868 T14955 debug"

 -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  -O
cd "./perf/should_run/T14955.run" && ./T14955 +RTS -V0 -tT14955.stats --machine-readable -RTS  
Actual stdout output differs from expected:
diff -uw "./perf/should_run/T14955.run/T14955.stdout.normalised" "./perf/should_run/T14955.run/T14955.run.stdout.normalised"
--- ./perf/should_run/T14955.run/T14955.stdout.normalised	2018-04-27 00:10:03.056784655 +0100
+++ ./perf/should_run/T14955.run/T14955.run.stdout.normalised	2018-04-27 00:10:03.060784652 +0100
@@ -1 +1 @@
- 
+True
*** unexpected failure for T14955(normal)

Unexpected results from:
TEST="T14955"

Changed 8 months ago by jrp

Attachment: testsuite_summary.2.txt added

validate --slow result

comment:6 Changed 8 months ago by osa1

Cc: osa1 added

comment:7 Changed 8 months ago by int-e

I think this is a bug/misfeature in GNU as: https://sourceware.org/bugzilla/show_bug.cgi?id=23040 (apparently, "." is evaluated wrt. the destination of the .uleb128 directive, which is .note.GNU-stack)

In any case, as a workaround, one can evaluate the expression before using it:

        uleb128_value = 1f-.-1
        .uleb128 = uleb128_value
;instead of
;       .uleb128 1f-.-1

The name can be reused.

comment:8 Changed 8 months ago by int-e

I mean .uleb128 uleb128_value (no equality sign), of course.

comment:9 Changed 8 months ago by int-e

The name can be reused.

While I think that this should be true, I'm actually not sure... I did a test with .long, but perhaps that was not adequate.

comment:10 Changed 8 months ago by osa1

This also happens when booting GHC with GHC 8.4.2 on Ubuntu 18.04.

comment:11 Changed 8 months ago by osa1

Differential Rev(s): Phab:D4651
Status: newpatch

comment:12 Changed 8 months ago by osa1

Differential Rev(s): Phab:D4651
Status: patchnew

comment:13 Changed 8 months ago by osa1

Apparently I interpreted the uleb128 argument wrong. int-e has a fix and will submit soon.

comment:14 Changed 8 months ago by int-e

Differential Rev(s): D4654
Status: newpatch

comment:15 Changed 8 months ago by int-e

Differential Rev(s): D4654Phab:D4654

comment:16 Changed 8 months ago by Ömer Sinan Ağacan <omeragacan@…>

In 358b5080/ghc:

Compute DW_FORM_block length correctly; also fixes #15068

Before this patch, the pprUnwindwExpr function computed the length of
by the following assembly fragment:

	.uleb128 1f-.-1
	<expression data>
1:

That is, to compute the length, it takes the difference of the label 1
and the address of the .uleb128 directive, and subtracts 1.

In #15068 it was reported that `as` from binutils 4.30 has trouble with
evaluating the `.` part of the expression. However, there is actually a
problem with the expression, if the length of the data ever becomes
larger than 128: In that case, the .uleb128 directive will emit more
than 1 byte, and the computed length will be wrong.

The present patch changes the assembly fragment to use two labels,
which fixes both these problems.

	.uleb128 2f-1f
1:
	<expression data>
2:

Test Plan: validate

Reviewers: bgamari, osa1

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15068

Differential Revision: https://phabricator.haskell.org/D4654

comment:17 Changed 8 months ago by osa1

Status: patchmerge

comment:18 Changed 8 months ago by jrp

That seems to have sorted it!

SUMMARY for test run started at Thu May  3 19:41:34 2018 BST
 0:09:13 spent to go through
    6355 total tests, which gave rise to
   23662 test cases, of which
   16961 were skipped

      40 had missing libraries
    6506 expected passes
     155 expected failures

comment:19 Changed 8 months ago by bgamari

Resolution: fixed
Status: mergeclosed

I doubt we'll have another 8.4 release so closing.

comment:20 Changed 7 months ago by recursion-ninja

This defect has completely broken my build on Ubuntu 18.04. I'm sure I'm not the only one experiencing this, and as the new OS version and/or underlying toolchain gets more adoption the problem will propagate as bgamari mentioned.

Can we prioritize a GHC-8.4.3 release? I really can't wait months for GHC-8.6 to resolve this defect. I'm guessing there are others can't wait that long either.

Last edited 7 months ago by recursion-ninja (previous) (diff)

comment:21 Changed 7 months ago by 4e6

I would also like to see this fix in GHC-8.4. Just bumped into this issue on Arch Linux (probably after upgrading to gcc-8.1.0)

comment:22 Changed 7 months ago by abarbu

Please prioritize a GHC-8.4.3. We just upgraded our machines and builds are failing because of this. When devs tell the community to wait 6+ months to fix a fatal error on a supported platform, and that the fix will be bundled with many other changes forcing a major upgrade, it really undercuts the argument that we should be relying on Haskell or GHC for anything.

comment:23 Changed 7 months ago by bgamari

Milestone: 8.6.18.4.3
Status: closedmerge

Can those who are affected by this issue confirm that they are building with debug information enabled (ghc -g)?

comment:24 Changed 7 months ago by recursion-ninja

Yes, I was building with ghc -g

comment:25 Changed 7 months ago by hvr

It's worth pointing out that this would mostly be experienced with Stack's somewhat questionable defaults. It should be rather easy to fix this on Stack's side by detecting system configurations which are known to be incompatible and avoid passing -g to GHC by default. For those that are blocked on this, I'd recommend either giving cabal new-build a try or using Stack w/ the GHC 8.4.2 (ghc-8.4.2 8.4.2-8~18.04) or GHC 8.2.2 (ghc-8.2.2 8.2.2-4~18.04) packages for Ubuntu 18.04 LTS from my Ubuntu PPA which don't suffer from this issue.

comment:26 Changed 7 months ago by recursion-ninja

Milestone: 8.4.38.6.1

I ran the following on my Ubuntu 18.04 installation to install the gcc-8.1 which appears to have resolved the issue.

$ add-apt-repository ppa:ubuntu-toolchain-r/test -y
$ apt-get install gcc-snapshot -y
$ apt-get install gcc-8 g++-8 -y
$ update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 60 --slave /usr/bin/g++ g++ /usr/bin/g++-8
Last edited 7 months ago by recursion-ninja (previous) (diff)

comment:27 Changed 7 months ago by svenpanne

I think that none of the suggestion so far is very helpful in the long run, the raw numbers (e.g. DistroWatch, State of Haskell Survey) indicate that this problem is a show stopper for 8.4.2 and its presence alone is a reason for an 8.4.3 release: Stack is by far the most popular way to install GHC, stack is far more popular as a build tool than cabal, and Ubuntu is ranking among the top 3 (or 4, depending on the survey) Linux distros, with 18.04 even being an LTS release. Put another way: Installing and using GHC in one of the most probable ways according to surveys will lead to a fragile/broken installation.

Installing a GHC by hand or changing the default GCC (which will definitely lead to problems later and undermines the whole idea of an LTS release) is OK as a stopgap measure, but not a real solution until August. I am sure everyone on this list is able to work around the problems, but I worry more about the average/wannabe Haskell user. Would it really be that hard to release an 8.4.3 with just the single fix above cherry-picked?

comment:28 Changed 7 months ago by vanessamchale

Last edited 7 months ago by vanessamchale (previous) (diff)

comment:29 in reply to:  27 ; Changed 7 months ago by hvr

Replying to svenpanne:

Sven, I'm not sure you're seeing the full picture here. The (questionable) popularity argument is completely off-topic and irrelevant to the issue at hand. Releasing a quickfixed GHC 8.4.3 would still undermine the whole idea of Stack's "LTS" snapshot releases and its (imperfect) "reproducability" concept, as this problem isn't limited to GHC 8.4.* but rather extends back to GHC 8.2.1. As such I see no reason for yet another rushed quickfix release of GHC, for something that *must* be fixed on Stack's end anyway in order to be effective. And it would be quite laughable if Stack wasn't in a better position to release a quick fix than for GHC HQ to make a full compiler release (which I have to emphasize wouldn't be sufficient anyway for users that are forced to use Stack and their GHC 8.[24].[12] snapshots to keep working with the affected GCC versions)... ;-)

comment:30 in reply to:  28 ; Changed 7 months ago by svenpanne

Replying to vanessamchale:

Stack is by far the most popular way to install GHC

I don't think that's true.

See http://taylor.fausak.me/2017/11/15/2017-state-of-haskell-survey-results/#question-15, if you've got more plausible/recent numbers, I would be interested to see them.

stack is far more popular as a build tool than cabal

You can use the system GHC with stack, as mentioned above.

I think you totally miss the point here: Of course you could do that, but one of the main points of stack's popularity is that you don't need to do that: All you need for a happy Haskell life is to install a single tool (stack), which pulls in other tools/compilers/packages as needed.

indicate that this problem is a show stopper for 8.4.2

This is not true.

In all companies I've worked so far, "crashing/not working on common platforms" is a definition of show stopper.

I worry more about the average/wannabe Haskell user

If for whatever reason they are constrained to using stack on Ubuntu without using the system GHC, they can use the latest LTS snapshot.

Telling people: "I've got buggy new SW, just use older one" is not really productive.

comment:31 Changed 7 months ago by bgamari

Milestone: 8.6.18.4.3

I will try to push out a new 8.4 release next week.

comment:32 in reply to:  29 Changed 7 months ago by svenpanne

Milestone: 8.4.38.6.1

Replying to hvr:

Replying to svenpanne:

Sven, I'm not sure you're seeing the full picture here. The (questionable) popularity argument is completely off-topic and irrelevant to the issue at hand.

Why on earth is popularity off-topic? Each and every bug is weighed by its impact. Why do we e.g. focus on x86_64 CPUs and not on e.g. ARM64?

Releasing a quickfixed GHC 8.4.3 would still undermine the whole idea of Stack's "LTS" snapshot releases and its (imperfect) "reproducability" concept, as this problem isn't limited to GHC 8.4.* but rather extends back to GHC 8.2.1. As such I see no reason for yet another rushed quickfix release of GHC, for something that *must* be fixed on Stack's end anyway in order to be effective.

I fail to see why stack should be changed.

And it would be quite laughable if Stack wasn't in a better position to release a quick fix than for GHC HQ to make a full compiler release (which I have to emphasize wouldn't be sufficient anyway for users that are forced to use Stack and their GHC 8.[24].[12] snapshots to keep working with the affected GCC versions)... ;-)

It's not laughable at all: You can provoke the same bug with cabal, too, just pass '-g' to GHC somehow. I somehow doubt that Ubuntu will release a new version of binutils soon (they would have to recompile each and every package if they take testing/QA seriously), so the only sane way to fix this would be in GHC itself.

comment:33 in reply to:  30 ; Changed 7 months ago by hvr

Sven, I still believe you're not seeing the point I'm making and trying to get back into a line of argument that's besides the point (don't get me started on the validity of those "statistics" you quote) and would only detract from the technical arguments that are pertinent to this issue. Please stop bringing up the irrelevant claims about Stack's (questionable) popularity and thus Stack would be too-big-to-fail that we have to adjust the surrounding ecosystem to Stack's needs, or even your (questionable) subjective perception about what a "happy Haskell life" constitutes, unless you really want me to get into an extended off-topic rant about of Stack's negative impact on Haskell's ecosystem and community and now even reaching into teaching (e.g. the popular data61 fp-course publicly getting attacked and its course materials even forked over Stack ideology)...

But let's try to get back on-topic. Maybe I'm not explaining myself well enough to get across the technical point, that rushing a GHC 8.4.3 quickfix just to workaround bad decisions made in Stack won't be enough and that Stack will need to address this on their end or Stack users will be still be "broken" with GHC 8.2.1, 8.2.2, 8.4.1 and 8.4.2 based install-plans on their end; and that we should rather focus our limited resources on letting GHC 8.4.2 mature a bit more (which is essentially a quickfixed/proper GHC 8.4.1 which is what some communities would declare a "NUKED" release; iow, for all practical purposes GHC 8.4.1 should be considered as if it never happened). To summarise, this bug has been present in GHC since GHC 8.2.1. If we follow your logic, Stack's mere existence would require us to make a GHC 8.2.3 point release as well rather than to fix this in Stack, in order not to leave those unfortunate GHC 8.2/Stack/Ubuntu18 users out in the rain.

Moreover, the most principled and thus recommended way to install and manage GHC on Debian or Ubuntu if you need a version that's not packaged by Debian/Ubuntu is via the instructions mentioned on http://downloads.haskell.org/debian/ which provides non-generic bindists specifically configured and built for the respective distribution release (this may not be so relevant on OSX or Windows, but for Linux's ABI compat story it is); this btw also means that a redundant(!) GHC 8.4.3 release would cause me a lot of busy work to "fix" something that my packaging doesn't even suffer from as I'd need to package up 8.4.3 and build it for various non-EOL'ed distros; not to mention I'd have to scrap the rather costly/time-consuming builds of a GHC 8.4.2 bindist for AIX I was working on, and start over w/ GHC 8.4.3, as well as having to carefully prepare Hackage releases of a couple GHC bootlibs and their associated Haddocks.

Finally, this doesn't affect non-Stack users, unless they are on a just released Ubuntu 18 release (NB: there's currently 3 LTS releases of Ubuntu that aren't EOL'ed; nobody is forced to use the still very infantly young new Ubuntu LTS yet) *and* don't use the packages provided either by Ubuntu or by my Ubuntu PPA (or aren't capable of building GHC from source) *and* use a non-default flag which is only relevant if you actually intend and know how to debug a Haskell program at a low-level via a debugger such as GDB. I seriously doubt this is a large enough group of people to demand this urgency. I for one I can't use (nor do I recommend) using GHC 8.4.x for anything mission critical until it has matured at least 2 more months and seen more field testing, and we've had time to accumulate fixes and release a non-redundant GHC 8.4.3 with those, to get it to the same level of confidence the GHC 8.2.2 release has.

I've already written more about this that I wanted to; I haven't heard any compelling reason yet that would justify rushing a redundant GHC 8.4.3 release only to keep Stack from fixing its bad choice of defaults. This is like asking to move a mountain because you don't feel like going around it. I'd rather want to see a GHC 8.4.3 released shortly before its support-window closes (which is in a couple months from now when GHC 8.6 becomes a thing), and releasing a GHC 8.4.3 now would make it more likely we won't see a GHC 8.4.4, thereby leaving us with a potentially less-reliable GHC 8.4.3 than it would be if it had had more time to mature and collect more fixes.

comment:34 Changed 7 months ago by osa1

Please move your stack/cabal-related discussions to elsewhere, this ticket is about the bug with -g on Ubuntu 18.04, and you're basically spamming GHC maintainers who get emails for updates on tickets.

comment:35 in reply to:  31 ; Changed 7 months ago by YitzGale

Replying to bgamari:

I will try to push out a new 8.4 release next week.

Thanks! Is the fix something that can be backported to previous versions of GHC?

comment:36 in reply to:  35 Changed 7 months ago by hvr

Replying to YitzGale:

Thanks! Is the fix something that can be backported to previous versions of GHC?

It can be done, and this is typically something that falls into the scope of packagers and distributors if they need to target affected toolchains; in fact this is what I did in

This has also happened in the past; without such backporting of compat-fixes I wouldn't be able to provide GHC versions ranging back to GHC 7.0.1 for the latest Debian & Ubuntu releases which had already made this necessary in the past thanks to evolving toolchains which broke assumptions made by GHC or happened to expose actual bugs, or were actually bugs in the C toolchain.

comment:37 in reply to:  33 ; Changed 7 months ago by recursion-ninja

I don't want to spam the GHC maintainers who get emails for updates on tickets. However, I think it's important to note that the non-stack users affected by this defect may not be so rare.

Replying to hvr:

Finally, this doesn't affect non-Stack users, unless they are on a just released Ubuntu 18 release (NB: there's currently 3 LTS releases of Ubuntu that aren't EOL'ed; nobody is forced to use the still very infantly young new Ubuntu LTS yet) ...

I was having "show-stopping" graphics driver issues on Ubuntu 16.04 that were only resolved by the 4.15.* version of the Linux kernel which was not and would not be supported (to the best of my knowledge) by Ubuntu 16.04. My upgrade to Ubuntu 18.04 was more or less "forced" to get a kernel version compatible with my machine.

Replying to hvr:

... *and* use a non-default flag which is only relevant if you actually intend and know how to debug a Haskell program at a low-level via a debugger such as GDB.

I was passing the -g flag while building with cabal because I have been fixing a defective feature involving the Cabal library linking to C & C++ sources and required debugging symbols while investigating and correcting the issue. https://github.com/haskell/cabal/pull/5315

Replying to hvr:

I seriously doubt this is a large enough group of people to demand this urgency.

This might be true. However, I did encountered this -g related defect through "normal," non-stack usage of ghc. There's a chance that my situation is an anomaly, but there's also a chance the defect might have a larger impact than estimated.

Last edited 7 months ago by recursion-ninja (previous) (diff)

comment:38 in reply to:  37 Changed 7 months ago by hvr

Replying to recursion-ninja:

I was having "show-stopping" graphics driver issues on Ubuntu 16.04 that were only resolved by the 4.15.* version of the Linux kernel which was not and would not be supported (to the best of my knowledge) by Ubuntu 16.04. My upgrade to Ubuntu 18.04 was more or less "forced" to get a kernel version compatible with my machine.

I've been in a similiar situation, and so have a lot others; *but* that's why Ubuntu some time ago introduced

https://wiki.ubuntu.com/Kernel/LTSEnablementStack

in order to help users who want to avoid having to upgrade away from an LTS release for the sake of a kernel upgrade. I'm happily running a

ii  linux-image-4.15.0-20-generic                 4.15.0-20.21~16.04.1                         amd64        Signed kernel image generic

kernel which iirc I had gotten installed before Ubuntu 18.04 Bionic was even released.

This might be true. However, I did encountered this -g related defect through "normal," non-stack usage of ghc. There's a chance that my situation is an anomaly, but there's also a chance the defect might have a larger impact than estimated.

Since you're on an Ubuntu system and you seem to be experienced enough to consider installing a bleedinge edge GCC toolchain; but then why aren't you simply using a GHC binary distribution like the ones I offer on https://launchpad.net/~hvr/+archive/ubuntu/ghc which are specifically configured and built for Ubuntu and designed to protect against this very kind of compatibility issues that inevitably creep up over time?

comment:39 Changed 7 months ago by YitzGale

According to reports on the stack github issue, this now appears to be far less common than originally thought. It only occurs if -g is set AND stripping is not enabled, and stack enables both of those by default. So the issue does not affect most stack users. It only affects those who explicitly disable stripping.

comment:40 Changed 7 months ago by bgamari

Milestone: 8.6.18.4.3

comment:41 Changed 7 months ago by bgamari

Status: mergeclosed
Note: See TracTickets for help on using tickets.