Bugzilla

Unfortunately a lot of this GTK code has git-blame dating back ~17 years or so, so for better or for worse, this may have been a problem for quite a while.

Coincidentally the final fatal `removed_printer_checklist` search seems to have been last touched in a commit from 10 years ago titled `Revert "Fix gtkprintbackendcups crash"`:  https://github.com/GNOME/gtk/commit/9d36dbb44ba14adeb29135de01a936eb623375f2

But the crash referenced there seems to have been something different from the crash that we're hitting here... maybe.  (The reverted patch was a null-check for `removed_printer_checklist` which wouldn't help in this case.)

I'm pretty sure it's possible to write a small GTK program that triggers this same issue, to assist in reporting upstream and seeing if the GTK folks can do anything about this.  Based on how ancient the code is and how fiddly printer things are, I'm not entirely sure a fix will be trivial/forthcoming.

I have an untested idea for a workaround on our end -- I think we can avoid around this by **changing our comparison callback to pretend it never finds the thing it's looking for**, i.e. make `nsDeviceContextSpecGTK::PrinterEnumerator` unconditionally return FALSE. That should prevent `list_added_cb` from calling `stop_enumeration` and deleting data out from under the `cups_request_printer_list_cb` loop.  It's possible there'll be a perf cost (even in the general weren't-gonna-crash case) to forcing ourselves to traverse the whole printer list, but hopefully it's minimal...

Unfortunately a lot of this GTK code has git-blame dating back ~17 years or so, so for better or for worse, this may have been a problem for quite a while.

Coincidentally, our [doomed `removed_printer_checklist` search](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/modules/printbackends/gtkprintbackendcups.c#L3753-L3756) (the last bullet in my previous-comment explanation) seems to have been last touched in a commit from 10 years ago titled `Revert "Fix gtkprintbackendcups crash"`:  https://github.com/GNOME/gtk/commit/9d36dbb44ba14adeb29135de01a936eb623375f2

But the crash referenced there seems to have been something different from the crash that we're hitting here... maybe.  (The reverted patch was a null-check for `removed_printer_checklist` which wouldn't help in this case.)

I'm pretty sure it's possible to write a small GTK program that triggers this same issue, to assist in reporting upstream and seeing if the GTK folks can do anything about this.  Based on how ancient the code is and how fiddly printer things are, I'm not entirely sure a fix will be trivial/forthcoming.

I have an untested idea for a workaround on our end -- I think we can avoid around this by **changing our comparison callback to pretend it never finds the thing it's looking for**, i.e. make `nsDeviceContextSpecGTK::PrinterEnumerator` unconditionally return FALSE. That should prevent `list_added_cb` from calling `stop_enumeration` and deleting data out from under the `cups_request_printer_list_cb` loop.  It's possible there'll be a perf cost (even in the general weren't-gonna-crash case) to forcing ourselves to traverse the whole printer list, but hopefully it's minimal...