-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panic (NPD): browser.mapPage -> Page.GetKeyboard
#4128
Comments
Hi @yevk ! Thanks for the report! Out of the curiosity, does the issue persist in k6 v0.53, like the same way as you found that screenshoter started panicing in k6 v0.54? |
Hey @olegbespalov, I'll test it tomorrow and get back to you. Should I also test 0.54? |
@yevk thanks!
If possible, yes, please. Just for more context, since we have no minimal script (yet), I'm wondering to prove (and maybe find out) if perhaps some change between v0.53...v0.54 causes these nil ponter panics. cc: @ankur22 |
@olegbespalov, same panic with 0.53:
|
@yevk I see 😢 thanks for checking 🙇 we will investigate and fix it then! |
@olegbespalov, I also tested with 0.54, same panic:
|
@olegbespalov, please let me know if you want me to test anything or provide more information. I'm currently blocked by this, trying to find a temporary workaround. |
Thanks for the quick feedback @yevk. I'll take a look to see how much effort it is to fix the issue. |
@yevk could you share your test script? Initial InvestigationIt looks like go.k6.io/k6/js/modules/k6/browser/browser.mapPage({{0x1f48e70, 0xc0032b8340}, 0xc0006134d0, 0xc003c1f200, 0xc0037f5600, {0x1f32ae0, 0x2f4c040}, {0x0, 0x0}}, 0x0)
/go/pkg/mod/go.k6.io/k6@v0.55.1-0.20241213083140-745f0d48d305/js/modules/k6/browser/browser/page_mapping.go:203 +0x1c6e mapPage takes two parameters, where the second parameter is I took a look at the code, and there's a chance that we're getting a
I can only see this race condition occurring when the load generator (where k6 is running) and or chrome instance(s) are under heavy load, which feels like it loosely correlates the issue description. Why we're getting these CDP events is kind of a mystery. It could be due to timeouts occurring and the iteration failing, which would close any @yevk could you check the resources of the load generator and or chrome instance(s) when you see this failure? |
@ankur22, unfortunately I can't share the script. I'm trying to create a simple, clean script to reproduce and share with you. I haven't been able to achieve this yet, I will update if I can. About checking the resources load, could you provide me with more specific directions for what you'd like me to collect? |
@yevk, if you could get graphs of the CPU, RAM, network and disk usage for the machine(s) running k6 and chrome while the test is running, that would help identify whether the compute resource is the issue that could be causing this test ending/race condition. Here's some links that might help you:
However, i just reread the original issue description and just spotted this: "The machine running the test has many CPUs and a lot of RAM (both are not fully consumed during tests). I also optimized the OS using the K6 optimization guide." A simple script that replicates this would be useful 🤞 🙇 |
@yevk after the checking the code, we got an assumption that the possible thing what happen is that we're reaching a default timeout for fetching the page, which is I'm not mistaken is just 30 secs. So we adjusted the code and it should explicitly error #4132 Could you please verify if the version from that branch (you could install it by If it starts errors about the timeout, that means that we were right and the way to go is just increase the timeout by passing an environment variable like Please let us know how it goes and if it helps! |
@yevk just FYI, I've updated the original branch so the latest k6's install instruction is |
@olegbespalov thanks for the update! I ran a few tests, so far no panics. I want to do a few more in different variations, then I'll update you with the results. I don't feel well right now, so I'll probably do it on Sunday. |
@yevk thanks for the update and no rush with checking! 🙇 P.S. get well soon! P.P.S. we'll be probably curious to learn what helped, just fix or fix + configure timeout |
Hey @olegbespalov, I have results for the original fix version.
With the fix, the original panic is gone, even without setting the timeout. The above is using your original fix version. Let me know if you want to me to repeat with the updated fix. With the fix, now there's a different panic (mostly consistent). I think it's unrelated to the fix as it also happened with the official 0.55.0 version + timeout:
|
@olegbespalov, thanks for the quick response and fix! |
Brief summary
k6 panics during a long running test with many VUs, each VU creating multiple pages.
Each VU creates a single (non-default) browser context, which is then used to create all pages for that VU.
k6 version in the stack trace is a patch from grafana/xk6-browser#1502. Same issue happens with GA 0.55.0.
Chrome version:
Google Chrome 131.0.6778.139
(stable)I couldn't reproduce the panic using a simpler script and I can't share the internal scripts I use.
The machine running the test has many CPUs and a lot of RAM (both are not fully consumed during tests). I also optimized the OS using the K6 optimization guide.
k6 version
0.55.0
OS
Ubuntu 22.04
Docker version and image (if applicable)
No response
Steps to reproduce the problem
I tried reducing the number of VUs (from 150 to 70) and it did help, around 70 VUs did not reproduce the panic. Although I would consider this a weak signal.
I traced the code where the panic is coming from.
The panic is at:
But I think the problem begins earlier, in:
In
mapPage
, most of the values defined inmapping
are functions, except forkeyboard
,mouse
and a few others, which accessp
whilemapping
is being constructed.It panics when
"kyboard"
is evaluated.p.GetKeyboard()
is called whilep == nil
. Looks like nothing else inmapPage
is accessingp
prior to "keyboard".Further down the stack:
The call to
mapPage
is coming frommapBrowserContext
, from within the promise fornewPage
. This is where I lost track of what leads topage
beingnil
.Here are some of the last log entries from
k6 --verbose
(the last log is always cut off at different length on each run):Expected behaviour
No panic - worst case should abort with error.
Actual behaviour
Panic
The text was updated successfully, but these errors were encountered: