Last Comment Bug 495392 - Crash when pasted selection contains data from java [@libc-2.10.1.so@0x729b8 ][@ nsClipboard::HasDataMatchingFlavors] [@ nsHTMLEditor::HavePrivateHTMLFlavor]
: Crash when pasted selection contains data from java [@libc-2.10.1.so@0x729b8 ...
Status: RESOLVED FIXED
[tb30xwanted]
: crash
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86 Linux
: -- normal with 5 votes (vote)
: mozilla1.9.3a1
Assigned To: Martin Stránský
:
:
Mentors:
https://bugzilla.gnome.org/show_bug.c...
: 501080 511363 511876 518331 534146 (view as bug list)
Depends on:
Blocks: 518590
  Show dependency treegraph
 
Reported: 2009-05-28 23:59 PDT by Martin Stránský
Modified: 2011-06-13 10:01 PDT (History)
22 users (show)
mbeltzner: blocking1.9.2-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta5-fixed
.9-fixed


Attachments
patch (2.05 KB, patch)
2009-05-29 00:38 PDT, Martin Stránský
karlt: review+
roc: approval1.9.2+
dveditz: approval1.9.1.9+
Details | Diff | Splinter Review
Warning messages when pasting from jEdit (2.78 KB, text/plain)
2009-09-23 06:48 PDT, Jan Horak
no flags Details
Firefox output when pasting text that would make Thunderbird crash (2.78 KB, text/plain)
2009-09-24 14:27 PDT, freeseek
no flags Details
v2 (4.60 KB, patch)
2009-11-13 02:23 PST, Martin Stránský
karlt: review+
mbeltzner: approval1.9.2+
Details | Diff | Splinter Review
Patch for thunderbird on OpenSUSE 11.1 (1.17 KB, patch)
2009-11-19 05:00 PST, martin.vogt
no flags Details | Diff | Splinter Review
Stacktrace I get on startup of 3.0b4 (5.66 KB, text/plain)
2009-11-24 03:28 PST, Thomas Keller
no flags Details

Description Martin Stránský 2009-05-28 23:59:56 PDT
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.
Comment 1 Martin Stránský 2009-05-29 00:02:01 PDT
The check is missing everywhere (Trunk, 1.9.1 & 1.9.0).
Comment 2 Martin Stránský 2009-05-29 00:38:45 PDT
Created attachment 380384 [details] [diff] [review]
patch

Simple NULL check added to nsClipboard::HasDataMatchingFlavors() and nsDragService::IsTargetContextList(). It applies to Trunk.
Comment 3 Martin Stránský 2009-05-29 00:44:54 PDT
Comment on attachment 380384 [details] [diff] [review]
patch

Can you check it please?
Comment 4 Karl Tomlinson (back Dec 13 :karlt) 2009-05-29 02:33:30 PDT
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?
Comment 5 Martin Stránský 2009-05-29 02:37:29 PDT
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.
Comment 6 Karl Tomlinson (back Dec 13 :karlt) 2009-06-01 19:27:24 PDT
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.
Comment 7 Martin Stránský 2009-06-01 23:53:06 PDT
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...
Comment 8 Karl Tomlinson (back Dec 13 :karlt) 2009-08-03 14:23:31 PDT
*** Bug 501080 has been marked as a duplicate of this bug. ***
Comment 9 Mats Palmgren (:mats) 2009-08-25 17:43:18 PDT
*** Bug 511876 has been marked as a duplicate of this bug. ***
Comment 10 freeseek 2009-09-21 12:07:17 PDT
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.
Comment 11 Karl Tomlinson (back Dec 13 :karlt) 2009-09-21 13:48:48 PDT
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.)
Comment 12 freeseek 2009-09-21 17:12:08 PDT
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.
Comment 13 freeseek 2009-09-21 17:14:43 PDT
By the way, someone in this forum: http://bugs.archlinux.org/task/14076 mentioned as well that he is using KDE4 and not Gnome.
Comment 14 Karl Tomlinson (back Dec 13 :karlt) 2009-09-22 17:29:52 PDT
I've made a Firefox build with some logging here:
https://build.mozilla.org/tryserver-builds/ktomlinson@mozilla.com-try-7a1f4e63ea77/

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 [details].

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.
Comment 15 freeseek 2009-09-22 18:27:30 PDT
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
Comment 16 Karl Tomlinson (back Dec 13 :karlt) 2009-09-22 18:49:55 PDT
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 [details].
Comment 17 Jan Horak 2009-09-23 06:46:16 PDT
*** Bug 518331 has been marked as a duplicate of this bug. ***
Comment 18 Jan Horak 2009-09-23 06:48:11 PDT
Created attachment 402344 [details]
Warning messages when pasting from jEdit

Attached warnings for bug 518331.
Comment 19 Karl Tomlinson (back Dec 13 :karlt) 2009-09-23 17:43:03 PDT
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 [details] 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.
Comment 20 Martin Stránský 2009-09-24 06:23:23 PDT
Jan will be working on it...
Comment 21 freeseek 2009-09-24 14:27:55 PDT
Created attachment 402666 [details]
Firefox output when pasting text that would make Thunderbird crash
Comment 22 freeseek 2009-09-24 14:32:10 PDT
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.
Comment 23 freeseek 2009-09-25 13:47:53 PDT
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.
Comment 24 anli 2009-09-27 19:50:52 PDT
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?
Comment 25 anli 2009-09-27 21:07:55 PDT
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.
Comment 26 antoine.monmayrant+mozilla 2009-09-29 01:33:21 PDT
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
Comment 27 jocker 2009-10-15 05:25:41 PDT
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,
Comment 28 freeseek 2009-10-15 10:10:01 PDT
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.
Comment 29 anli 2009-10-15 10:17:14 PDT
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!
Comment 30 freeseek 2009-10-15 10:22:07 PDT
Well, I was not trying to infer that, just trying to give some hint to the time the regression was introduced.
Comment 31 freeseek 2009-10-15 10:30:00 PDT
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.
Comment 32 Martin Stránský 2009-11-06 02:59:04 PST
May be related to bug 311340 so taking this one...
Comment 33 Martin Stránský 2009-11-11 05:03:39 PST
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.
Comment 34 Karl Tomlinson (back Dec 13 :karlt) 2009-11-11 13:49:27 PST
(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.
Comment 35 Karl Tomlinson (back Dec 13 :karlt) 2009-11-11 14:01:51 PST
Comment on attachment 380384 [details] [diff] [review]
patch

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.)
Comment 36 Martin Stránský 2009-11-12 05:52:15 PST
I still believe we should check what gtk gives us and don't blindly throw it into scrcmp.
Comment 37 Martin Stránský 2009-11-12 05:52:40 PST
s/scrcmp/strcmp
Comment 38 Karl Tomlinson (back Dec 13 :karlt) 2009-11-12 13:02:01 PST
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.
Comment 39 Martin Stránský 2009-11-13 02:23:52 PST
Created attachment 412175 [details] [diff] [review]
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.
Comment 40 Karl Tomlinson (back Dec 13 :karlt) 2009-11-15 13:47:06 PST
Comment on attachment 412175 [details] [diff] [review]
v2

Thanks for tidying up the existing NULL checks.
Comment 41 Karl Tomlinson (back Dec 13 :karlt) 2009-11-15 13:49:55 PST
(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
Comment 42 jocker 2009-11-16 06:14:17 PST
(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 **** 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 **** software was patched does not mean that there are no more **** software out there (or older versions of the said software still in circulation)

...just my two cents

Thnx..
Comment 43 Karl Tomlinson (back Dec 13 :karlt) 2009-11-16 10:25:32 PST
(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.
Comment 44 martin.vogt 2009-11-19 05:00:22 PST
Created attachment 413314 [details] [diff] [review]
Patch for thunderbird on OpenSUSE 11.1
Comment 45 martin.vogt 2009-11-19 05:01:43 PST
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
Comment 46 Martin Stránský 2009-11-19 22:52:03 PST
*** Bug 511363 has been marked as a duplicate of this bug. ***
Comment 47 Martin Stránský 2009-11-20 06:34:36 PST
Can we make a progress here? It hits Fedora users regulary....
Comment 48 Dão Gottwald [:dao] 2009-11-20 07:56:05 PST
You need to request approval for 1.9.2.
Comment 49 Thomas Keller 2009-11-24 03:26:46 PST
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).
Comment 50 Thomas Keller 2009-11-24 03:28:38 PST
Created attachment 414227 [details]
Stacktrace I get on startup of 3.0b4
Comment 51 Mark Banner (:standard8, limited time in Dec) 2009-11-24 06:27:11 PST
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.
Comment 52 Martin Stránský 2009-11-24 06:53:51 PST
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.
Comment 53 Martin Stránský 2009-11-24 06:56:41 PST
with gtk2-2.18.3-21.fc12.x86_64
Comment 54 Martin Stránský 2009-11-24 07:02:13 PST
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.
Comment 55 Martin Stránský 2009-11-24 07:15:02 PST
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).
Comment 56 Mark Banner (:standard8, limited time in Dec) 2009-11-24 07:41:20 PST
Comment on attachment 412175 [details] [diff] [review]
v2

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).
Comment 57 Joe Drew (not getting mail) 2009-11-24 10:52:20 PST
It hurts me, but I don't think we should block on this. I do think this patch should be approved, though.
Comment 58 Karl Tomlinson (back Dec 13 :karlt) 2009-11-24 12:49:08 PST
Yes, I don't think we should block on workarounds for every new bug introduced in GTK.  However, the patch is safe to take.
Comment 59 Mike Beltzner [:beltzner, not reading bugmail] 2009-11-24 13:09:20 PST
Not blocking, a192=beltzner
Comment 60 Mark Banner (:standard8, limited time in Dec) 2009-11-24 14:15:20 PST
Checked into mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/c9c35333436b
Comment 61 Mark Banner (:standard8, limited time in Dec) 2009-11-24 14:33:15 PST
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
Comment 62 Wolfgang Rosenauer [:wolfiR] 2009-11-24 22:03:12 PST
argl, g_strcmp0() needs glib 2.16. That seems to be too recent.
Comment 63 Karl Tomlinson (back Dec 13 :karlt) 2009-11-25 01:20:16 PST
Yes, sorry.  That was my suggestion.  I thought I checked but obviously I did something wrong.
Comment 64 Karl Tomlinson (back Dec 13 :karlt) 2009-11-25 01:25:12 PST
Comment on attachment 380384 [details] [diff] [review]
patch

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.
Comment 65 Karl Tomlinson (back Dec 13 :karlt) 2009-11-25 12:13:38 PST
Comment on attachment 380384 [details] [diff] [review]
patch

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.
Comment 66 Karl Tomlinson (back Dec 13 :karlt) 2009-11-26 20:30:15 PST
http://hg.mozilla.org/mozilla-central/rev/a293d150ebbd
Comment 67 Karl Tomlinson (back Dec 13 :karlt) 2009-11-29 15:03:03 PST
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/b8b04ef445a1
Comment 68 Karl Tomlinson (back Dec 13 :karlt) 2009-11-29 15:04:04 PST
Also fixed in GTK+:
http://git.gnome.org/cgit/gtk+/commit/?id=6dfb21e616bdf1e1db7ed86bff08fcb68210f17e
Comment 69 walter 2010-01-30 03:46:44 PST
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
Comment 70 Mark Banner (:standard8, limited time in Dec) 2010-02-03 07:46:30 PST
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?
Comment 71 freeseek 2010-02-03 07:50:14 PST
Can't agree better. I stopped using Thunderbird. This bug remained opened for too long.
Comment 72 Karl Tomlinson (back Dec 13 :karlt) 2010-02-03 10:04:08 PST
Comment on attachment 380384 [details] [diff] [review]
patch

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.
Comment 73 Daniel Veditz [:dveditz] 2010-02-19 14:08:58 PST
Comment on attachment 380384 [details] [diff] [review]
patch

Approved for 1.9.1.9, a=dveditz for release-drivers
Comment 74 Mark Banner (:standard8, limited time in Dec) 2010-03-03 13:06:57 PST
Checked into 1.9.1:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/62f3d28797e2
Comment 75 Wayne Mery (:wsmwk, NI for questions) 2010-10-23 06:27:34 PDT
*** Bug 534146 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.