1823565 - Probable double-free in CUPS/cupsAddOption

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P2)

Description

[Randell Jesup [:jesup] (needinfo me)]

NOTE: not sure what sec-group to restrict this to.

300+ reports in the last 6 months. Use this search to see only the CUPS crashes:
https://crash-stats.mozilla.org/signature/?product=Firefox&proto_signature=~nsPrinterCUPS&signature=arena_run_reg_dalloc%20%7C%20arena_t%3A%3ADallocSmall%20%7C%20arena_dalloc%20%7C%20idalloc&date=%3E%3D2022-09-21T01%3A16%3A00.000Z&date=%3C2023-03-21T01%3A16%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=url&_columns=user_comments&_sort=-version&_sort=url&_sort=-date&page=1

Appear to all involve cpusAddOption

Crash report: https://crash-stats.mozilla.org/report/index/92bee364-9313-4701-a76d-3a8e60230309

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT((run->mRegionsMask[elm] & (1U << bit)) == 0) (Double-free?)

Top 10 frames of crashing thread:

0  firefox  arena_run_reg_dalloc  /root/parts/firefox/build/memory/build/mozjemalloc.cpp:2523
0  firefox  arena_t::DallocSmall  /root/parts/firefox/build/memory/build/mozjemalloc.cpp:3652
1  firefox  arena_dalloc  /root/parts/firefox/build/memory/build/mozjemalloc.cpp:3743
2  firefox  idalloc  /root/parts/firefox/build/memory/build/mozjemalloc.cpp:3762
2  firefox  arena_t::RallocSmallOrLarge  /root/parts/firefox/build/memory/build/mozjemalloc.cpp:3859
3  firefox  arena_t::Ralloc  /root/parts/firefox/build/memory/build/mozjemalloc.cpp:3868
3  firefox  BaseAllocator::realloc  /root/parts/firefox/build/memory/build/mozjemalloc.cpp:4513
4  firefox  Allocator<MozJemallocBase>::realloc  /root/parts/firefox/build/memory/build/malloc_decls.h:53
5  firefox  PageRealloc  /root/parts/firefox/build/memory/replace/phc/PHC.cpp:1207
5  firefox  replace_realloc  /root/parts/firefox/build/memory/replace/phc/PHC.cpp:1288

Comment 1

[:Gijs (out for now; he/him)]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #0)

NOTE: not sure what sec-group to restrict this to.

Going to guess at "layout" and CC a bunch of folks who've worked on our printing code.

Comment 2

[Andrew McCreight [:mccr8]]

There are multiple threads doing stuff with nsPrinterCUPS which could be related, or maybe it is a driver issue?

Comment 3

[Emily McDonough [:alaskanemily]]

Since it's relevant, I'll quote a part of the investigation in bug 1788543 here:

There were some concerns that CUPS code may have race conditions in its string table code, but after looking through it I think it's pretty carefully implemented to lock the string table with a mutex for any accesses and so I don't think this is the cause.

This could very possibly be a different expression of bug 1788543 where we crash at a different point after some memory corruption happens or triggering the same problem with a different series of calls.

Comment 4

[Emily McDonough [:alaskanemily]]

See bug 1824800 comment 3, I'm hoping that bug 1826872 fixes this issue (and that this is the same bug or at least has the same fix).

Comment 5

[Daniel Holbert [:dholbert]]

(Assigning to make it clear that this is being worked on, and is hopefully-fixed, per comment 4.)

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Emily McDonough [:alaskanemily] from comment #4)

See bug 1824800 comment 3, I'm hoping that bug 1826872 fixes this issue (and that this is the same bug or at least has the same fix).

Note: if this^ theory pans out, then there should be no crashes here associated with CUPS in 114 or newer.

We do actually have one crash (from today!) in version 114 beta7 with this signature:
bp-d526311f-f0d2-4bbd-939a-8cdf10230522
...but it's entirely unrelated to CUPS. Phew. Per comment 0, this bug is about this particular crash signature with nsPrinterCUPS in the backtrace.

For convenience, here's the relevant crash-stats link, like the one in comment 0 but with no date-specific restrictions:
https://crash-stats.mozilla.org/signature/?proto_signature=~nsPrinterCUPS&signature=arena_run_reg_dalloc%20|%20arena_t%3A%3ADallocSmall%20|%20arena_dalloc%20|%20idalloc

That search shows nothing since version 113.

So we're still hoping that the CUPS issue here is fixed. Possibly worth spinning off a followup for the remaining non-CUPS-related [@ arena_run_reg_dalloc | arena_t::DallocSmall | arena_dalloc | idalloc ]) crashes if there's measurable crash volume after we close out this bug.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

Per comment 0, this bug is about this particular crash signature with nsPrinterCUPS in the backtrace.

For convenience, here's the relevant crash-stats link, like the one in comment 0 but with no date-specific restrictions:
https://crash-stats.mozilla.org/signature/?proto_signature=~nsPrinterCUPS&signature=arena_run_reg_dalloc%20|%20arena_t%3A%3ADallocSmall%20|%20arena_dalloc%20|%20idalloc

That search shows nothing since version 113.

Still nothing. So it looks like this has gone away in version 114 and newer. So, I think we can declare victory here. Hooray!