Safari crashes with segmentation fault on Monterey

Question

Created Jun ’22

Replies 1

Boosts 1

Views 1.3k

Participants 2

Issue: Safari browser crashes consistently when I run a Selenium automation script for a very simple use case: Enter username & password and press the Sign in button.

Browser crashes as soon as the button is clicked, before the home page loads up.

Please refer to the attached js file for script and steps to reproduce. Also attaching Safari crash logs from ~/Library/Logs/DiagnosticReports/.

Can see a segmentation fault had occurred with KERNEL_INVALID_ADDRESS due to bad memory area being accessed:

"exception" : {"codes":"0x0000000000000001, 0x0000000000000040","rawCodes":[1,64],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS at 0x0000000000000040"},
"termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":48287},

Product Specs:

MacOS Monterey version 12.2.1

Mac mini (2018)

Processor: 3Ghz 6-Core Intel Core i5

Memory: 8GB 2667 MHz DDR4

Graphics: Intel UHD Graphics 640 1536 MB

NOTE: Issue is NOT related to Selenium since this issue is only seen in Monterey only for particular product specs consistently. Did not face this in Big Sur/ Catalina/ Mojave/ High Sierra, etc. Also test runs fine in Chrome, Firefox & Edge browsers in the same machine.

Crash may be reproducible only in some versions of Monterey with particular hardware configurations. This is an error related to segmentation fault due to bad memory access so it's pretty clear this has to be hardware dependent.

Safari-2022-06-24-152240.txt

reproduce_safari_crash.js

Boost

Answer 1

ngfeldman OP

Nov ’22

We were hitting what I think is the same error at my organization. The specific criteria that seemed to be needed to reproduce the error were:

Safari is being run via Webdriver (or perhaps more accurately, it is run using "Remote Automation")
The "Cross-Origin-Opener-Policy (COOP) header" experimental feature is enabled in Safari (from the menu bar: Develop > Experimental Features > Cross-Origin-Opener-Policy (COOP) header)
The web response contains a "Cross-Origin-Opener-Policy" header

Therefore you might be able to work around the issue by either disabling the "Cross-Origin-Opener-Policy (COOP) header" experimental feature or by modifying your web server not to return the "Cross-Origin-Opener-Policy" header.

We discovered the issue only after two things happened:

Our automated test suite began using a combination of MacOS 12.6.1 with Safari 15 to run integration tests against our web server.
We upgraded the version of Django used to run our web server from version 3 to version 4, which begins setting the "Cross-Origin-Opener-Policy" header on all responses by default.

0