| Summary: | REGRESSION(271184@main): [Win] crash under JSC::PolymorphicCallNode::unlinkImpl | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Fujii Hironori <Hironori.Fujii> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | ysuzuki |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=265361 | ||
|
Description
Fujii Hironori
2023-11-27 22:54:50 PST
(In reply to Fujii Hironori from comment #0) > Windows Release becomes crashy. > > Buildbot: builder WinCairo-64-bit-Release-Tests build 2839 : 271179@main > https://build.webkit.org/#/builders/728/builds/2839 Wrong url and regision. 271179@main is green. Buildbot: builder WinCairo-64-bit-Release-Tests build 2840 : 271184@main https://build.webkit.org/#/builders/728/builds/2840 No reliable way to reproduce the crash. But, the following command is likely reproducing the crash.
> python .\Tools\Scripts\run-webkit-tests --release --child=1 --no-retry --exit-after-n-crash=1 --iter=10 webgl/2.0.y/conformance2/textures/canvas
Not only Windows Release build, but also Debug builds are crashy. Buildbot: builder WinCairo-64-bit-Debug-Tests build 21395 : 271184@main https://build.webkit.org/#/builders/727/builds/21395 Regressions: Unexpected crashes (4) webgl/2.0.0/conformance2/textures/image_bitmap_from_blob/tex-3d-rg16f-rg-half_float.html [ Crash ] webgl/2.0.0/conformance2/textures/image_bitmap_from_image_data/tex-3d-rgb565-rgb-unsigned_byte.html [ Crash ] webgl/2.0.y/conformance/ogles/GL/operators/operators_017_to_024.html [ Crash ] webgl/2.0.y/conformance2/textures/canvas/tex-3d-rg8-rg-unsigned_byte.html [ Crash ] As far as I tryed bisection, 271184@main seems to be the culprit. I kind of doubt integrity of the builds on WinCairo buildbots. No other ports are reporting this crash. And from the code, I cannot find the path causing this condition. CallLinkInfoBase's destructor is always unregistering itself. So there is no way to have dangling CallLinkInfo in this linked-list. Ross, me, and Fujihiro are looking into it. This requires Windows port's debugging since there is no problems on the other ports. *** This bug has been marked as a duplicate of bug 265475 *** |