Extensions Randomly Crash On Launch And During The Session #75
Comments
|
From the crash log, it looks like you're using a Canary build. You should try on the latest stable build. This probably isn't a Chromium Legacy bug. |
|
This still happens in 104. |
|
🙁 Does this happen regardless of which extensions you enable? For example, I'm using: And none of these extensions are crashing on launch on Chromium 104.0.5112.79 on Mavericks 10.9.5. It would be good to see if I can replicate the problem using the same set of extensions you're using, and/or if installing/enabling a particular extension is causing all of them to crash. |
|
Just spit balling...did you try collecting extension errors and/or clearing cache... |
|
@Wowfunhappy It happens mostly with Adguard and - to a lesser extent - Wayback. |
|
This happened to me on Lion on first launch after updating to a new Canary version. |
This CL adds a UMA histogram which tracks the reason that the FedCM account picker was dismissed. BUG=1343857 (cherry picked from commit 48eaa14) Change-Id: Ia2f1d27d3c811149b8d1ad98cf8ac2f740191c70 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3774541 Reviewed-by: Yi Gu <yigu@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Commit-Queue: Peter Kotwicz <pkotwicz@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#1027117} Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3788737 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Gary Kacmarcik <garykac@chromium.org> Cr-Commit-Position: refs/branch-heads/5195@{#75} Cr-Branched-From: 7aa3f07-refs/heads/main@{#1027018}
Patching system-initiated -[NSWindow orderWindow:] calls has caused issues in fullscreen. For example, this function will be called when a sheet modal is created and the sheet will appear to be occluded by other windows. This CL patches only chrome-initiated calls instead. I couldn't find out a reliable way to add regression test. Neither -[NSWindow orderedIndex] or -[NSWindow childWindows] is reliable for testing sheet window that is attached to a child window. (cherry picked from commit bd812e5) Bug: 1352634, 1324216 Change-Id: I3ee43bae3c248da433f486c6444fda55b5b7121b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3842864 Reviewed-by: Avi Drissman <avi@chromium.org> Commit-Queue: Keren Zhu <kerenzhu@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#1037901} Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3854876 Cr-Commit-Position: refs/branch-heads/5249@{#75} Cr-Branched-From: 4f7bea5-refs/heads/main@{#1036826}
|
Happens to me all the time on Mavericks. Extensions crash every few minutes. Bitwarden and uBlock Origin are some of the most frequently crashed extensions. |
|
Is anything logged upon extension crash? |
This cl only affect Lacros on-device config builders like lacros-amd64-generic-chrome-skylab. This cl will certainly NOT affect linux-lacros builders(linux-lacros-tester-rel, linux-lacros-rel, etc) or any other platforms. This CL will update cros image version for skylab tests. CROS_BOARD_LKGM is updated according to chromeos/CHROMEOS_LKGM; CROS_BOARD_DEV, CROS_BOARD_BETA and CROS_BOARD_STABLE are updated according to Omaha. If this CL caused regressions, please revert and pause the autoroller at https://luci-scheduler.appspot.com/jobs/chrome/lacros-skylab-tests-cros-img-roller Also please file a bug to OS>LaCrOS>Partner, and CC svenzheng@chromium.org, yjt@google.com. R=rubber-stamper@appspot.gserviceaccount.com Requires-Testing: True Change-Id: Id08e9d02a4b94ddb4ff3bced31a192a362eb015c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3963635 Auto-Submit: skylab-test-cros-roller@chops-service-accounts.iam.gserviceaccount.com <skylab-test-cros-roller@chops-service-accounts.iam.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5359@{#75} Cr-Branched-From: 27d3765-refs/heads/main@{#1058933}
How to check the logs? |
Change-Id: I3b5535607e58dd5156b704c2b07a7a9e6c79028e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4127455 Bot-Commit: Chrome Release Bot (LUCI) <chrome-official-brancher@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5481@{#75} Cr-Branched-From: 130f3e4-refs/heads/main@{#1084008}
This CL may cause a small binary size increase, roughly proportional to how long it's been since our last AFDO profile roll. For larger increases (around or exceeding 100KB), please file go/crostc-bug. Please note that, despite rolling to chrome/android, this profile is used for both Linux and Android. If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/afdo-chromium-beta Please CC c-compiler-chrome@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Chromium Beta Branch: https://bugs.chromium.org/p/chromium/issues/entry To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md Tbr: c-compiler-chrome@google.com Change-Id: I83448ba71b3ae0f269fdf6d8b7ab52a014227844 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4211493 Commit-Queue: Chrome Release Autoroll <chromium-release-autoroll@skia-public.iam.gserviceaccount.com> Bot-Commit: Chrome Release Autoroll <chromium-release-autoroll@skia-public.iam.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563@{#75} Cr-Branched-From: 3ac59a6-refs/heads/main@{#1097615}
This reverts commit 1e8bb18. Reason for revert: The metrics for recording these changes is not present in Beta, and the metrics is not working correctly in Canary. CL reverted here: https://chromium-review.googlesource.com/c/chromium/src/+/4221985 Bug: 1414259 Change-Id: Ib36e7ae28436659c05d71ec622f2b799ce36934a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4297978 Commit-Queue: Ritika Gupta <ritikagup@google.com> Reviewed-by: Shakti Sahu <shaktisahu@chromium.org> Reviewed-by: Ritika Gupta <ritikagup@google.com> Cr-Commit-Position: refs/branch-heads/5615@{#75} Cr-Branched-From: 9c6408e-refs/heads/main@{#1109224}
Update custom icon dimensions 32 x 20 -> 40 x 24 on "Payment methods" and "Edit card" pages. Payment methods page Mock: https://www.figma.com/file/N6F3DN9prdEzQiylOtVBCW/X-PA-share?node-id=2-7334&t=tHB6xlatk0CGPBjx-0 Current: https://screenshot.googleplex.com/9hXssgDwN7hefkt New: https://screenshot.googleplex.com/AbMbYZNW3X9G2Aw Edit card page Mock: https://www.figma.com/file/N6F3DN9prdEzQiylOtVBCW/X-PA-share?node-id=2-7011&t=tHB6xlatk0CGPBjx-0 Current: https://screenshot.googleplex.com/5JBvMxcC5QuGHag New: https://screenshot.googleplex.com/9Lr9bV24CC67fmR Note: Only custom icon dimensions are updated. Network icon dimensions will be updated in a future change. All updates are behind AutofillEnableNewCardArtAndNetworkImages flag. (cherry picked from commit ac96bff) Bug: 1417919, 1427669 Change-Id: I31b95e22e6624be3102e1dcbf1bd6be1aa5e467f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4357238 Reviewed-by: Friedrich Horschig <fhorschig@chromium.org> Reviewed-by: Lijin Shen <lazzzis@google.com> Commit-Queue: Vishwas Uppoor <vishwasuppoor@google.com> Cr-Original-Commit-Position: refs/heads/main@{#1122057} Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4373879 Cr-Commit-Position: refs/branch-heads/5672@{#75} Cr-Branched-From: 5f2a724-refs/heads/main@{#1121455}
This feature interferes with some internal code and should not be enabled in experimental-web-platform-features until that is resolved. (cherry picked from commit f08e3d1) Bug: 1439567 Change-Id: I690084acd8f6cac31b58fde765ef4564434d0b6e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4491244 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Auto-Submit: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#1137309} Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492319 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5735@{#75} Cr-Branched-From: 2f562e4-refs/heads/main@{#1135570}
Idem here, just maybe not that often. |
Change-Id: I684ab8dcda1ba6d46f3e09853e8bdc553a65fc58 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4777442 Auto-Submit: Ben Mason <benmason@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5938@{#75} Cr-Branched-From: 2b50cb4-refs/heads/main@{#1181205}
|
Exactly. And they crash so often that the browser becomes barely usable. Can someone please fix it? Would love to help wherever I can. |
|
For what it's worth, some extensions crash much more often than others. uBlock Origin is the main one that crashes for me.
I've been trying to capture a crash when Chromium is launched from the Terminal in the hopes that something is logged there, but so far extensions have refused to crash when I'm actually looking for it. 🤷♂️ |
|
...literally seconds after posting the above, I finally managed to get uBlock Origin to crash while Chromium was launched from the Terminal. And confirmed that nothing is printed there either. So, no, I cannot figure out where these crashes are logged! If I may make a suggestion... could we consider automatically reloading any extensions that crash (maybe after ~10 seconds or so)? It would of course be better if they did not crash in the first place, but Chromium Legacy is always going to be a less stable than mainline and that's okay. |
|
If I may make a suggestion... could we consider automatically reloading any extensions that crash? It would of course be better if they did not crash in the first place, but Chromium Legacy is always going to be a less stable than mainline and that's okay.
That's an idea, but with a restart rate limiter so that nothing gets locked up of bugged down by an extension that crashes immediately and consistently (i.e. one that actually does have a bug in it).
|
|
In the extensions settings, to find the extension error log, click on the Details chip in the extension tale and turn on "Collect errors". The Adguard Extension is the gravest offender. This is what I'm seeing 👇 I reported these errors to the Adguard team but they told me they could make nothing of it. |
|
I've checked these. Nothing seems to appear following a crash, at least for me. On Oct 5, 2023, at 11:39 AM, scrutinizer11 ***@***.***> wrote:
In the extensions settings, to find the extension error log, click on the Details chip in the extension tale and turn on "Collect errors". The Adguard Extension is the gravest offender. This is what I'm seeing 👇
I have reported these errors to the Adguard team but they told me they could make nothing of it.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
On Thursday October 05 2023 09:01:37 Jonathan wrote:
I've checked these. Nothing seems to appear following a crash, at least for me.
On Oct 5, 2023, at 11:39 AM, scrutinizer11 ***@***.***> wrote:
I have reported these errors to the Adguard team but they told me they could make nothing of it.
There's also no guarantee that this is what causes the crash...
|
|
Have you tried running chrome with verbose logging enabled? Also if you go to chrome://crashes any crash log there? |
|
I'm actually getting many more crashes than usual.
It doesn't work via The I really don't want to start messing with managed preferences... my hope is that blueboxd can just make the two-line change to Chromium's source at some point. |
|
On Thursday November 23 2023 04:47:41 Jonathan wrote:
I really don't want to start messing with managed preferences...
Actually, I think I already get a notice that my preferences are being managed by my organisation (as if I'm so organised... 8^) ). Not sure what that would be about but I suppose it has to be because of something done when I first installed Chromium Legacy and the corresponding updater PrefPane (or the 1 time I updated through that).
|
|
Yeah that's the PrefPane updater, which sets other policies via |
|
Yeah that's the PrefPane updater, which sets other policies via `defaults write`. Use the PrefPane uninstaller to remove that.
Is there a reason to want that? The PrefPane is a nice way to know how much newer the current stable version is ;)
|
This is interesting. Yes I remember reading there are different "levels" of preferences. and someone ran into the same issue in https://stackoverflow.com/questions/76060139/trying-to-change-chrome-extensioninstallforcelist-policy-from-recommended-to which seems to suggest that simply created Looking at source for |
|
I got a uBlock Origin crash earlier, after starting Chromium from a shell. This appeared on the terminal at about the same time: |
|
Today I got an extension crash alert (Windscribe VNC) and at (almost exactly) the same time a Chromium Helper process crashed giving me this backtrace in the problem reporter: |
|
OK, sorry for the noise, I hoped this might help.
|
|
@krackers Since Bluebox appears to be busy for the moment, do you know if I could potentially |
|
If the only solution is a memory patch, that isn't worth doing since it would break on every update.
Why, not even if you only do it for release builds?
With the current latest (I think) release I can have a 30 min. browsing session where no extension crashes, or I can run into an episode like the other day where I spend a certain time doing nothing but clicking on extension crash popups because they keep crashing in a loop.
I know it's easy to say for someone who can't help with the hacking effort but I think that the issue is debilitating enough to justify a certain effort to work around it until an actual fix is found.
If exporting a "presumably not exported symbol" isn't trivial (overly complicated build system?) can't you patch the code? If there's a code path the restart crashed extensions conditionally it should be possible to bypass the condition check and just hardwire the restart?!
|
|
Sorry, I personally don't want to spend time on a memory patch if I will have to update the offsets each time a new Chromium build is released.
Yes, that is obviously preferable. The problem is that building Chromium is extremely difficult, not to mention CPU intensive. Bluebox has some sort of very impressive automated build system set up. |
|
From the latest posts, I deduce that these extension crashes will never get fixed. My solution was to ditch Adguard, a constant pet peeve, altogether for uBlock Origin. It hasn't had a single crash (knock the wood). |
scrutinizer11
changed the title
|
> can't you patch the code?
Yes, that is obviously preferable. The problem is that building Chromium is extremely difficult,
No doubt about the latter, but from what I've seen of it it will do incremental/re-builds that take a lot less time if you modified only 1 or a handful files (that aren't headers that get included by everyone else). Without having looked at the code my guess would be that we're talking about a single function where you'd have to remove/comment-out a single if, and it also seems likely that this would be in code that doesn't change very often.
…---
Sadly uBlock Origin was part of the crash orgy I had the other day. I stopped reading the balloon text after the 1st few re-popups but I'm pretty certain uBO didn't crash less than the others. TamperMonkey was another repeat offender, as was the Windscribe VPN extension, can't really remember the others.
|
|
We're discussing a one-line change (change Long story short, I'm really not looking to offer alternative Chromium Legacy builds on my end. What should really happen is this one-line change should be incorporated into Chromium Legacy, but at the moment I'm not sure how to get this on Bluebox's radar against all of the noise on the issue tracker. |
|
@Wowfunhappy I don't believe dyld interposing would work because chrome is wholly statically linked (with the exception of the system libraries) so dyld doesn't even have anything to do here. If the function isn't inlined and it has its own symbol then you could use something like libSymRez to get the address of it (even if it's not exported, which it probably won't be) and patch it from there. You could probably check by using Btw you tried forcing policy config via cmd-line and it didn't work? |
|
Looks like I was too hasty to conclude. uBlock mirrors AG falls on heavy sites, especially Reddit. AG was crashy on YouTube while uBlock is more enduring. |
|
@Wowfunhappy I don't believe dyld interposing would work because chrome is wholly statically linked (with the exception of the system libraries) so dyld doesn't even have anything to do here.
@krackers but how difficult (or how much work) would it be to hardwire the auto-restart behaviour as part of the patches that are undoubtedly already applied?
|
|
You mean if you modify source code? Just one line. But until bluebox includes it as part of his builds, are you going to be rebuilding chrome from source yourself? |
|
Oops, sorry, I thought I was answering to blueboxd, my bad!
|
|
Oh, look at that! It looks like extensions should be restarting automatically in the latest stable (121.0.6166.160.1). I just did some tests where I intentionally stopped extension processes, and it seems to be working for me! |
|
Although the extension is reloaded automatically, the notification still appears, which is very mildly annoying. I wonder if that could be hidden? |
|
@Wowfunhappy Is the extension a native mac notification center notification, or a window generated by chrome? If it's the former you can probably swizzle notification center stuff to selectively block certain things. There might have even been a SIMBL plugin long ago that did this blacklist behavior, but maybe I'm misremembering. |
|
@krackers Generated by Chrome. :( |
|
@Wowfunhappy you could probably still do something hacky where you hook nswindow create and detect the crash window by seeing if it's borderless mask and matching dimensions. |
|
@krackers Generated by Chrome. :(
But they make them look a lot like native notifications .... and at least they don't accumulate in the notification centre ;)
|
Describe the bug
Chromium shows notifications about extensions that crashed on launch.
To Reproduce
Such extensions as Adguard (including but not limited to) crash immediately and often trigger the entire crash cycle
Expected behaviour
No extension crashes.
Desktop (please complete the following information):
Logs
chromium10505170.log
The text was updated successfully, but these errors were encountered: