Diagnostic assert at [@ mozilla::net::Http3Stream::ReadSegments ]
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox97 | --- | unaffected |
firefox98 | --- | disabled |
firefox99 | --- | fixed |
People
(Reporter: dragana, Assigned: dragana)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [necko-triaged])
Crash Data
Attachments
(3 files)
Assignee | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Found this crash on try server.
https://treeherder.mozilla.org/logviewer?job_id=366855828&repo=autoland&lineNumber=6834
The test netwerk/test/unit/test_http3_large_post.js
was running with socket process. Before running this test, there were already some test failures, which might suggest that something was already wrong.
Comment 2•4 years ago
|
||
The raw log for comment #1.
Comment 3•4 years ago
|
||
Reproduce this crash with the following steps:
- Click
+
to upload a file on discord.com - Rename the uploaded file.
- Type anything and click enter to send this message.
The attached file is the http log.
Comment 4•4 years ago
|
||
I'm surprised this isn't flagged as a regression
Assignee | ||
Comment 5•4 years ago
|
||
This is not really a regression. There is no impact on the users. This is a diagnostic assert to make sure we behave nice.
Look at the log in comment 3, this is probably a false positive.
Comment 6•4 years ago
|
||
(In reply to Dragana Damjanovic [:dragana] from comment #5)
This is not really a regression. There is no impact on the users. This is a diagnostic assert to make sure we behave nice.
But this type of assert takes down non-debug builds. Crash is a pretty hard impact on users.
Can we change the type of assert, or remove it until it's not crashing beta and nightly builds? https://hg.mozilla.org/releases/mozilla-beta/file/8426c57c6960df31cae39214a8a1af0d92170662/netwerk/protocol/http/Http3Stream.cpp#l408
Comment 7•4 years ago
|
||
Set release status flags based on info from the regressing bug 1750587
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 8•3 years ago
|
||
A non-zero Content-Length header is set on nsHttpChannel by the creator of the channel. The creator of the channel does not supply an upload stream.
We should not send a Content-Length header without a body.
A Content-Length header value should match the size of the body.
Necko cannot easily detect this situation and I think it should be fixed by the channel creator
I have created bug 1757910 to fix the problem and I will change this assertion to a debug one because we cannot detect this case correctly.
Assignee | ||
Comment 9•3 years ago
|
||
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
bugherder |
Description
•