firefox, nautilus, transmission crash when using gtk file dialog

Bug #288529 reported by Oliver Nevezi
70
This bug affects 3 people
Affects Status Importance Assigned to Milestone
firefox-3.0 (Ubuntu)
Invalid
Medium
Unassigned
gtk+2.0 (Ubuntu)
Invalid
Undecided
Unassigned
language-pack-ro (Ubuntu)
Fix Released
Undecided
Arne Goetje

Bug Description

Binary package hint: firefox-3.0

crashed when passing torrent link to transmission, I think is more a nautilus bug

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/lib/firefox-3.0.3/firefox
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0.3+nobinonly-0ubuntu2
ProcAttrCurrent: unconfined
ProcCmdline: /usr/lib/firefox-3.0.3/firefox
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=ro_RO.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: firefox-3.0
StacktraceTop:
 strlen () from /lib/libc.so.6
 vfprintf () from /lib/libc.so.6
 __vasprintf_chk () from /lib/libc.so.6
 g_vasprintf () from /usr/lib/libglib-2.0.so.0
 g_strdup_printf () from /usr/lib/libglib-2.0.so.0
Title: firefox crashed with SIGSEGV in strlen()
Uname: Linux 2.6.27-7-generic x86_64
UserGroups: adm admin cdrom dialout fuse lpadmin plugdev sambashare

Tags: apport-crash
Revision history for this message
Oliver Nevezi (oliver-nevezi) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Symbolic stack trace

StacktraceTop:strlen () from /lib/libc.so.6
vfprintf () from /lib/libc.so.6
__vasprintf_chk () from /lib/libc.so.6
IA__g_vasprintf (string=0x1, format=<value optimized out>,
IA__g_strdup_printf (format=0x1 <Address 0x1 out of bounds>)

Revision history for this message
Apport retracing service (apport) wrote : Symbolic threaded stack trace
Changed in firefox-3.0:
importance: Undecided → Medium
Revision history for this message
Alexander Sack (asac) wrote : Re: firefox, nautilus, transmission

the crash report looks ok. Most likely you cannot reproduce this reliably, can you?

Changed in firefox-3.0:
status: New → Confirmed
Revision history for this message
Oliver Nevezi (oliver-nevezi) wrote :

It happens all the time, at the point when you pass the link(torrent) to nautilus "open with" dialog in order to select Transmission.Again, is nautilus, I think, who crashes with Firefox together.
The same bug is present with the same nautilus "open" dialog when atempt to open a document with Gedit.
Also reliably crashes every time.

Revision history for this message
amagda (amagda) wrote :

Binary package hint: gnome-desktop-environment

Firefox, like any other application, (gedit, ooffice), crashes on "save as". Each time i try to "save as" from a gnome application the application crashes with a segmentation fault.

Switching between languages I have found out that this appears ONLY if i use Romanian environment ro_RO.UTF-8 (selected as you log in the system) and does not appear if i switch back to English ( LANG=en_EN.UTF-8) or German. Every time i change back to English all works perfectly.

Also if you open a terminal and set the LANG env to "export LANG=ro_RO" , and start Firefox or whatsoever application and do a save as, the application will not crash anymore. If you use "export LANG=ro_RO.UTF-8" all save as from a gnome application will crash on any save as command.

Best regards
Adrian

~ $ lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10

ProblemType: Crash
Architecture: amd64
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/lib/firefox-3.0.3/firefox
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0.3+nobinonly-0ubuntu2
ProcAttrCurrent: unconfined
ProcCmdline: /usr/lib/firefox-3.0.3/firefox
ProcEnviron:
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=ro_RO.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: firefox-3.0
StacktraceTop:
 strlen () from /lib/libc.so.6
 vfprintf () from /lib/libc.so.6
 __vasprintf_chk () from /lib/libc.so.6
 g_vasprintf () from /usr/lib/libglib-2.0.so.0
 g_strdup_printf () from /usr/lib/libglib-2.0.so.0
Title: firefox crashed with SIGSEGV in strlen()
Uname: Linux 2.6.27-7-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

The same crash with gimp :

Revision history for this message
Oliver Nevezi (oliver-nevezi) wrote :

After all it seems to be a locale (ro_RO.UTF-8) bug and is present only in amd64 architecture in both 8041 and 810, made 2 clean installs yesterday on same hardware with i386 and locale set to ro_RO.UTF-8 and all went well.
On the other hand on amd64 - ro_RO.UTF-8 a whole bunch of apps are crashing all the times when you select "save as", "open with", "preferences": Nautilus, Evolution, Gedit, Firefox, Transmission, OOffice.

Revision history for this message
Alexander Sack (asac) wrote :

adding gtk+2.0 as I also had a freeze/crash in a gtk file dialog now. maybe gvfs related?

Changed in gtk+2.0:
status: New → Confirmed
Revision history for this message
Alexander Sack (asac) wrote :

keeping firefox task open until we know whats going on here.

Revision history for this message
Dread Knight (dread.knight) wrote :

Tested my 64 bit Kubuntu Intrepid without using romanian language like Oliver Nevezi mentioned and everything seems perfect.

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 288529] Re: firefox, nautilus, transmission crash when using gtk file dialog

On Wed, Dec 10, 2008 at 01:22:09PM -0000, Dread Knight wrote:
> Tested my 64 bit Kubuntu Intrepid without using romanian language like
> Oliver Nevezi mentioned and everything seems perfect.
>

OK, if there are no issues left we can probably close the firefox task
as invalid.

 affects ubuntu/firefox-3.0
 status invalid

Thanks for the info!

 - Alexander

Revision history for this message
Oliver Nevezi (oliver-nevezi) wrote :

I'm 100% shure that this bug will never be resolved!
It's ,like I said, a locale (or maybe a gvfs, nautilus bug), everything(firefox, transmission, gedit, nautilus, etc, etc) is crashing all the times when reach the "open with", and so on dialog, on ro_RO.UTF-8 with the amd64 architecture....so @dread.knight do not waste our time "without using romanian language"!!!
What is the meaning of that?If this bug is only a ro_RO.UTF-8 thing then is not a bug??
Ohh and this s**t is not present on Debian amd64 and thats why I abandoned the piece of crap wich is Ubuntu.

Alexander Sack (asac)
Changed in firefox-3.0:
status: Confirmed → Invalid
amagda (amagda)
Changed in firefox-3.0:
status: Invalid → Confirmed
Revision history for this message
amagda (amagda) wrote :

Hi

I have made a search on launchpad regarding this problem:

There are several posts regarding the very same bug:

https://bugs.launchpad.net/ubuntu/+source/xdg-user-dirs-gtk/+bug/295244
https://bugs.launchpad.net/ubuntu/+source/language-pack-gnome-ro/+bug/249199
https://bugs.launchpad.net/ubuntu/+source/anjuta/+bug/25889
https://bugs.launchpad.net/ubuntu/+source/language-pack-ro/+bug/176939
https://bugs.launchpad.net/bugs/264806
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/293792

How can we unify all this bug reports ?

The bug seems to be quite old (2005) ..... It appears only in Ubuntu 64 bit, Romanian language.

Revision history for this message
Alexander Sack (asac) wrote :

please submit .crash files by double clicking on it in nautilus ... that will produce a good backtrace for us which might give us a hint whats going on here. if you do so, please post the new bug id here, so we properly follow up on your bug.

Revision history for this message
Sergiu Bivol (sergiu-bivol) wrote :

There is no point to add any backtrace or log to this bug report.

I have provided a fix long time ago here:
https://bugs.launchpad.net/ubuntu/+source/language-pack-ro/+bug/176939/comments/2

Simply click on the link and the mystery is solved :)

I have to make it clear that it's not a bug in the Gnome translation, as it was fixed there about 3 years ago. The problem is that Launchpad refuses to import the newer translations from upstream, using the old ones instead. This is also true (and _extremely_ annoying) for KDE.

Should I file a separate bug report regarding this behavior of Rosetta?

Revision history for this message
Arne Goetje (arnegoetje) wrote :

Thanks for the heads up. I fixed the translation string in Rosetta for Hardy, Intrepid and Jaunty. Updates will come with the next language-packs.

Revision history for this message
Arne Goetje (arnegoetje) wrote :

Regarding translation errors in the Romanian language packs: please contact the Romanian Translation Team to fix those, or even better, become a member of that team and fix it yourself. ;) For each translation which is also present in the upstream package, multiple choices are displayed in Rosetta and the team members can pick one of those to be used in the language packs.

Changed in language-pack-ro:
assignee: nobody → arnegoetje
status: New → Fix Committed
Revision history for this message
Sergiu Bivol (sergiu-bivol) wrote :

What happens when the upstream translations are not imported by Rosetta at all? (see libk3b, ktorrent, Amarok... in Jaunty for Romanian). I would suspect a bug in Rosetta rather than asking translators to re-translate every message that is already translated upstream. Is there a reason for ignoring those files?

Revision history for this message
Sergiu Bivol (sergiu-bivol) wrote :

This was a translation bug, not a GTK one.

Changed in gtk+2.0 (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Sergiu Bivol (sergiu-bivol) wrote :

This bug has nothing to do with Firefox. The translation bug has been fixed.

Changed in firefox-3.0 (Ubuntu):
status: Confirmed → Invalid
Changed in language-pack-ro (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.