Closed Bug 1511647 Opened 6 years ago Closed 3 years ago

Investigate removing NULL checks on aArgv

Categories

(Core :: IPC, task, P3)

Product:
Core
Component:
IPC
Type:
task

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox65 --- affected

People

(Reporter: jan, Assigned: gerard-majax)

References

Details

(Keywords: nightly-community)

See bug 1477037 for whole context. (Nathan Froyd [:froydnj] from bug 1477037 comment 15) > Can you file a followup bug in Core::IPC about removing these checks? I don't see any reason that we should be passing nullptr in the arg list...unless we're processing the nullptr at the end of argv, which indicates a logic bug someplace else.
See also bug 1509813, which is the same problem of mystery nulls on regular builds. This also means that the guess in bug 1477037 comment #10, that it's related to --disable-crashreporter, is probably not it. Bug 1477037 comment #5 has a reliable repro, if I understand correctly, so if that reproduces under rr it should be relatively simple to reverse-debug with watchpoints to find out where the null is coming from. Failing that, printing out the argument list and seeing where the null is could give some clues.
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1509813
ni? me to see if there's a reliable repro
Flags: needinfo?(jld)
Type: enhancement → task
Assignee: nobody → lissyx+mozillians
Severity: normal → S4
Flags: needinfo?(jld)
Priority: -- → P3

This is code we removed in bug 1723505

So, this code is dead, and building tree as of bug 1477037 is not working anymore, so reproducing that is kinda hard. All IPC level CLI parsing should have moved to CheckArg() that is immune to nullptr so there should be no reason to crash anymore ; and disabling crash reporter does not show any dangling nullptr within aArgv.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.