** Description changed:

  [ Impact ]
  
- A significant number of crashes are being reported across releases in
- the Wireplumber shutdown sequence, particularly when switching between
- sessions (gdm-greeter -> user), but also in other situations.
+ wireplumber aborts with SIGABRT on its shutdown path:
+ 
+   "assertion failed: (handler != NULL)" in invalid_closure_notify()
+   from closure_invoke_notifiers()
+ 
+ This is one of the highest-volume wireplumber crash signatures on
+ errors.ubuntu.com:
+ https://errors.ubuntu.com/problem/a862ecef975d9036153bbb65bf0b0116072763d4
+ 
+ The 0.5.12 permission-store lifecycle fix already released for this bug
+ reduced the report rate but did not eliminate it. Resolute at
+ 0.5.13-1ubuntu1 still produces reports, most recently LP: #2167080, whose
+ core dump gives the full chain.
+ 
+ Root cause now appears to be teardown ordering, not memory corruption.
  
  [ Test plan ]
  
- Since this is not an easily reproducible issue, the test plan is tricky
- to define. The code changes can be exercised by stopping/starting the
- Wireplumber service. There are no behaviour changes related to the
- permissions store in particular, rather the lifecycle.
+ The crash is a shutdown race, so a single run proves nothing. Reproduction
+ is statistical.
+ 
+ 1. On a resolute install with the archive wireplumber 0.5.13-1ubuntu1,
+ confirm apport is enabled and /var/crash is empty:
+ 
+      sudo rm -f /var/crash/_usr_bin_wireplumber.*
+      systemctl --user status wireplumber
+ 
+ 2. Cycle the service repeatedly:
+ 
+      for i in $(seq 1 200); do
+        systemctl --user restart wireplumber
+        sleep 2
+      done
+      ls -l /var/crash/_usr_bin_wireplumber.*
+ 
+    Machines with modem-manager present (the reported trace goes through
+    WpModemManager) reproduce most readily. A laptop with a WWAN card, or
+    any machine where `wpctl status` lists the modem-manager plugin, is the
+    best target.
+ 
+ 3. The other reported trigger is the greeter-to-user session handover,
+ which tears down the lightdm/gdm wireplumber instance. Log in and out
+ ~20 times and check /var/crash for a wireplumber crash owned by uid 108
+ (lightdm) or the gdm uid.
+ 
+ 4. Repeat 1-3 with 0.5.13-1ubuntu1.1 from resolute-proposed. No
+ _usr_bin_wireplumber crash file should appear.
+ 
+ 5. Check the journal for the shutdown path being clean:
+ 
+      journalctl --user -u wireplumber -b | grep -iE
+ 'assertion|abort|proxy'
+ 
+ 6. Regression check: audio must still work normally. Play audio, switch
+    output devices with `wpctl set-default`, suspend and resume, and confirm
+    `wpctl status` lists the same nodes before and after a restart.
  
  [ Where problems could occur ]
  
- This could cause / expose further race conditions during Wireplumber
- shutdown.
+ The change makes wireplumber deactivate objects earlier than it used to, so
+ anything that assumed it could still use another plugin during its own
+ teardown now runs against a deactivated peer.
+ 
+  * Plugins whose disable() reaches into another plugin: modem-manager (dbus
+    connection), the portal permission store, the reserve-device logic. A
+    mistake here shows up as a different shutdown crash or a hang at exit
+    rather than the assert above, so watch for wireplumber being SIGKILLed
+    by the systemd user manager at logout.
+ 
+  * Lua scripts are now deactivated before the Lua state is freed. A script
+    that relied on running code during GC finalization would silently stop
+    doing so. In practice this affects the monitors in
+    /usr/share/wireplumber/scripts; a failure would present as devices not
+    being cleanly removed on shutdown, which is harmless at exit but would
+    be visible if it leaked into a restart.
+ 
+  * Upstream 0.5.15 also carries a824ae91 ("m-lua-scripting: only hold a
+    strong reference of the Lua state when the script is enabled"), a
+    follow-up that suppresses leaked-proxy warnings introduced by MR 833's
+    earlier deactivation. It is a 140-line refactor wrapping lua_State in a
+    GObject, which is too invasive for an SRU, so it is deliberately not
+    backported. Resolute may therefore log "leaked proxy" warnings at
+    shutdown that stonking does not. These are log noise, not a functional
+    regression.
+ 
+ * The GLib side of the problem is untouched. glib2.0 (Ubuntu Resolute) is
+   still Triaged on this bug: g_signal_connect_object()'s notifier
+   bookkeeping desyncs when the signal instance is destroyed before the
+   watching object. This upload removes wireplumber's way of reaching that
+   state; it does not fix GLib, so other packages remain exposed.
  
  [ Other info ]
  
- The Ubuntu Error Tracker has been receiving reports about a problem regarding 
wireplumber.  This problem was most recently seen with package version 
0.5.10-3, the problem page at 
https://errors.ubuntu.com/problem/a862ecef975d9036153bbb65bf0b0116072763d4 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
- If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.
+  * Fixed upstream in 0.5.15, so stonking (0.5.15-1ubuntu2) already has both
+    commits. No regression on release upgrade.
+ 
+  * The Ubuntu Error Tracker has been receiving reports about this problem.
+    The problem page at
+ 
+    https://errors.ubuntu.com/problem/862ecef975d9036153bbb65bf0b0116072763d4
+    
+    contains more details, including versions of packages affected,
+    stacktrace or traceback, and individual crash reports.
+ 
+  * LP: #2167080 is a duplicate with a fully analysed core dump.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2127049

Title:
  wireplumber crashed with SIGABRT; "assertion failed: (handler !=
  NULL)" in invalid_closure_notify() from closure_invoke_notifiers()

To manage notifications about this bug go to:
https://bugs.launchpad.net/glib/+bug/2127049/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to