click on bookmark crashes firefox with java content in clipboard

Downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=501685

There's a crash at nsClipboard::HasDataMatchingFlavors()

Bactrace:

Thread 1 (Thread 20486):
#0 0x00000033b140ed5b in raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
#1 0x0000003f72873244 in nsProfileLock::FatalSignalHandler (signo=11) at
nsProfileLock.cpp:212
#2 <signal handler called>
#3 strcmp () at ../sysdeps/x86_64/strcmp.S:29
#4 0x0000003f7306c82d in nsClipboard::HasDataMatchingFlavors (this=<value
optimized out>,
    aFlavorList=<value optimized out>, aLength=1, aWhichClipboard=<value
optimized out>, _retval=0x7fff29c80a1c)
    at nsClipboard.cpp:448
#5 0x0000003f72e3d243 in nsHTMLEditor::HavePrivateHTMLFlavor (this=<value
optimized out>, aClipboard=0x0)
    at nsHTMLDataTransfer.cpp:1844
#6 0x0000003f72e3f5ff in nsHTMLEditor::Paste (this=0x7f430705f800,
aSelectionType=0) at nsHTMLDataTransfer.cpp:1869
#7 0x0000003f72d23ee6 in nsTextEditorMouseListener::MouseClick
(this=0x7f430704fd80, aMouseEvent=<value optimized out>)
    at nsEditorEventListeners.cpp:362
#8 0x0000003f72e7fb45 in nsHTMLEditorMouseListener::MouseClick
(this=0x7f430704fd80, aMouseEvent=0x7f43071b9640)
    at nsHTMLEditorMouseListener.cpp:307
[...]

It's here at sClipboard.cpp:448

  for (PRInt32 j = 0; j < n_targets; j++) {
     gchar *atom_name = gdk_atom_name(targets[j]);
>> if (!strcmp(atom_name, aFlavorList[i]))
        *_retval = PR_TRUE;

Looks like gdk_atom_name(targets[j]) returns NULL and we don't catch it.

The check is missing everywhere (Trunk, 1.9.1 & 1.9.0).

Created an attachment (id=380384)
patch

Simple NULL check added to nsClipboard::HasDataMatchingFlavors() and nsDragService::IsTargetContextList(). It applies to Trunk.

(From update of attachment 380384)
Can you check it please?

Thanks, Martin.

I don't understand why we should ever have (in gdk_atom_name)
GPOINTER_TO_UINT(targets[j]) >= virtual_atom_array->len

Would you have a testcase that you could make available to me, please?

I tried hard to reproduce it with instructions from original bugreport but w/o success. So at least I tested that gdk_atom_name() can really return the NULL value although official GTK documentation doesn't claims it.

gdk_atom_name() can return NULL, but only if it is given a bad GdkAtom parameter.

The problem appears to be that the GdkAtom is bad. I'd prefer to wait for more data to work out why the GdkAtom is bad, rather than patch some of the symptoms.

I think the pointer check is always good thing. There have been many bugs/crashes in mozilla codebase where somebody doesn't check the pointer value...

*** Bug 501080 has been marked as a duplicate of this bug. ***

*** Bug 511876 has been marked as a duplicate of this bug. ***

Please, add the pointer check, for the sake of saving time to hundreds of people around there. I do not understand why this bug is not considered a top priority for the team. I have starting experiencing this but with Thunderbird 2, around six months ago. I was startled. The crashes happened on four different machines I owned, so it must be overly spread. I upgraded to Thunderbird 3 hoping the problem to be solved, but it was not (I use version 3.0~b4~hg20090908r3585+nobinonly-0ubuntu1~umd1~jaunty). I have lost a lot of time having to rewrite my emails because of these crashes and now I have developed the practice to first copy the whole text of the email to the clipboard before pasting anything into it. The crash happens both on 32 bits machines and 64 bits machines. Also, it happens with all the machines I have, running either Ubuntu Intrepid or Jaunty. I have been wondering how the developers cope with that. Maybe the fact that I use KDE has something to do with it? Please do not let this bug open.

giulio, are there some particular apps from which copying causes the crash?
Any core KDE apps? Which versions?
(So far there only seem to have been reports from java apps.)

Actually, my experience has been that the problem is extensive. Sometimes I copy text from kile and it crashes, sometimes from firefox, sometimes from chrome-browser and sometimes it crashes even when I paste text copied from Thunderbird itself. It does not crash if I paste the text in the subject field. The problem is not reproducible though. But when it crashes I know that I can reproduce it with what I have in the clipboard, as long as I do not change it. But I have not noticed any pattern. Actually, if I paste what I have in the clipboard and I copy it again, it usually does not crash. Sometimes it is even enough to open Klipper (the KDE clipboard manager), reselect what is already selected, and paste again, and it works fine. Please, let me know if you want me to debug it. I have no experience with debugging but I am willing to dedicate time to this.

By the way, someone in this forum: http://bugs.archlinux.org/task/14076 mentioned as well that he is using KDE4 and not Gnome.

I've made a Firefox build with some logging here:
https://<email address hidden>/

If you have something in the clipboard that causes a crash (in Thunderbird or
other Mozilla apps), then run this build and try pasting into a
contenteditable element such as in attachment 345137.

The build is based on trunk (a few days ago), so I suggest either back up your
profile or "mkdir ~/tmp/new-profile" and run with "-profile ~/tmp/new-profile
-no-remote".

It shouldn't crash but will log some info like this:

** (firefox-bin:17547): WARNING **: atom_name is NULL for targets[0] == 0x78
** (firefox-bin:17547): WARNING **: xatom is 606 for GdkAtom 0x78
** (firefox-bin:17547): WARNING **: xatom 606 name is text/plain;charset=UTF-8

Hopefully the logs might provide some clues as to what is happening.

I am sorry, but the problem has nothing to do with firefox, but with Thunderbird, maybe this is the wrong place where to report it. I have never had firefox crashing, only Thunderbird. I was redirected to this bug from this one:
https://bugzilla.redhat.com/show_bug.cgi?id=509582

Firefox will use the same code as in the Thunderbird stack trace at https://bugzilla.redhat.com/show_bug.cgi?id=509582 if you paste into attachment 345137.

*** Bug 518331 has been marked as a duplicate of this bug. ***

Created an attachment (id=402344)
Warning messages when pasting from jEdit

Attached warnings for bug 518331.

Thank you, Jan.

The way gdk_selection_property_get() is meant to work for atom property types
is that it fills |data| with GdkAtoms. These GdkAtoms come from
gdk_x11_xatom_to_atom_for_display(), which should return either a valid
GdkAtom, or on failure GDK_NONE (which is also a valid GdkAtom).

gtk_selection_data_get_targets() should only return true if the selection data
contains GdkAtoms.

The "`ATOM_TO_INDEX (atom) < virtual_atom_array->len' failed" assertion in
attachment 402344 indicates that the GdkAtoms are not valid, so something has
gone wrong in this process before the gdk_atom_name() call.

I haven't been able to reproduce here, so I'd appreciate it if someone can work out why these GdkAtoms are not valid. I would start with a break point in gdk_selection_property_get() and checking that the elements of atoms_dest are all less than virtual_atom_array->len.

Jan will be working on it...

Created an attachment (id=402666)
Firefox output when pasting text that would make Thunderbird crash

I finally managed to crash Thunderbird again, then I went in firefox and I pasted the same data that would make Thunderbird crash. I hope this helps.

I got more evidence that the bug has definitely to do with something broader than Thunderbird (although Thunderbird is the only one that crashes). I have noticed, in the past 8 months or so, that sometimes I would try to copy something in matlab by selecting it and copy it somewhere else with the middle button of the mouse and nothing would happen. Then I would just go and copy it again, so that I developed the habit of copying the text pressing Ctrl+C multiple times. Last time it happened, I thought it might be related and I tried to paste the clipboard into Thunderbird. It crashed! I bet whatever the bug is, it is related.

Confirming the issue, up to date Kubuntu Karmic testing is in use:

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20090924 Ubuntu/9.10 (karmic) Firefox/3.5.3

My "main" way to reporduce the crash is to copy to clipboard something from Netbeans and click on any bookmark.

Is it possible to public a workaround without closing the bug?

Addition. To be sure the problem doesn't depend on, say, installed plugins, I have tried:

- created new profile
- tried to reproduce the issue - no crash,
- imported previously saved (JSON) bookmarks - crash

Resuming, the problem doesn't depend on plugins, but does depend on concrete bookmark tree.

I think I experience the same bug in Thunderbird 3.0b3 under Fedora 11 64 bits
(Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814)
(Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3)
It occurs almost all the time even in safe-mode using a brand new profile.

Here are some observations I made:
- Crash occurs when pasting in the body of the message, not when pasting in the "To" or "Cc" fields.
- Crash can be avoided by using the kde clipboard klipper: Crtl-C in a given app (firefox or jabref) then Ctrl-V in Thunderbird leads to a seg fautl (idem using select/middle click) but Ctrl-C in a given app, then selecting an entry in the paste history of klipper then Ctr-V works (same for select/middle click).

Hope it helps,

Antoine

is there anyone actively working on this bug?

Is there any known workaround or non-affected version we could use until the bug is fixed?

Currently using Thunderbird 2.0.22 under jaunty...

Can actively reproduce it while pasting data from squirrelSQL (and other java-based apps) in case you need more debug output or something.

Thunderbird also crashes on random(?) intervals while minimized, if I have "bad" data copied into the clipboard (even without pasting it on thunderbird)

Thanks in advance,

Do you use KDE as well? I started experiencing this around the beginning of year (2009), I think when I started using KDE 4.2, and it never went away since then. I still don't know what is causing the problem but I cannot believe that such a bad regression made it through for so long. I have to be honest, this single problem is making me switch from Thunderbird to the web based Gmail interface.

The problem does NOT depend on desktop enviroment or window manager!! I have tried fluxbox the same way: start Firefox, start some java application, copy something to clipboard from last one, click on bookmarks - crash!

Well, I was not trying to infer that, just trying to give some hint to the time the regression was introduced.

Wow, you are right though, if I copy something from matlab (with Ctrl+C, not just by highlighting with the mouse), which is java based, go to firefox, open the Bookmarks menu and click with the right button of the mouse on a bookmark, it crashes! But I never managed to crash Firefox before, probably because I don't use the bookmarks.

May be related to bug 311340 so taking this one...

Well, after some investigation I believe the NULL check is a proper solution here.

For instance, see the clipboard tutorial at http://www.gtk.org/tutorial1.2/gtk_tut-19.html

Anyway, selection_data and its description by atoms is created by application which pastes data into clipboard. Mozilla has not any mechanism how to deny third-party app to paste incorrect targets into clipboard. We can only ignore them.

(In reply to comment #33)
> Anyway, selection_data and its description by atoms is created by application
> which pastes data into clipboard. Mozilla has not any mechanism how to deny
> third-party app to paste incorrect targets into clipboard. We can only ignore
> them.

Yes, another app may put anything into the X Selection.

But gtk_selection_data_get_targets() should return GdkAtoms.
GdkAtom is a type specific to GDK and has no meaning for other apps.
GdkAtoms should not come (directly) from another app, so I filed

https://bugzilla.gnome.org/show_bug.cgi?id=601611

The comment "As usual, java gets it wrong and sets the type to TARGETS, not ATOM" in gtk_selection_data_get_targets() was helpful.

(From update of attachment 380384)
The correct workaround for applications would be to check whether
gtk_selection_data_get_data_type(selection_data) == gdk_atom_intern("TARGETS", FALSE)
before calling gtk_selection_data_get_targets(), and, if so and gtk_selection_data_get_format(selection_data) == 32, assume XA_ATOM type and use gdk_x11_xatom_to_atom() to do the conversion to GdkAtom.

(But the GTK bug should still be fixed.)

I still believe we should check what gtk gives us and don't blindly throw it into scrcmp.

s/scrcmp/strcmp

I'd be happy with using g_strcmp0 when the data is a gchar* from GDK.
That way our code doesn't need the extra checks.

Created an attachment (id=412175)
v2

Okay, here is a patch with g_string0. I also removed inconsistency in Drag&Drop when somewhere is the NULL check performed and somewhere is missing. All code with gdk_atom_name() call g_string0() now.

(From update of attachment 412175)
Thanks for tidying up the existing NULL checks.

(In reply to comment #35)
> The correct workaround for applications would be to check whether
> gtk_selection_data_get_data_type(selection_data) == gdk_atom_intern("TARGETS",
> FALSE)
> before calling gtk_selection_data_get_targets(), and, if so and
> gtk_selection_data_get_format(selection_data) == 32, assume XA_ATOM type and
> use gdk_x11_xatom_to_atom() to do the conversion to GdkAtom.

The java bug has been fixed, so not much point in doing this.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6607163

(In reply to comment #41)
> (In reply to comment #35)
> > The correct workaround for applications would be to check whether
> > gtk_selection_data_get_data_type(selection_data) == gdk_atom_intern("TARGETS",
> > FALSE)
> > before calling gtk_selection_data_get_targets(), and, if so and
> > gtk_selection_data_get_format(selection_data) == 32, assume XA_ATOM type and
> > use gdk_x11_xatom_to_atom() to do the conversion to GdkAtom.
>
> The java bug has been fixed, so not much point in doing this.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6607163

I tend to disagree on that.
I believe that any decently-written piece of software should safeguard from crap input, by checking whenever possible. The input after all could be there by mistake, or intentionally ( i.e. malicious code)

The fact that one piece of crappy software was patched does not mean that there are no more crappy software out there (or older versions of the said software still in circulation)

...just my two cents

Thnx..

(In reply to comment #42)
> I believe that any decently-written piece of software should safeguard from
> crap input, by checking whenever possible.

Martin's patch protects from crashes.

I don't think it is worth adding code to interpret an old Java's special format.

Created an attachment (id=413314)
Patch for thunderbird on OpenSUSE 11.1

Hello,

thanks martin for the patch. This fixed the "right mouse click" crash
on the Bookmark Buttons for me. For thunderbird this does not help on my opensuse
system. I will attach my patch, but I'm nor sure if this is the right place.

regards,

Martin

*** Bug 511363 has been marked as a duplicate of this bug. ***

Can we make a progress here? It hits Fedora users regulary....

You need to request approval for 1.9.2.

I'm on TB 3.0b4 (openSUSE 11.2) and this crash hits me as well, however I do not need to trigger it manually - I just see TB crashing "in the background". When I try to restart it with '--debug gdb', I get the attched stacktrace directly on startup (calendar view is active).

Created an attachment (id=414227)
Stacktrace I get on startup of 3.0b4

Martin: we'd like to get this into the branches for Thunderbird to pick up.

Is there any easy way to produce a crashtest for this? (from the comments, I'm guessing not).

As mozilla-central is restricted to approval-1.9.2+ or blocking-1.9.2+ only at the moment, could you request approval-1.9.2 for this and put a risk assessment on?

I'd like to end up getting this into the 1.9.2 and 1.9.1 branches so that Thunderbird can pick this up, as I'm told it is a frequent crash for us on Linux.

Reproduction steps:

1) install jEdit (from http://www.jedit.org/)
2) launch thunderbird/firefox, open any page you can paste in or create a new message
3) write some text in jEdit and copy-paste it to mozilla (by ctrl+c, ctrl+v).

I can reliably reproduce it on Fedora 12/i686.

with gtk2-2.18.3-21.fc12.x86_64

The crash is reproducible on x86_64 too, with:

$java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6) (fedora-33.b16.fc12-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

There's one trick there - don't use proprietary java VM from sun, it seems to crash with the OpenJDK only.

As for the risk assessment, it's generally strcmp -> g_strcmp0 change at a few places. It can't regress unless there's a typo in the patch (or regression inside glib itself).

(From update of attachment 412175)
See comments 52-55 for clear STR and risk assessments (I'm told we're seeing this a lot in Thunderbird on Linux as well).

It hurts me, but I don't think we should block on this. I do think this patch should be approved, though.

Yes, I don't think we should block on workarounds for every new bug introduced in GTK. However, the patch is safe to take.

Not blocking, a192=beltzner

Checked into mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/c9c35333436b

I had to back this out due to Linux build bustages across all trees:

http://hg.mozilla.org/mozilla-central/rev/6432560e430e

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1259100980.1259101752.9386.gz

/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsClipboard.cpp: In member function ‘virtual nsresult nsClipboard::HasDataMatchingFlavors(const char**, PRUint32, PRInt32, PRBool*)’:
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsClipboard.cpp:434: error: ‘g_strcmp0’ was not declared in this scope
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsClipboard.cpp:438: error: ‘g_strcmp0’ was not declared in this scope
NEXT ERROR make[6]: *** [nsClipboard.o] Error 1
make[6]: *** Waiting for unfinished jobs....
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsDragService.cpp: In member function ‘virtual nsresult nsDragService::IsDataFlavorSupported(const char*, PRBool*)’:
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsDragService.cpp:834: error: ‘g_strcmp0’ was not declared in this scope
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsDragService.cpp:840: error: ‘g_strcmp0’ was not declared in this scope
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsDragService.cpp:849: error: ‘g_strcmp0’ was not declared in this scope
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsDragService.cpp:858: error: ‘g_strcmp0’ was not declared in this scope
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsDragService.cpp: In member function ‘PRBool nsDragService::IsTargetContextList()’:
/builds/slave/mozilla-central-linux/build/widget/src/gtk2/nsDragService.cpp:981: error: ‘g_strcmp0’ was not declared in this scope
make[6]: *** [nsDragService.o] Error 1

argl, g_strcmp0() needs glib 2.16. That seems to be too recent.

Yes, sorry. That was my suggestion. I thought I checked but obviously I did something wrong.

(From update of attachment 380384)
Let's go back to this, then.

The check in nsDragService isn't really necessary because GdkDragContext is not subject to the same bug, but I guess it's consistent to do the same check everywhere.

(From update of attachment 380384)
Requesting approval 1.9.2 for these null checks that fix the most-reported Thunderbird crash on Linux. The patch only affect code paths in situations for which we'd crash atm.

Writing a unit test to test the crash would be a significant amount of work and would only be of any use when run with the broken versions of GTK, which we don't have on our test platforms.

This patch is a workaround for a bug in a workaround in GTK for a Java bug.
I've suggested that the incorrect workaround in GTK be removed, but there hasn't been any progress on that.

http://hg.mozilla.org/mozilla-central/rev/a293d150ebbd

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/b8b04ef445a1

Also fixed in GTK+:
http://git.gnome.org/cgit/gtk+/commit/?id=6dfb21e616bdf1e1db7ed86bff08fcb68210f17e

Just for completeness: i had the samebug with thunderbird running inside a NXcleint. No need for JAVA , just clip & bang.
thunderbird 2.0.23 on Opensuse11.1

backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff169d854 in strcmp () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff169d854 in strcmp () from /lib64/libc.so.6
#1 0x0000000000622b1b in nsClipboard::HasDataMatchingFlavors (this=<value optimized out>, aFlavorList=0x1000, aWhichClipboard=<value optimized out>, _retval=0x7fffffffc29c) at nsClipboard.cpp:396
#2 0x0000000000a40008 in nsHTMLEditor::HavePrivateHTMLFlavor (this=<value optimized out>, aClipboard=0x4415880) at nsHTMLDataTransfer.cpp:1846
#3 0x0000000000a400c7 in nsHTMLEditor::Paste (this=0x3a8a7d0, aSelectionType=0) at nsHTMLDataTransfer.cpp:1865

Karl: would you be prepared to back port this to 1.9.1? We did see a few crashes with this stack for 3.0, though nothing yet for 3.0.1. It may be that the affected users have switched to something else or mainly use distro builds. I'm just wondering what your thoughts are?

Can't agree better. I stopped using Thunderbird. This bug remained opened for too long.

(From update of attachment 380384)
Actively maintained distros using the GTK+-2.18 branch would have picked up the fix there. But distros on the GTK+-2.16 branch are unlikely to have backported the patch (Ubuntu 9.04 and Fedora 11 haven't), so applying the workaround to 1.9.1 would help people.

The patch only adds null checks in places where null values would cause a crash.

(From update of attachment 380384)
Approved for 1.9.1.9, a=dveditz for release-drivers

Checked into 1.9.1:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/62f3d28797e2

*** Bug 534146 has been marked as a duplicate of this bug. ***