QM: Add support for error stacks
Categories
(Core :: Storage: Quota Manager, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox90 | --- | fixed |
People
(Reporter: janv, Assigned: janv)
References
(Blocks 1 open bug)
Details
Attachments
(14 files, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
Bug 1709352 - Reorder appending of extra keys to match the definition in Events.yaml; r=#dom-storage
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
Jens suggested that we could get precise error stacks if we had a wrapper around nsresult
that would hold info about error propagation. I think I figured out how to do that.
Assignee | ||
Comment 1•4 years ago
|
||
Assignee | ||
Comment 2•4 years ago
|
||
Depends on D114241
Assignee | ||
Comment 3•4 years ago
|
||
Depends on D114242
Assignee | ||
Comment 4•4 years ago
|
||
Depends on D114243
Assignee | ||
Comment 5•4 years ago
|
||
Depends on D114244
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Depends on D114245
Assignee | ||
Comment 7•4 years ago
|
||
Depends on D114338
Assignee | ||
Comment 8•4 years ago
|
||
Depends on D114339
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Did you analyze the effect of QMResult on code generation?
I am not sure in how many cases we benefit from the unused-zero optimization of Result<V, nsresult> now.
I fear this will make it even more relevant to restrict the builds this gets into.
Maybe QMResult should better be called QMError if it's never used to indicate success.
Assignee | ||
Comment 10•4 years ago
|
||
(In reply to Simon Giesecke [:sg] [he/him] from comment #9)
Did you analyze the effect of QMResult on code generation?
Not yet, but maybe it's not that urgent if we add some ifdef
, see below.
I fear this will make it even more relevant to restrict the builds this gets into.
That's actually a good observation, we can put all extra member variables in QMResult behind the ifdef
that we already have for stuff like this.
Maybe QMResult should better be called QMError if it's never used to indicate success.
Originally I wanted to have the ability to use it without mozilla::Result, but maybe it's not needed and then we would rename it to QMError
.
Assignee | ||
Comment 11•4 years ago
|
||
This makes it consistent with other places where we check EARLY_BETA_OR_EARLIER
and DEBUG identifier. For example HandleError.
Depends on D114340
Assignee | ||
Comment 12•4 years ago
|
||
Assignee | ||
Comment 13•4 years ago
|
||
The appening of module extra key was already commented out.
Assignee | ||
Comment 14•4 years ago
|
||
Ok, so I was able to limit the overhead to EARLY_BETA_OR_EARLIER || DEBUG builds.
sizeof(Result<Ok, nsresult)
and sizeof(Result<Ok, QMResult)
is the same in Release builds (the size is 4 bytes).
sizeof(Result<Ok, QMResult)
in Nightly builds is 24 bytes.
Comment 15•4 years ago
|
||
(In reply to Jan Varga [:janv] from comment #14)
Ok, so I was able to limit the overhead to EARLY_BETA_OR_EARLIER || DEBUG builds.
sizeof(Result<Ok, nsresult)
andsizeof(Result<Ok, QMResult)
is the same in Release builds (the size is 4 bytes).
sizeof(Result<Ok, QMResult)
in Nightly builds is 24 bytes.
For the sake of readability I was just wondering if we should have some specifically labeled switch (#define
) instead of sparse #if defined(EARLY_BETA_OR_EARLIER) || defined(DEBUG)
throughout the code?
Assignee | ||
Comment 16•4 years ago
|
||
The new code for error stacks already has it, QM_ERROR_STACKS_ENABLED.
Comment 17•4 years ago
|
||
I was referring to the ones introduced in Bug 1709352 - Define LogError only when needed; r=#dom-storage, are those the same scope?
Assignee | ||
Comment 18•4 years ago
|
||
That can be changed too.
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 19•3 years ago
|
||
Comment 20•3 years ago
|
||
Assignee | ||
Comment 21•3 years ago
|
||
Comment 22•3 years ago
|
||
Comment 23•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5ed477dfcd93
https://hg.mozilla.org/mozilla-central/rev/922a380b0d86
https://hg.mozilla.org/mozilla-central/rev/b4c891b1a31e
https://hg.mozilla.org/mozilla-central/rev/8313509e7cc1
https://hg.mozilla.org/mozilla-central/rev/e538b40f3e43
https://hg.mozilla.org/mozilla-central/rev/038434c75607
https://hg.mozilla.org/mozilla-central/rev/6d45855c91a7
https://hg.mozilla.org/mozilla-central/rev/f1905864fccd
https://hg.mozilla.org/mozilla-central/rev/bdfc8a9626c1
https://hg.mozilla.org/mozilla-central/rev/d239739c9637
https://hg.mozilla.org/mozilla-central/rev/fa9b64cfbfc9
Assignee | ||
Comment 24•3 years ago
|
||
LogError signature is now separately defined for the case when
QM_ERROR_STACKS_ENABLED is defined and when it's not defined). HandleError has
been changed as well to have explicit handling depending on
QM_ERROR_STACKS_ENABLED.
Assignee | ||
Comment 25•3 years ago
|
||
Depends on D116070
Comment 26•3 years ago
|
||
Comment 27•3 years ago
|
||
bugherder |
Assignee | ||
Comment 28•3 years ago
|
||
Depends on D116121
Assignee | ||
Updated•3 years ago
|
Comment 29•3 years ago
|
||
Comment 30•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/13f9d77af67b
https://hg.mozilla.org/mozilla-central/rev/0caad459ce02
Description
•