[CRASH] All versions above v120 are crashing #242
Labels
bug
Something isn't working
Comments
|
Update: exactly the same result when I boot up into Mojave instead of Yosemite! |
|
I am actually also getting this. Totally strange since nothing in Chromium Legacy changed. It doesn't need to be a particularly advanced website, e.g. it happened on Hacker News which is fairly basic. Crash log attached. I'm seeing lots of |
|
Is it under a thread called "ThreadPoolUtilityWorker"? I figured out how to view my crash logs, and this is what it shows under the crashed thread: |
|
Interesting, for me the crashed thread is But your crash log is also implicating something ot do with TensorFlow ( |
|
Confirmed, and currently investigating. Sorry for the inconvenience as always. |
Maybe it's a difference between Mac operating systems? It looks like you're on 10.9. I get (I'm just relieved that it's not my old MacBook Pro suddenly freaking out.) |
|
Add me to the "me too" list... on 10.9 and indeed the ThreadPoolForegroundWorker thread. v120.0.6099.199.1 indeed seems to work |
|
Got it, we now need This should be fixed in the next canary/stable (maybe within a couple weeks). |
|
I have also experienced the same issue with the the same crashed thread ( |
I can confirm that I was able to get v127 to run without crashing, using the following shell command:
Is this a sensible workaround, or is there a better way to do it until a new release comes out? |
|
Same here with version 126.0.6460.0 on OSX 10.7.5, MacBook Crash report: |
|
Is this a sensible workaround, or is this the best way to do it until a new release comes out?
If this is the only workaround that is currently available and it doesn't kill performance completely then could it NOT be a sensible thing to do if you still want to use Chromium?
Running 120.xxxx is not an unsensible workaround too (as long as you don't do anything sensitive with it I guess). But 121.xxxx introduced auto-restarting of crashed extensions that's really useful and also fixed an issue for me where several sites (instagram included) didn't recognise the browser and sometimes asked me to log in again without having restarted the browser.
What exactly does that option do?
Looking at that backtrace I don't have much faith that this will ever be resolved unless someone has enough resources to run Chromium under valgrind or with some memory sanitisation feature. (The system malloc routines also have boundary guarding options; those could be a cheap way to get a better idea where the actual bug is).
There must be an out-of-bounds access somewhere that messes things up just enough to cause a crash who knows how much further down the line; if so: good luck matching cause and effect!!
What version of libc++ does Chromium Legacy (CL) use? I know it's linked in statically but is there a possibility that whatever changed is causing a lethal library version conflict (e.g. via a library that links to a different static libc++)? If not, does updating to a newer libc++ help?
The big question is also what can be causing this global failure (surely the Russians have better things ...).
Has anyone already tried to run the browser in safe mode, with all extensions disabled, to see if this is not caused by one of those?
Does the crash occur with a profile that does not use the browser sync feature? The way to test would probably be
- use another browser or Chrome on an officially supported OS to save a webpage known to cause the crash.
- confirm that that saved page caused a CL crash too
- create a new CL profile while not connected to the internet (browser can't phone home)
- open the saved page in that new profile
- if no crash, reconnect to the internet
- if no crash, sign in to browser sync
FWIW, I've had the browser crash while loading the changelog page of the updated TamperMonkey extension
|
|
--disable-features=OptimizationHints
Googling this I found cypress-io/cypress#22622
So there is indeed some downloading going on of a resource that will probably be used by the code in which we see the crash occur.
It would probably not hurt to disable OptimizationGuideModelDownloading too but would disabling that feature alone suffice too (after cleaning out all caches etc)?
|
|
If anyone is using #25, the latest version will add the |
|
Same here, thank you for confirming versions which do work. I am typing from phoe. |
See https://chromium.googlesource.com/chromium/src/+/HEAD/components/optimization_guide/ i don't entirely understand but apparently, Google remotely pushes some type of configuration to Chromium browsers. |
|
i don't entirely understand but apparently, Google remotely pushes some type of configuration to Chromium browsers.
Yes, that's what I understood too from the issue I linked to above. Can be as much as a 45Mb download (which would be a big amount of code if it's something like javascript).
Browsers apparently check for and download new versions of this (there's a flag to disable that behaviour, too) so it's more "pulling" than pushing ;) Either way it fits with my observation: the browser ran fine for me for maybe 5 minutes and then it crashed. And didn't stop doing that. Those few minutes things still worked must have corresponded to the browser (lazily) checking for a new version of the resource and downloading + installing it.
From reading around it seems to be some kind of feature related to AI (no thanks anyway) and embedded searches in the URL bar. I didn't see any impact of disabling the feature on a browser benchmark (antutu; but that was under Linux to be fair).
|
|
Guys do you have a direct link to v120. I'm trying to use original Safari on 10.11.5 but all it does it gives me a spinning wheel under assets. I can obviously launch VB win7 and download with firefox or on the phone. |
|
On Saturday October 26 2024 09:59:55 davids74 wrote:
Guys do you have a direct link to v120.
https://github.com/blueboxd/chromium-legacy/releases/download/120.0.6099.199.1-stable.lion/120.0.6099.199.1.zip
Here's also a direct link to the backported Waterfox G3.2.7 that I'm still using as my main browser on Mac. It no longer handles all of github but it does handle the releases and issue pages.
https://github.com/aeiouaeiouaeiouaeiouaeiouaeiou/waterfox-osx/releases/download/G3.2.7-osxfix-eol-current/waterfox-G3.2.7-osxfix-eol.en-US.mac.dmg
|
Just open the Terminal and run:
And any version of Chromium legacy will work. (Adjust the path if Chromium Legacy is not installed in the |
|
Hi guys.
It worked, but I needed to leave the terminal open, and rerun the command each time I restarted the Mac + relaunched Chromium.
I tried to use your chromium-legacy-downloader, the last one, downloaded 3 hours ago, but the Chromium installed doesn't want to launch: the icon in the dock bounce 3 times and disappears, whatever the Chromium version, Canary or Stable. |
Put "nohup" in front and "&" at the end:
"Nohup" means "no hangup" and it keeps the process going even if the terminal session quits. The ">/dev/null" bit just keeps it from storing the esoteric output from the shell command. |
|
On Saturday October 26 2024 10:21:23 Jonathan wrote:
> Guys do you have a direct link to v120.
Just open the Terminal and run:
`/Applications/Chromium.app/Contents/MacOS/Chromium --disable-features=OptimizationHints`
```
open -a Chromium.app --args --disable-features=OptimizationHints
```
will do the trick too.
IFF you've installed Chromium through the downloader prefpane then you can also edit the wrapper script for a permanent fix.
```
vi /Applications/Chromium.app/Contents/MacOS/Chromium
```
and add the extra argument just ahead of the `"$@"` (with a space between the 2 arguments).
If you haven't ... you can create a basic version of the wrapper script yourself - leaving that as an exercise to the reader O:^)
|
|
I am back in! I downloaded the 120 through VM Firefox and am typing from Chrome, directly on my outdated mac. I am here thanking you RJVB for suggesting the version that works. And it does! I downloaded waterfox dmg for safe measure. |
|
Coincidentally I thought it was something to do with star constellations. I just had a 48h ordeal to get my old phone be able to make card payments on a phone. |
|
Hi gpsvisualizer
Thanks for your answer, but the problem still remains: if I quit Chromium, it crashes again after relaunching if not relaunched with the Terminal and the shell command line. There is another solution, for those (like me) who have an outdated Mac, it's Palemoon : it runs on MacOS 10.7 and later, and despite not connecting to some sites it works fine. It also has a good list of extensions, including ad-blockers and cookie's helpers (I don't care about cookies and Cookies exterminator or Cookies Control Panel). |
cs.chromium.org, It's really hard to understand what exactly is being optimized here. I think roughly they use an ML model to predict which page resoruces may be requested in what order. I don't think the
Is this more recent than the last official version of Firefox supported on mavericks (78-ish?). Also palemoon still supports 10.9 iirc. |
Yes, that's true, it has to be launched that way every time you use it. The "nohup" and "&" additions just allow you to close the terminal app while you're using Chromium. I use Keyboard Maestro for pretty much everything on my Mac, so I'm just having KM launch Chromium via the shell command. It's working great. |
|
Hi Thank you gpsvisualizer, but I think I have found another solution : In my Home/Library/Application Support/Chromium folder there is a folder named "optimization_guide_model_store" containing 10 folders named with numbers : 2 - 9 - 15 - 20 - 25 - 26 - 31 - 32 - 34 and 36. Then, I reset the "optimization_guide_model_store" folder's authorizations to the "R/W" mode and relaunched Chromium 124.0.6367.207.1, which crashed a few seconds after connecting to a web site. The "optimization_guide_model_store" folder's was then refilled with the same 10 folders from "2" to "36". I erased the 10 folders and launched Chromium 120.0.6099.199.1, still looking at the "optimization_guide_model_store" folder : I saw the folders reappear one by one and stop at the "34" folder : only 9 folders, no "36" folder. Then I launched Chromium 124.0.6367.207.1, still looking at the "optimization_guide_model_store" folder and again Chromium worked fine until the folder named "36" came back and then Chromium 124.0.6367.207.1 crashed. The content of this "36" folder is a folder named "C0DAB6922330736D" containing a folder named "BAD0CB32F1D8E8C8" containing 2 files "model-info.pb" and "model.tflite". Now my Chromium 124.0.6367.207.1 seems to run fine with the "optimization_guide_model_store" folder locked in "read only" mode and containing only the 9 folders from "2" to "34". So, it seems that the crash is caused by the files in the "36" folder ??? Does it also work for you guys ? |
|
On Saturday October 26 2024 12:57:13 krackers wrote:
Or possibly the model itself changed which is triggering a bug in TFLite.
I think that's exactly what it is. And that also may mean that the bug will fix itself.
Is this more recent than the last official version of Firefox supported on mavericks (78-ish?). Also palemoon still supports 10.9 iirc.
Slightly, yes. The repo owner managed to do 10.9 compatible builds for a while; he posts here now so might chime in.
Most sites still work (including Whatsapp and Instagram) and it's very stable. Annoyingly Mozilla have broken its browsersync a few months back; that feature was long a reason for me to stay on Firefox.
|
|
On Saturday October 26 2024 14:10:45 ClaudeFR wrote:
The content of this "36" folder is a folder named "C0DAB6922330736D" containing a folder named "BAD0CB32F1D8E8C8" containing 2 files "model-info.pb" and "model.tflite".
Now my Chromium 124.0.6367.207.1 seems to run fine with the "optimization_guide_model_store" folder locked in read only mode and containing only the 9 folders from "2" to "34".
So, it seems that the crash is caused by the files in the "36" folder ???
Yes, that seems very plausible! The numeric folder names probably correspond to the TensorFlow version included in the Chromium build. The v119 Chromium version I have on Linux stops at 34, for instance.
It's interesting that all the older folders come back too but looking at the timestamps I see that Chrome v119 updated the following files when I launched it this afternoon:
./9/A3BFD4A403A877EC/1E13FC379A93BF27/model.tflite
./9/A3BFD4A403A877EC/1E13FC379A93BF27/model-info.pb
./13/A3BFD4A403A877EC/6C0E9A2F51D634D7/model-info.pb
./13/A3BFD4A403A877EC/6C0E9A2F51D634D7/model.tflite
./15/A3BFD4A403A877EC/E47312EE2645BE59/model-info.pb
./20/A3BFD4A403A877EC/9060B206DACFCA8F/model-info.pb
./20/A3BFD4A403A877EC/9060B206DACFCA8F/model.tflite
./25/A3BFD4A403A877EC/DBBF574E713767FF/visual_model_desktop.tflite
./25/A3BFD4A403A877EC/DBBF574E713767FF/model.tflite
./25/A3BFD4A403A877EC/DBBF574E713767FF/model-info.pb
./32/A3BFD4A403A877EC/6E3AF2B86B52A2B3/model-info.pb
./32/A3BFD4A403A877EC/6E3AF2B86B52A2B3/model.tflite
./34/A3BFD4A403A877EC/F1534B57116257BC/model-info.pb
./34/A3BFD4A403A877EC/F1534B57116257BC/model.tflite
That strongly suggests that Chromium does not just use the files from the latest folder (36) but there's some hierarchical organisation. Kinda nice of them if that's an effort to keep supporting older browser builds, but it also give a software solution to prevent the offending file(s) from being loaded while still maintaining a maximum of whatever this does exactly.
"Just" figure out where these files are being loaded, and block access to folder `36` there. And any later folders as their content might build on the content of folder 36.
|
|
Also fwiw there are backported builds of modern firefox for 10.9 - https://github.com/i3roly/firefox-dynasty/ |
|
Also fwiw there are backported builds of modern firefox for 10.9 - https://github.com/i3roly/firefox-dynasty/
Now that's good news, or potentially so. How much experience do you have with its stability, speed etc? I see you filed a number of issues (didn't look if the closed ones were fixed or just rejected).
|
|
Hi RJVB Edit at 01:22 : a "40" folder has just appeared… and Chromium 124.0.6367.207.1 still works fine… is it a bug fix ? |
tagging @Wowfunhappy to chime in here since he uses it more than I do. Edit: Discussion branched to thread in GH discussion page.
Is it possible that this is an upstream issue as well (i.e. if you were running official chrome 124 you'd see the same)? |
|
Yesterday I went back to Chromium Legacy 120.0.6099.199.1 on my iMac (mid-2010) with Yosemite (10.10.5). It works well. So folder 36 does not crash this version of Chromium Legacy. I run Chromium Legacy without the downloader, which in my opinion only slows the app down. On Yosemite, the app with the downloader also asked for permission to access my account every time it started. |
One more note on this: When I returned to version 120.0.6099.199.1, I only sent the app itself to the trash and didn't delete the application support files. The folder “36” in the optimization_guide_model_store folder was already created yesterday morning at 9:26 a.m., i.e. still by Chromium 124.0.6367.207.1. Incidentally, all the other folders in the optimization_guide_model_store folder are much older; the folder “34”, for example, dates back to December 2023. |
|
On Saturday October 26 2024 16:06:48 ClaudeFR wrote:
The 2 files "model-info.pb" and "model.tflite" in the "36" folder were dated today at 00:54, although the other files of the "2" to "34" folders are dated yesterday at 22:27 : it seems that only the last folder is used or updated ?
All files I listed above were dated at the time that I first launched Chrome yesterday, but again that was on Linux. Whether or not files are dated with their upstream timestamp or the timestamp where they were downloaded may depend on the OS.
It would stand to reason too that Google only push the files that have updates or introduce new functionality. The most logical explanation for the organisation with numbered subdirs would be those correspond to different API TensorFlow versions, introducing new features. With this organisation they can continue to update the models used by older browser versions.
So it may be possible that folder “36” will not be created until the 124.etc. versions of Chromium Legacy.
That folder will be created by (release/stable) versions v121 and up, presumably because they are built with a TensorFlow library that is new enough to use the files in that folder.
It's indeed an interesting question if the official builds suffer the same problem, but I think if that were the case the episode would have been closed by now. Imagine just about everyone's browser crashing constantly, as well as every new enough ChromeBook. In fact, it seems unlikely that the update to those models would never have been pushed because the crash should have been detected in-house.
|
|
I can confirm that everything works fine, with no special --disable-features flags, if I set folder "36" to read-only. Chromium 127 also creates folders 39, 40, 43, and 45, but they don't seem to blow anything up. |
|
I have now also deleted the So I created the directory there myself and set it to read-only. Then I started the https://github.com/blueboxd/chromium-legacy/releases/tag/1303823 ‚Chromium Legacy 127.0.6494.0 (Official Build) (x86_64)‘-version again. So far no crash. macOS Mavericks 10.9.5 |
|
==> However, I wonder what the folder '36' is used for, not that there will be other problems in the future because it is not writable.
Not having any content in there just means it won't be loaded and that whatever functionality it provides won't be available.
Just blocking access to the "36" subdir corresponds to the software solution (idea for a patch) I suggested above.
Creating an empty, write-protected "36" subdir is something wowfun's prefpane could do, or rather, add a routine to the Chromium wrapper script that does this so it will be done for every user who launches Chromium Legacy.
Thing is, it leaves the door open to future re-occurrences of the issue. It doesn't seem farfetched to think that TensorFlow itself is becoming complex enough to expose issues in libc++ . And since libc++ is part of the LLVM project there will probably be very little upstream considerations for such issues given how aggressively they drop support for older OSes.
FWIW and possibly an open door: MacPorts has patches for current LLVM versions to make them work on legacy OS versions, contributed in part by Apple employé and LLVM contributor Jeremy Huddlestone.
|
But it seems so much cleaner to just add the command line flag that turns this off. Do we really want this anyway? |
|
But it seems so much cleaner to just add the command line flag that turns this off.
Definitely easier and no risk for re-occurrences. Or you could use the commandline flag that turns off downloading (and delete the "36" subdir), to preserve whatever functionality this is for that currently works.
Do we really want this anyway?
I think the question should be "What does this really do and do we need/want that functionality"...
It strikes me as a bit odd that they'd use a complex vector calculus library just for a fancy omnibar-or-whatever search feature; maybe it won't hurt to raise the issue at hand in Chromium circles (at least someone must have a "gee, that's interesting" reaction!) to get some feedback? Is there anything about why the feature disabler was introduced in the Chromium commit log?
|
|
Had this problem too on Mojave, installed 120.0.6099.199.1 instead, which works fine. |
|
I think I'm seeing the same issue on 10.13. Weird that it was fine and then started all at once. I figured it was an extension that had updated, but that doesn't seem to be the case? Anyway, here's my dump: |
|
@JackCico wrote
Wow, this actually worked for me on 10.13. No crashes. Thanks very much for figuring that out and sharing the information! Here are the commands I executed in Terminal: |
|
Can you paste your pļū kaka somewhere else? |
|
I've been home last week and turned on my yosemite mbp 4.1, nothing crashed, I used it for over an hour, maybe two. The version is over 120 but no the latest, this one doesn't do the "link-pulling over the tab bar" bug, so I stayed on this. |
Does it mean that Empire strikeback is over? That is that there was actual problem that Google has fixed with its updates? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Starting this afternoon (2024-10-25), Chromium is crashing whenever I visit a Web site that has any complexity at all; usually, the problem occurs when I try to login to a Web site. (For example, https://github.com/)
I tried clearing my cache, and I even tried deleting the entire Chromium folder from "~/Library/Application Support/". Things would start out normal and then immediately crash when I tried to visit a Web site that was more than simple HTML.
Sometimes logging in via an Incognito Window works, but not always. (Somehow I wonder if syncing and/or authenticating on google.com might be part of the problem.)
The following versions are all crashing:
v121.0.6167.139.1
v123.0.6303.0
v124.0.6367.207.1
v127.0.6494.0
This one does not crash:
v120.0.6099.199.1.zip
Desktop (please complete the following information):
Logs
I'm happy to provide logs if someone can tell me how.
Anyone else seeing anything weird today?
The text was updated successfully, but these errors were encountered: