Chromium Browser seit ein paar Wochen instabil, noch jemand?

R

Rosendoktor

Well-Known Member
Hi,

vor ein paar Wochen hat der bis dahin sauber laufende Chromium Browser zu spinnen angefangen. Manche Tabs frieren nach unbestimmter Zeit beim Browsen ein, irgendwann kommt dann die Meldung dass der Tab nicht reagiert, nach schliessen und neu laden geht es manchmal wieder, manchmal nicht.

Los ging es damit nach einem grösseren System- (10.3-RELEASE-p7 auf -p8 glaube ich) und Paketupgrade, wobei der Chromium Browser selbst nicht aktualisiert wurde (Version 52.0.2743.116).

Als später Chromium selbst auf 52.0.2743.116_1 aktualisiert wurde, hab' ich vergeblich gehofft.

Als ich 10.3 auf 11.0 upgegraded habe, hab' ich auch vergeblich gehofft.

Immer noch dasselbe mit den abstürzenden Tabs. Hab schon die Extensions (nur Ghostery) und die Proxy Einstellungen zurückgesetzt, bringt auch nichts.

Hat ausser mir noch jemand solche Probleme mit Chromium?

Gruss,
Robert
 
Insbesondere mit bei (sehr)vielen offenen Tabs will Chromium offenbar zumindest kurzfristig Platz unter /tmp belegen, wenns den nicht gibt, murkste das Ganze dann so (s.o.) oder ähnlich herum.
Nachdem ich mein tmpfs unter /tmp und dessen Quota aufgelöst habe, ist das Problemchen zumindest hier verschwunden.
hth
 
Leider wurde das "Aw, Snap" Verhalten, mit der ein Tab abgestürzt ist und man ihn sofort (fast immer) erfolgreich neu laden konnte verschlimmbessert worden. Jetzt hängen die Seiten und man kann bis zu einer halben Minute lang den Tab weder neu laden noch schließen. Auch sind jetzt direkt alle Tabs der selben Domain betroffen.
Derzeit behelfe ich mich damit, die Tabs dann nach der Wartezeit zu schließen und mit Ctrl+Shift+T wieder zu öffnen.

Was das Ganze ein bisschen abmildert: Mit uBlock Origin tritt das Verhalten weit seltener auf. Ohne Adblocker passiert es ganz oft und ich habe gehört, dass mit AdBlock Plus nicht besser wird. Möglicherweise blockt uBlock die Ads schon zu einem früheren Zeitpunkt weg oder ABPs Werbe-Whitelist ist Schuld...
 
Okay, danke. Ich bin also nicht allein. Dachte schon, das liegt an dem Socks5/SSL Tunnel oder am Adblocker, auf beides möchte ich ungern verzichten auf dem mobilen Gerät.

Also doch wieder Firefox, was anderes gibt's ja kaum noch was flexible Konfiguration und gängige Extensions erlaubt.

Hab' mal mit den Firefox Profilen gespielt, da ich normalerweise die verschiedenen Browser auf unterschiedliche Weise konfiguriere und für unterschiedliche Zwecke verwende, das geht anscheinend ziemlich gut. Man kann Firefox in jedem Profil auf einen anderen Proxy setzen und auch mehrere Instanzen mit unterschiedlichen Profilen starten (firefox -P <Profilname>).
 
genau - ich habe generell die auswahl firefox -P da ich mehre Profile habe, z.B. Standart und Tor
 
Dieses "Aw... Snap" ist mir auch öfter aufgefallen. Leute nutzt doch den Seamonkey, dann habt Ihr noch einen tollen E-Mail-Client mit dabei.
 
Ich weiß zwar nicht ob sich eure Chromium Probleme damit auflösen, aber bei mir war es so, dass sich Chromium ebenfalls seit vielen Wochen schon vergnatzbadelt hatte. Und zwar dermaßen, dass der Browser völlig unbenutzbar war. Da ging im Prinzip gar nichts mehr. Außer Zombies hat der Chromium nichts mehr machen können.
Nun entdeckte ich heute diesen Eintrag:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202068

Das brachte mich auf die Idee, dass es irgendwas mit der Google Anmeldung zu tun haben könnte. Obwohl ich mich ja noch nie bei Google angemeldet hatte. Und Bingo!
Das war dann für mich die Lösung für das Chromium Problem. Seit dem läuft er wieder. Also ich habe mich natürlich nicht bei Google angemeldet, aber da gibt es ja beim Chromium nun dieses in den Rand integrierte Icon für das Google Konto. Da habe ich einmal draufgeklickt und mir mal angeschaut was es so bietet. Ich habe dann nur ein neues Icon (kein custom Icon, sondern eines aus der normalen Auswahl) für mein Chromium Profil ausgewählt:
http://i.stack.imgur.com/EKAdA.png
... und Zack, lief der Chromium auf einmal wieder wie ein geölter Blitz. Sonderlich stabil ist der Browser aber im Vergleich zum Firefox trotzdem nicht, allzu leicht können wohl irgendwelche Kampfscripte von Webseiten den Chromium, bzw. Tabs blockieren und zum Absturz bringen. Ich schätze die integrierte Blacklist im Firefox reißt es raus. Da dürften schon viele schwarze Schafe mit ausgefiltert werden.
 
Bei mir hat es damals geholfen, in den Einstellungen unter "System" die "Hardwarebeschleunigung" zu deaktivieren. Danach lief Chromium wieder stabiler. Ist aber schon eine Weile her. Einen Versuch ist es aber wert.
 
Fusselbär schrieb:
Nun entdeckte ich heute diesen Eintrag:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202068

Das brachte mich auf die Idee, dass es irgendwas mit der Google Anmeldung zu tun haben könnte. Obwohl ich mich ja noch nie bei Google angemeldet hatte. Und Bingo!
Das war dann für mich die Lösung für das Chromium Problem. Seit dem läuft er wieder. Also ich habe mich natürlich nicht bei Google angemeldet, aber da gibt es ja beim Chromium nun dieses in den Rand integrierte Icon für das Google Konto. Da habe ich einmal draufgeklickt und mir mal angeschaut was es so bietet. Ich habe dann nur ein neues Icon (kein custom Icon, sondern eines aus der normalen Auswahl) für mein Chromium Profil ausgewählt:
http://i.stack.imgur.com/EKAdA.png
... und Zack, lief der Chromium auf einmal wieder wie ein geölter Blitz.…
Zum Vergrößern anklicken....
Danke für den Tipp, aber zumindest bei mir hilft das nicht weiter:
2016-10-28 chromium.png
 
Ach, das knallgelb ist keine Absicht? Ist es etwa der Bug, den auch Greg Lehey hatte?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213351
Dazu gibt es dann im andern Thread noch eine Amerkung seinerseits im Kommentar Nummer 6, dass es wohl ein Artefakt sei, das durch eine übriggebliebene Datei verursacht wurde. Bei ihm half ein neuer User:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212060#c6
Merkwürdig, dass bei mir schon das auswählen eines neuen Avatar Icons ausgereicht hatte.
Btw.: ich starte übrigens meinen Chromium so:
Code: 
chrome --enable-http-pipelining --disk-cache-dir="/var/tmp/chromium" --enable-gpu-rasterization --ssl-version-min=tls1
Hier noch ein paar mehr Details im Spoiler, vielleicht enthält es ja irgend etwas, was dem einen oder andern weiter hilft.
Graphics Feature Status




    • Canvas: Hardware accelerated
    • Flash: Hardware accelerated
    • Flash Stage3D: Hardware accelerated
    • Flash Stage3D Baseline profile: Hardware accelerated
    • Compositing: Hardware accelerated
    • Multiple Raster Threads: Enabled
    • Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
    • Rasterization: Hardware accelerated
    • Video Decode: Hardware accelerated
    • Video Encode: Hardware accelerated
    • WebGL: Hardware accelerated
Driver Bug Workarounds




    • clear_uniforms_before_first_program_use
    • scalarize_vec_and_mat_constructor_args
Problems Detected




    • Clear uniforms before first program use on all platforms: 124764, 349137
      Applied Workarounds: clear_uniforms_before_first_program_use
    • Always rewrite vec/mat constructors to be consistent: 398694
      Applied Workarounds: scalarize_vec_and_mat_constructor_args
    • Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
      Disabled Features: native_gpu_memory_buffers
Version Information

Data exported28.10.2016, 16:21:52
Chrome versionChrome/52.0.2743.116
Operating systemFreeBSD 10.3-STABLE
Software rendering list version0
Driver bug list version8.78
ANGLE commit idunknown hash
2D graphics backendSkia
Command Line Args--enable-http-pipelining --disk-cache-dir=/var/tmp/chromium --enable-gpu-rasterization --ssl-version-min=tls1 --window-depth=24 --x11-visual-id=33 --wm-user-time-ms=42397809 --flag-switches-begin --no-pings --disable-touch-adjustment --disable-offer-upload-credit-cards --enable-devtools-experiments --enable-display-list-2d-canvas --enable-experimental-canvas-features --enable-experimental-web-platform-features --enable-fast-unload --enable-gpu-rasterization --javascript-harmony --enable-offline-auto-reload-visible-only --enable-quic --enable-tab-audio-muting --enable-tcp-fastopen --enable-unsafe-es3-apis --enable-webgl-draft-extensions --ignore-gpu-blacklist --enable-lcd-text --disable-overlay-scrollbar --reduced-referrer-granularity --touch-events=disabled --enable-features=brotli-encoding --flag-switches-end
Driver Information

Initialization time0
In-process GPUtrue
Sandboxedfalse
GPU0VENDOR = 0x0000, DEVICE= 0x0000
Optimusfalse
AMD switchablefalse
Driver vendor
Driver version
Driver date
Pixel shader version
Vertex shader version
Max. MSAA samples
Machine model name
Machine model version
GL_VENDOR
GL_RENDERER
GL_VERSION
GL_EXTENSIONS
Disabled Extensions
Window system binding vendor
Window system binding version
Window system binding extensions
Window managerKWin
XDG_CURRENT_DESKTOPKDE
Compositing managerYes
Direct renderingYes
Reset notification strategy0x0000
GPU process crash count0
Compositor Information

Tile Update ModeOne-copy
Partial RasterEnabled
GpuMemoryBuffers Status

ATCSoftware only
ATCIASoftware only
DXT1Software only
DXT5Software only
ETC1Software only
R_8Software only
BGR_565Software only
RGBA_4444Software only
RGBX_8888Software only
RGBA_8888Software only
BGRX_8888Software only
BGRA_8888Software only
YUV_420Software only
YUV_420_BIPLANARSoftware only
UYVY_422Software only
Edit: nicht wundern, das disk-cache-dir liegt bei mir in einem tmpfs.
 
Fun stuff

Hat .Xdefaults "Xft.dpi: 144" hab ich dasselbe Problem wie Kamikaze. Setze ich es auf 96, gefolgt von einem "xrdb -merge .Xdefaults" ist chromium zwar klein, aber imerhin nicht gelb :P


Fun stuff #2: will man dann "--force-device-scale-factor=2" verwenden, weil Augenlicht und so, hat man das ganze wieder in gross und gelb \o/


Moral der Geschicht: ändere Xft.dpi nicht.


mfg Tobias
 
Fusselbär schrieb:
Dazu gibt es dann im andern Thread noch eine Amerkung seinerseits im Kommentar Nummer 6, dass es wohl ein Artefakt sei, das durch eine übriggebliebene Datei verursacht wurde. Bei ihm half ein neuer User:
Zum Vergrößern anklicken....
Bei mir nicht.

Fusselbär schrieb:
Btw.: ich starte übrigens meinen Chromium so:
Code: 
chrome --enable-http-pipelining --disk-cache-dir="/var/tmp/chromium" --enable-gpu-rasterization --ssl-version-min=tls1
Zum Vergrößern anklicken....

Mit GPU Rasterisation bekomme ich auf größeren Seiten ein ganz matschiges Bild. Am besten ist das Bild wenn ich in den Preferences Hardware Accelleration ganz abschalte.

tcb schrieb:
Fun stuff

Hat .Xdefaults "Xft.dpi: 144" hab ich dasselbe Problem wie Kamikaze. Setze ich es auf 96, gefolgt von einem "xrdb -merge .Xdefaults" ist chromium zwar klein, aber imerhin nicht gelb :P
Zum Vergrößern anklicken....
Wenn ich ein xrandr --dpi 96 absetze verschwinden die Artefakte. Aber alles so winzig ist auch nicht wirklich benutzbar.
 
Bin nun wieder auf FF umgestiegen. Chr0me hatte mir zu oft die Snap-Fratze beim laden von Seiten presentiert. Bisher noch keine Probleme mit meinen surf-Gewohnheiten unter FF (pkg-Version).
 
Chromium ist ja nun in Version 54 in den Ports. Ich habe es nicht weiter verfolgt. Nutzt aktuell jemand die neue Version, und könnte zu den Problemen ein feedback geben, ob es sich nun wieder gebessert hat?
 
Ich warte noch auf das Binärpaket, aber laut des Portmaintainers soll es wesentlich besser laufen, er sagt, dass er nur noch einen Hänger pro Tag hat.
 
Ich verwende ihn seit gestern aus dem github repo. Ist besser, aber immer noch nicht gut (mehrmals eingefroren, und tabs, die sich nicht schliessen liessen).
 
Den neuen Chromium habe ich gleich fleißig gebaut, als er in den Ports gelandet ist. Das ist ja beim bauen ein Ungeheur, dieser Behemot, der Schrecken der Portssammlung wird aber auch immer gewaltiger, die Bauzeit länger und der Resourcenverbrauch geradezu schwindelerregend. Bis der fertig war, war ich müde und mir fielen fast die Augen zu. Habe den Chromium aber dann doch mal ganz kurz ausprobiert. Aber dann war ich endgültig zu müde. Habe dann noch in systat gesehen, dass nach dem beenden vom Chromium Browser noch zwei Verbindungen aufrechterhalten wurden, versuchte noch abzuwarten bis diese endlich abgebaut würden, aber dann hat die Müdigkeit gewonnen und das Bettchen gerufen. Rund 8 Stunden später schaute ich erfrischt nach und musste feststellen dass die zwei Verbindungen immer noch aufrechterhalten wurden. Es stellte sich dann mittels sockstat heraus, dass es sich um irgendwelche chrome Prozesse handelte. Fand ich suspekt. Habe dann mit killall chrome den chrome Prozessen den Garaus gemacht. killall musste mehrmals wiederholt werden bis wirklich alle chrome Prozesse beseitigt waren, obwohl doch killall eigentlich schon im ersten Lauf seinen Namen erfüllen sollte. Die Verbindungen waren dann weg. Aber mein Vertrauen in den Chromium ist dadurch nicht gerade gewachsen. Und Tabs abstürzen lassen kann die neue Chromium Version leider immer noch ganz gut, jedenfalls auf heise.de. Dagegen ist der Firefox solide wie ein Fels in der Brandung.

Trotzdem danke an die Chromium Porter! Das muss die Hölle gewesen sein, bei diesem Ungetüm:
https://svnweb.freebsd.org/ports?limit_changes=0&view=revision&revision=426855
 
Es soll angeblich helfen, wenn man das ~/.config/chromium bzw. ~/.config/chrome Verzeichnis mal löscht, dann könnte es stabiler laufen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben