Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upModule specifier parsing failed in webgpu wpt tests #27061
Comments
|
@kunalmohan Do you have any examples of the URLs that end in *? I haven't found any yet. |
|
I tried to reproduce this in my local and I found it's an intermittent panic
With running the test around 10 times, I only got the |
|
It panics for me everytime and for the same tests :(
works fine. So maybe it isn't related to Others URLs that panic-
Does the build profile make a difference? (ideally it should not) |
|
Interesting! With adding some logs, I saw this while running the
Also, I confirm this one is parsed by |
|
I haven't been able to reproduce this problem when running Edit: nevermind, just reproduced it. |
|
When I use a debugmozjs build, I see:
I strongly suspect we're holding on to a pointer that gets moved or freed by the GC somewhere.
|
|
I verified my theory by setting a breakpoint at the start of finish_dynamic_module and printing the module specifier data in the debugger (which showed expected values), setting a watchpoint on the string data in member and continuing. The watchpoint triggered in a GC that poisoned the string data which occurred while executing the module. |
|
This will be fixed by updating to a version of mozjs that includes servo/mozjs#254. |
|
@jdm thanks for the fix! Just one question, does that mean the assertion thrown by |
|
That is correct. |
@jdm @CYBAI really appreciate you both helping me so much in my project! Thank you!
I replaced the optional-chaining syntax and tested on my local system with the
dynamic-modulebranch rebase over latest master.gpu-test.jscompiles successfully. But there is a different panic now (which is unrelated to dynamic module)-I also realised that we already have test-suite under
tests/wpt/web-platform-tests/webgpu. So I tried running them and most of them run successfully (i.e. they fail instead of throwing anError) except a few that crash with the above panic. I noticed that the URL for those tests end with*.Also I want to confirm one thing. The tests
Fail(instead ofError) after removing the optional chaining operator. Will it be safe to say that there is no more unsupported syntax in the tests? (Also, I did not see anyfail to compile modulewarning in the logs while running the live test, apart from the above panic)Originally posted by @kunalmohan in #25439 (comment)