From clintonmead at gmail.com  Wed Feb 21 00:39:56 2024
From: clintonmead at gmail.com (Clinton Mead)
Date: Wed, 21 Feb 2024 11:39:56 +1100
Subject: How to build executables that will dump live backtraces
Message-ID: <CAFDVgwHZyfLtDuJO-aWAcMhGZxJ1CPRvq4krJ-6NyFrm0ahxZg@mail.gmail.com>

Hi All

I've noticed this is a quiet mailing list recently, but I couldn't find a
more appropriate place to ask this question. Please say if there's
somewhere else I should be asking.

It's my understanding that one can get GHC executables to dump backtraces
of all their running threads to stderr upon receiving SIGQUIT. And the way
to do that is to build with 'libdw' support.

We have a build system using Nix, and we're unfortunately a bit behind on
GHC 9.2.2 atm, but in anycase, I noticed in a Nix develop shell when I run
`ghc --info | grep libdw` I get:

,("RTS expects libdw","NO")

So I instead added the following to my Haskell package overrides:

ghc = old.ghc.overrideAttrs (oldAttrs: { configureFlags =
oldAttrs.configureFlags ++ [
"--with-libdw-includes=${pkgs.elfutils.dev}/include"
"--with-libdw-libraries=${pkgs.elfutils.out}/lib" "--enable-dwarf-unwind"
]; buildInputs = oldAttrs.buildInputs ++ [pkgs.elfutils]; });

I basically copy/pastaed this from
https://github.com/input-output-hk/haskell.nix/blob/master/compiler/ghc/default.nix

And this seems to work, now when I run `ghc --info` I get:

,("RTS expects libdw","YES")

But despite building with this version of GHC, still when I send `SIGQUIT`
to a process built with this version of GHC, I just get the message:

"This build does not support backtraces."

Now I have also been building my packages with `-g`, passing
`--enable-debug-info` etc, although it's my understanding that what I've
done just with building GHC with `--enable-dwarf-unwind` _should_ be enough
to get a backtrace upon SIGQUIT, it might just be a poor one if the
debugging symbols aren't added.

But clearly I've missed something if it's not working. I'm not quite sure
what set of circumstances the message "This build does not support
backtraces" is displayed? Is there a runtime check to see whether the
"libdw" library is actually in the library path, in addition to the
requirement that GHC be built with libdw support? If that's the case,
perhaps as I'm running this on NixOS I need to add something to my
executable's LD_LIBRARY_PATH or something? Or is there some option I need
to give GHC/Cabal to ensure that backtrace support is added to the
executable's runtime as well as making sure I've compiled with GHC that's
compiled with libdw support? Or is there some other runtime RTS option I
need to give to my executable?

As you can see, I'm completely lost about how to move forward on this, so
any help would be very much appreciated.

Thanks,
Clinton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20240221/e701701c/attachment.html>

From carter.schonwald at gmail.com  Wed Feb 21 18:56:35 2024
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 21 Feb 2024 13:56:35 -0500
Subject: How to build executables that will dump live backtraces
In-Reply-To: <CAFDVgwHZyfLtDuJO-aWAcMhGZxJ1CPRvq4krJ-6NyFrm0ahxZg@mail.gmail.com>
References: <CAFDVgwHZyfLtDuJO-aWAcMhGZxJ1CPRvq4krJ-6NyFrm0ahxZg@mail.gmail.com>
Message-ID: <CAHYVw0yF3do7vkMLToooJsjOE3siW_UO4FG3zAAC_XJpiLXjEA@mail.gmail.com>

Have you looked at
https://www.haskell.org/ghc/blog/20200403-dwarf-1.html or other docs online
?

On Tue, Feb 20, 2024 at 7:40 PM Clinton Mead <clintonmead at gmail.com> wrote:

> Hi All
>
> I've noticed this is a quiet mailing list recently, but I couldn't find a
> more appropriate place to ask this question. Please say if there's
> somewhere else I should be asking.
>
> It's my understanding that one can get GHC executables to dump backtraces
> of all their running threads to stderr upon receiving SIGQUIT. And the way
> to do that is to build with 'libdw' support.
>
> We have a build system using Nix, and we're unfortunately a bit behind on
> GHC 9.2.2 atm, but in anycase, I noticed in a Nix develop shell when I run
> `ghc --info | grep libdw` I get:
>
> ,("RTS expects libdw","NO")
>
> So I instead added the following to my Haskell package overrides:
>
> ghc = old.ghc.overrideAttrs (oldAttrs: { configureFlags =
> oldAttrs.configureFlags ++ [ "--with-libdw-includes=${pkgs.elfutils.dev}/include"
> "--with-libdw-libraries=${pkgs.elfutils.out}/lib" "--enable-dwarf-unwind"
> ]; buildInputs = oldAttrs.buildInputs ++ [pkgs.elfutils]; });
>
> I basically copy/pastaed this from
> https://github.com/input-output-hk/haskell.nix/blob/master/compiler/ghc/default.nix
>
> And this seems to work, now when I run `ghc --info` I get:
>
> ,("RTS expects libdw","YES")
>
> But despite building with this version of GHC, still when I send `SIGQUIT`
> to a process built with this version of GHC, I just get the message:
>
> "This build does not support backtraces."
>
> Now I have also been building my packages with `-g`, passing
> `--enable-debug-info` etc, although it's my understanding that what I've
> done just with building GHC with `--enable-dwarf-unwind` _should_ be enough
> to get a backtrace upon SIGQUIT, it might just be a poor one if the
> debugging symbols aren't added.
>
> But clearly I've missed something if it's not working. I'm not quite sure
> what set of circumstances the message "This build does not support
> backtraces" is displayed? Is there a runtime check to see whether the
> "libdw" library is actually in the library path, in addition to the
> requirement that GHC be built with libdw support? If that's the case,
> perhaps as I'm running this on NixOS I need to add something to my
> executable's LD_LIBRARY_PATH or something? Or is there some option I need
> to give GHC/Cabal to ensure that backtrace support is added to the
> executable's runtime as well as making sure I've compiled with GHC that's
> compiled with libdw support? Or is there some other runtime RTS option I
> need to give to my executable?
>
> As you can see, I'm completely lost about how to move forward on this, so
> any help would be very much appreciated.
>
> Thanks,
> Clinton
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20240221/953b983c/attachment.html>

From zubin at well-typed.com  Fri Feb 23 10:55:32 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Fri, 23 Feb 2024 16:25:32 +0530
Subject: [ANNOUNCE] GHC 9.8.2 is now available
Message-ID: <p3jwwq6lmiu5cuwsmgtdswbxyz2tilwtvxaarcviyztjaj6mlk@gfxg23vric2o>

The GHC developers are happy to announce the availability of GHC 9.8.2. Binary
distributions, source distributions, and documentation are available on the
[release page](https://www.haskell.org/ghc/download_ghc_9_8_2.html).

GHC Blog Post: https://www.haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html 

This release is primarily a bugfix release addressing many issues
found in the 9.8 series. These include:

* A fix for a bug where certain warnings flags were not recognised (#24071)
* Fixes for bugs in the renamer and typechecker (#24084, #24134, #24279, #24083)
* Fixes for bugs in the simplifier and code generator (#24160, #24242, #23628, #23659, #24160, #23862, #24295, #24370)
* Fixes for some memory leaks in GHCi (#24107, #24118)
* Improvements to error messages (#21097, #16996, #11050, #24196, #24275, #23768, #23784, #23778)
* A fix for a recompilation checking bug where GHC may miss changes in
   transitive dependencies when deciding to relink a program (#23724).
* And many more fixes

A full accounting of changes can be found in the [release notes]. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and
other anonymous contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years. Finally,
this release would not have been possible without the hundreds of open-source
contributors whose work comprise this release.

As always, do give this release a try and open a [ticket][] if you see
anything amiss.

Enjoy!

-Zubin

[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
[release notes]: https://downloads.haskell.org/~ghc/9.8.2/docs/users_guide/9.8.2-notes.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20240223/a9ab4b01/attachment.sig>