gnome-shell crashed with SIGSEGV at ?+a7c called from (Cannot access memory at address [in stack])

Stacktrace:
 #0 0x00007f0d7aec5a7c in ?? ()
 No symbol table info available.
 Backtrace stopped: Cannot access memory at address 0x7ffce8d834a0
StacktraceSource: #0 0x00007f0d7aec5a7c in ?? ()
StacktraceTop: ?? ()

Thank you for taking the time to report this bug and helping to make Ubuntu better.

However, processing it in order to get sufficient information for the developers failed (it does not generate an useful symbolic stack trace). This might be caused by some outdated packages which were installed on your system at the time of the report. Please upgrade your system to the latest package versions. If you still encounter the crash, please file a new report.

Thank you for your understanding, and sorry for the inconvenience!

Looks the same as these, which are also new in gnome-shell 42:

https://errors.ubuntu.com/problem/72ac8d41c03462cc0271527dec039025218b46d4
https://errors.ubuntu.com/problem/644a6cc9e462a67db78caff5570888f0fc956d0b
https://errors.ubuntu.com/problem/f87fbdb8562f83f5a04d1b4910b46dc111548b00

Frame #1 is in the heap, apparently, so might be coming from JavaScript.

Although duplicate bug 1964254 is gnome-shell 41.

All the duplicates seem to get stuck at addresses in [stack] according to ProcMaps.txt. The crash reports all say "Backtrace stopped: Cannot access memory at address", but ProcMaps.txt seems to indicate it's a valid stack address (read-write memory, but not executable).

I think the final address ending in a7c is probably raise() so that may not be useful information.

This is starting to smell like stack corruption.

It appears the address of a stack variable has overwritten the return address for the offending function call. So we have no stack trace.

I wonder if there's a way to catch stack corruption without going so far as Valgrind...

If anyone can reproduce this crash then please:

1. Reproduce the crash.

2. Reboot.

3. Run:

   journalctl -b-1 > prevboot.txt

4. Attach the resulting text file here.

Got directed here from bug (private due to coredump attachement) that Daniel marked a duplicate of this one.

I can reliably reproduce my original issue following:

1. Fresh boot
2. Connect external monitors
3. Put laptop to sleep
4. Wake laptop from sleep (one of two external monitors is still black)
5. Go to Settings -> Display (Gnome thinks both monitors are enabled)
6. Disable the black monitor and enable it again.
7. Gnome enables the problematic monitor for a split second and then disables it instantly.

Attaching prevboot.txt for the above.

I have so far two workarounds for my issue

Workaround 1:
- go to TTY3 with Ctrl+Alt+F3 (no need to log in, just wait for all monitors to work)
- go to TTY1 with Ctrl+Alt+F1 (lands on GDM log in page, I log in)
- all monitors now work and applications are preserved (sometimes need to enable it in settings)

Workaround 2:
- power cycle the black monitor (but without messing with Settings -> Display first)

Happy to provide more information or test solutions. It was driving me crazy to at least figure out reproducibility pattern and possible workarounds (stayed until 3am one night experimenting...).

Not sure if useful but I also learned:
- happens also on kernel 5.17 from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17.2/amd64/
- happens also on live usb session from Ubuntu 22.04 so not likely my local changes
- does not happen on live usb of fedora 36 beta (tested as it also has gnome 42)

Looks like I hit this today in a Xorg session when testing Nvidia.

The log provides no details of what caused the crash other than the system was shutting down/logging out at the time.

Bug 1964037 mentions a similar stack trace so maybe that was the problem all along.