• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Seamonkey crasht nach Firefox-Update [Gelöst]

Hi,

ich habe gerade über YaST das Paket MozillaFirefox (auf 3.0.11-0.1.1 zzgl. Abhängigkeiten) aktualisiert, ebenso dosbox und digikam durch kde4-digikam ersetzt.
Seitdem crasht Seamonkey (1.1.14-1.1, das neueste was verfügbar ist)beim Öffnen einer Mail oder Aufrufen einer Webseite.

Über die Konsole gibt er noch folgendes von sich:
Code:
 seamonkey
/usr/bin/seamonkey: line 277:  4067 Speicherzugriffsfehler  $AOSS $MOZ_PROGRAM $MOZ_LANG

Woran kann das liegen? Ist sehr ungünstig das Ganze, da ich Seamonkey für Mail und Internet dringend und laufend benötige.... :down:

Edit: Inzwischen hier entdeckt, dass das Problem auch anderswo auftritt. Umbenennen von ~/.qt hat nichts geholfen, auch nscd läuft.
Bugreport ist raus.
 

whois

Ultimate Guru
Hi

Diese Fehlermeldung gibt nichts her.
Sonst kommt da nichts?
Welche KDE/QT Version hast du da drauf jetzt?

cu
 

Rainer Juhser

Moderator
Teammitglied
margin-auto schrieb:
da ich Seamonkey für Mail und Internet dringend und laufend benötige....
Die Kombination Firefox + Thunderbird ist keine Alternative für dich? Zumal du den Fuchs ja wohl sowieso bereits installiert hast.
 
OP
M

margin-auto

Member
Ich nutze KDE 3.5, allerdings auch einzelne KDE4-Anwendungen, da die 3.5-Äquivalente nicht mehr zur Verfügung stehen bzw. nicht mehr gepflegt werden. So eben Digikam und Gwenview. kdebase3 ist in der Version 3.5.10-17.4 installiert.

QT ist in der Version 3-3.3.8b-87.11 installiert. Daneben steht noch ein Paket "qt4-x11-tools-4.4.3-4.8.1 - Qt 4 GUI related libraries" zur Verfügung. Ist das eine neuere Version QT 4? Kann/sollte ich die installieren?

Die Kombination aus Tb und Fx ist aus einer Vielzahl von Gründen keine Alternative für mich.
Ich sehe auch nicht ein, warum ich ein Programm durch ein anderes ersetzen soll, nur weil irgendwo unverträgliche Pakete auftauchen. (Sorry, falls das etwas angep***t klingt....).

Die Crashes treten auch nicht mit allen Seiten auf. Ich kann Google aufrufen, Wikipedia und http://fun.drno.de
Reproduzierbare Abstürze treten u.a. mit www.linux-club.de und www.drehscheibe-online.de auf. www.heise.de führt zu sporadischen Abstürzen.
Ich habe auch versucht Adblockplus zu deaktivieren und das Profilverzeichneis ~/.mozilla zu leeren. Beides ohne Erfolg.
 

whois

Ultimate Guru
margin-auto schrieb:
Die Crashes treten auch nicht mit allen Seiten auf. Ich kann Google aufrufen, Wikipedia und http://fun.drno.de
Reproduzierbare Abstürze treten u.a. mit http://www.linux-club.de und http://www.drehscheibe-online.de auf. http://www.heise.de führt zu sporadischen Abstürzen.
Ach, das hattest du verschwiegen da hätten wir lange Rätseln können.
Hast du mal alle Addons deaktiviert und dazu Java und Java Script.

Code:
java -version

Code:
xulrunner -version

Ergibt was?
 
OP
M

margin-auto

Member
Sorry, aber das hatte ich erst heute morgen entdeckt. Gestern Abend hatte ich wohl keine der Seiten erwischt, die nicht crashen.

Danke für den Hinweis. Mit ausgeschaltetem Javascript treten die Abstürze im Browser nicht mehr auf. Er stürzt jedoch weiterhin beim Öffnen einer Mail ab. JS ist aber komplett deaktiviert. Woran kann das liegen?
 

whois

Ultimate Guru
Stürzt er mit der gleichen Fehlermeldung ab?
Dann doch auch mal die Xulrunner Ausgabe liefern.

Auch bei reinen Textmails?
 
OP
M

margin-auto

Member
whois schrieb:
Stürzt er mit der gleichen Fehlermeldung ab?

Code:
~> seamonkey
/usr/bin/seamonkey: line 277:  5144 Speicherzugriffsfehler  $AOSS $MOZ_PROGRAM $MOZ_LANG

Das "$opt" am Ende fehlt, wenn JS ausgeschaltet ist. Die Zahl die hier 5144 ist variiert bei jedem Aufruf. Wohl die PID.

whois schrieb:
Auch bei reinen Textmails?

Ja. Ich habe noch keine Mail gefunden, bei der er nicht abstürzt.

whois schrieb:
Dann doch auch mal die Xulrunner Ausgabe liefern.

Wie komme ich da ran?
 
OP
M

margin-auto

Member
Code:
~> java -version
java version "1.6.0_0"
IcedTea6 1.4 (suse-24.4.3-i386) Runtime Environment (build 1.6.0_0-b14)
OpenJDK Client VM (build 14.0-b08, mixed mode)

Code:
~> xulrunner --version
Mozilla XULRunner 1.9.0.11 - 2009060200

Über YaST ist noch Xulrunner 1.9.0.10 bis -4 verfügbar. Würde ein Downgrade evt. helfen?

Die Paketverwaltung bräuchte eine History, damit man alle gemachten Änderungen ggf. rückgängig machen kann....
 

whois

Ultimate Guru
Das Problem ist das ich hier im Betrieb keine Suse 11.1 am laufen habe und daher nicht verifizieren kann ob das daran liegt.
Hier läuft noch eine alte Xulrunner Version unter Suse 11 und Debian mit allen Browser und Email Clients.

Code:
Mozilla XULRunner 1.9.0 - 2008061600

Also entweder wartest du bis heute Abend das ich dann eventuell mehr dazu sagen kann oder du musst darauf hoffen das es einer sieht der es so Problemfrei am laufen hat.
 
OP
M

margin-auto

Member
Ein Downgrade auf xulrunner 190-1.9.0.11-1.1.1 und damit verbunden von Fx auf 3.0.11-0.1.1 hat das Problem behoben. (Und bis jetzt noch keine anderen Schäden angerichtet ;) )

Vielen Dank für deine Hilfe.

Und die Moral von der Geschicht'? Nutze die Paketaktualisierung von YaST gar niemals nicht!
 

whois

Ultimate Guru
margin-auto schrieb:
Und die Moral von der Geschicht'? Nutze die Paketaktualisierung von YaST gar niemals nicht!
Das würde ich so nicht sagen aber xulrunner hakt im Moment fast überall.
Ich habe das auch schon auf verschiedenen ML gelesen.
 

dietger

Hacker
Und die Moral von der Geschicht'? Nutze die Paketaktualisierung von YaST gar niemals nicht!
Unsinn! Willst Du alles selber kompilieren? Viel Spaß dabei. :D
Das liegt eindeutig an einem "matschigen" Paket, nämlich xulrunner. Da kann die Paketaktualisierung nix für.
Kommt halt mal vor.

Dietger
 

whois

Ultimate Guru
dietger schrieb:
Das liegt eindeutig an einem "matschigen" Paket, nämlich xulrunner. Da kann die Paketaktualisierung nix für.
Richtig, kein Grund die bequeme Paketverwaltung zu dämonisieren.
Ausserdem dürfte das Paket auch bald wieder in Ordnung sein, wir sind halt alle nur Menschen die Fehler machen. ;)
 
OP
M

margin-auto

Member
Ich habe nichts gegen die Paketverwaltung von YaST. Seit 11.0 ist sie ja auch wieder vernünftig schnell. Ich habe nur in letzter Zeit vermehrt schlechte Erfahrungen damit gemacht, neue Versionen darüber einzuspielen. Irgendwas war danach meistens zerschossen. Das liegt aber i.d.T. nicht an YaST, sondern an den bereitgestellten Paketen.
Unter 9.x und auch noch 10.x habe ich regelmäßig wöchentlich ein "Alle Pakete aktualisieren wenn verfügbar" gemacht und hatte kaum Probleme damit. In den letzten 1-2 Jahren bin ich zunehmend davon abgekommen.
 
OP
M

margin-auto

Member
dietger schrieb:
Hmm, welche Repos hast Du denn bei Dir eingebunden ?

Openoffice, Mozilla, Packman, Update, Debug, Non-OSS, OSS, Source, die System-DVD und noch ein Repo für ein ... ahem ... Tool zum DVD-gucken. Wobei ich bei letzterem nicht weiss, ob das überhaupt noch nötig ist oder ob man es nicht auch woanders herbekommt.
 

whois

Ultimate Guru
Auch wenn das weit über die Deutung des Threads hinausgeht, das ist aber nicht zufällig Videlolan gemeinsam mit Packman?
 
OP
M

margin-auto

Member
whois schrieb:
das ist aber nicht zufällig Videlolan gemeinsam mit Packman?

Nein, das habe ich schon hinter mir. ;)
Die sporadischen Probleme liegen auch weniger an den Repos oder an YaST selbst, als daran, dass eben öfters mal nicht ausreichend getestete Pakete auftauchen. So wie in diesem Fall jetzt auch.
 
Oben