Repository navigation
CefRequest.setURL("") and reading back a malformed URL crash the Debug/coverage build (CEF's own CHECK/NOTREACHED) #21
Description
Activity
- added a commit that references this issue
on Aug 29, 2026 Found a second, identically-rooted reproduction while continuing coverage work:
CefRequest.setURL(null)(not justsetURL("")) hits the sameCHECK(!url.empty())inrequest_ctocpp.cc, becausenative/CefRequest_N.cpp'sN_SetURLmarshals a nulljstringto an emptyCefString()with no guard -- same code path as the empty-string case, just reached via null. Debug/coverage-build-only, confirmed via isolated repro. Test added asNullParameterEdgeCaseTest.requestSetURLWithNullDoesNotThrow(),@Disabledpending the same fix.Third reproduction of the same root cause:
CefRequest.set(null, method, postData, headerMap)(nullurlargument) also hitsCHECK(!url.empty())viaCefRequest::Set(). Disabled asNullParameterEdgeCaseTest.requestSetAcceptsAllNullArguments().Fourth reproduction, same class of bug but a different setter:
CefRequest.setMethod(null)hitsCHECK(!method.empty())inrequest_ctocpp.ccviaCefRequest::SetMethod(). Same root pattern as the others in this issue --native/CefRequest_N.cpp's setters marshal a nulljstringstraight to an emptyCefString()with no guard, and several of CEF's own setters CHECK their string argument is non-empty. Worth considering a single fix that guards all ofCefRequest_N.cpp's string setters against null/empty where CEF's own API requires non-empty, rather than patching one call site at a time. Disabled asNullParameterEdgeCaseTest.requestSetMethodWithNullDoesNotThrow().Sixth reproduction, same pattern but a different value type:
CefPostDataElement.setToFile(null)hitsCHECK(!fileName.empty())viaCefPostDataElement::SetToFile(). At this point the pattern is clearly systemic, not isolated toCefRequest: at least 6 confirmed call sites acrossCefRequest_N.cppandCefPostDataElement_N.cppmarshal a null/emptyjstringstraight to an emptyCefString()with no guard, and CEF's own bundled binary CHECKs non-empty on several of those parameters (url, method, header name, file path). Recommend a single fix pass across both_N.cppfiles' string setters (guard-and-no-op on null/empty where CEF requires non-empty) rather than patching call sites one at a time -- filing/triaging each individually is producing a lot of near-duplicate issues (#19, #20, #21) for what looks like one root cause. Disabled asNullParameterEdgeCaseTest.postDataElementSetToFileAcceptsNull().Seventh reproduction, on CefResponse this time:
CefResponse.setHeaderByName(null, "value", true)hitsCHECK(!name.empty())inresponse_ctocpp.ccviaCefResponse::SetHeaderByName(). Confirms this isn't CefRequest/CefPostDataElement-specific -- CefResponse_N.cpp has the identical unguarded-null pattern. Disabled asNullParameterEdgeCaseTest.responseSetHeaderByNameWithNullNameDoesNotThrow().- added a commit that references this issue
on Aug 30, 2026 Fixed the empty-URL half of this issue (the setURL("") CHECK(!url.empty()) crash). native/CefRequest_N.cpp's N_SetURL now rejects an empty URL before calling into CEF (no-op instead of crashing).
The second crash signature described here (NOTREACHED in gurl.cc when reading back a URL that was successfully setURL()'d with a malformed-but-non-empty string, e.g. "://missing-scheme") is NOT addressed by this fix and remains open -- as the issue notes, setURL() itself accepting such strings is arguably already the questionable part, and the right JCEF-side fix isn't clear-cut. Leaving this issue open to track that remaining half; happy to split it into a separate issue if preferred.
Un-disabled requestSetURLWithEmptyStringDoesNotThrow in MalformedInputEdgeCaseTest.java. Verified passing in a full-suite run (156/156 tests, 0 failures).
- added a commit that references this issue
on Aug 31, 2026 Partial progress, not closing (part 2 below is still open).
Part 1 (
CefRequest.setURL("")empty-stringCHECK(!url.empty())) was already fixed in an earlier session (N_SetURL's empty-string guard predates this comment).This session (commit 92aed53) extended the identical guard pattern to the other call sites in the same bug class that had never been individually addressed:
CefRequest.setMethod(),CefRequest.set()(both its url and method params),CefResponse.setHeaderByName(), andCefPostDataElement.setToFile()(filed separately as #28, now closed). All 6 ofNullParameterEdgeCaseTest's previously-@Disabledtests covering this are now re-enabled and passing.Part 2 is still open and untouched: reading back a URL that was set to a malformed-but-non-empty string (e.g.
"://missing-scheme") still hitsGURL::spec()'sNOTREACHEDongetURL()/toString(). Nothing in today's work addresses this — it needs either a JCEF-side URL-validity check before acceptingsetURL(), or upstream CEF discussion, per this issue's own "Fix sketch" section.- added 4 commits that reference this issue
on Sep 1, 2026
Summary
Same class of issue as #20, found in the same bad-path test-writing round. Two distinct crash signatures, both Debug/coverage-build-only (confirmed neither reproduces in Release):
CefRequest.setURL("")(empty string):.toString()(which internally reads back the URL) on aCefRequestwhose URL was set to a genuinely unparseable string (e.g."://missing-scheme"):setURL()itself accepts malformed-but-non-empty strings fine (confirmed via isolated testing that"not a valid url at all","http://", and"://missing-scheme"all pass throughsetURL()without crashing) -- it's specifically reading the URL back afterward (getURL()/toString()) that hits theGURL::spec()NOTREACHEDfor a URL that never successfully parsed.request_ctocpp.ccis auto-generated by CEF's own build (frominclude/cef_request.hviatools/make_ctocpp_impl.py, not checked into thechromiumembedded/cefsource repo as a static file), so the exact generatedCHECKlogic wasn't directly inspectable -- confirmed only empirically via isolated test runs.Repro
Added to
java/tests/junittests/MalformedInputEdgeCaseTest.java(the empty-URL case is@Disabledwith a link to this issue -- remove@Disabledto re-run it, under theENABLE_COVERAGE/Debug build specifically):The three malformed-but-non-empty-string cases (
requestSetURLWithNoSchemeStringDoesNotThrow/WithSchemeOnlyStringDoesNotThrow/WithMissingSchemeColonStringDoesNotThrow) are kept enabled -- confirmed safe as long as nothing calls.toString()/getURL()on the request afterward. The.toString()-after-malformed-setURL()crash itself isn't currently captured as a standalone reproducer test (the version of this test that did that was rewritten to avoid it once isolated as the cause) -- worth adding a dedicated@Disabledtest for that specific combination if this issue is picked up.Impact
Same as #20: both crashed early enough in the process to prevent
CoverageTestHelper.flush()from running, losing an entire coverage-measurement run's.gcdadata each time (0 files written both times this was hit).Fix sketch (not implemented here)
For the empty-URL case: validate in
native/CefRequest_N.cpp'sN_SetURLthat the string is non-empty before calling into CEF. For the malformed-URL-then-read-back case: less clear what the "right" JCEF-side fix is, sincesetURL()itself succeeding with a malformed value is arguably already the questionable part -- may need either upstream CEF discussion or a JCEF-side URL-validity check before accepting asetURL()call at all.Found via
This fork's coverage-expansion effort (tracked in #5), same bad-path test-writing round as #20 -- specifically while re-running Track B's
ENABLE_COVERAGEDebug-build measurement with this session's newly-added tests included, immediately after fixing #20.