5/3/2023 0 Comments Appium memory monitorThe stuff which is not directly related to accessibility interactions might be executed in background threads good day to you. This is the reason XCTest requires it to be in idle state, at least periodically. Basically all UI interactions must by running on the main UI thread. You could find them if you dump xctest platform headers. Yes, these structures are internal XCTest classes. The whole chain looks like: test runner app process->xctest client->testmanagerd server.Īre XCElementSnapShot, XCAccessibilityElement process substructures utilising XCTest modules? Are they running in own threads? So basically any test runner is a separate application with its own process (although it is different from other "normal" apps, since it has more privileges and uses XCTest APIs). From my observations there is testmanagerd process running on the device and talking to the xctest client using its own special protocol. This is not documented anywhere (internal Apple stuff, yolo). Please inform if there is some helpful information which I can provide which may be required for problem resolution.ĭoes XCTest run as separate process/service/driver or it runs as a part of WebDriverAgentRunner-Runner process as an imported external module? I suppose that it crashes on device out-of-memory when reaching 2+ GiBs in memory usage.14.43.21.mov. The WebDriverAgentRunner-Runner process starts from just 20MiBs on start of the long scenario execution, before it crashed we saw this grown to 1.5+GiBs. These are just screen-recordings of short intervals during tests execution where it's clearly visible that the process continuously growth in memory usage. There is a long iterative app specific test scenario here containing clicks, swipes, page_source calls, on-screen device keyboard interaction, web elements properties requesting (like text, names and others) Additional info: At that moment after monitoring iOS processes on the device - it's clear that the WebDriverAgentRunner-Runner process isn't there already. After the iOS WebDriverAgentRunner-Runner process crashes appium continues tries to connect to it but has not success. This is not Appium server problem but the problem with WebDriverAgent. Real device or emulator/simulator: real iPhone XRĪfter upgrading to Appium version 1.21 we started to experience an issue of WebDriverAgent crashing after 12+ hours of test scenario execution in real device (this was not verified in iOS simulator, but could be the problem there also because the WebDriverAgentRunner-Runner process in the simulator also growth in memory usage highly during hours of execution.Mobile platform/version under test: iOS 14.5.1.Node.js version (unless using Appium.app|exe): v12.16.1.Desktop OS/version used to run Appium: MacOS.Last Appium version that did not exhibit the issue (if applicable): 1.19 (at least memory growth didn't lead to the process crash).Then the process crashes and no connection retries to WDA work from Appium server side. During long test runs iOS WebDriverAgentRunner-Runner process growth from ~20Mb to about 2Gbs of Memory usage in real iPhone XR device. Inside the loop / out side the loop I can't use the "driver.close" and also "driver.quit". back to the page where the elements present validate the properties (reference is the test data)Ĥ. start the for loop (i<= no of elements i++) for the below actions.ģ. Script is as follows:(I can't copy paste the script due to security reasons)ġ. Need to select each element >then click on preperties> validate properties (Around 12 elements need to validate) this page contins a web table with 100 Plus elements (services) exixts. Workign on the below scenario> returning out of emmory error- after 40+ iterations (around 2gb of memory usage it's not loading the throwing error)ģ.
0 Comments
Leave a Reply. |