495392 - Crash when pasted selection contains data from java [@libc-2.10.1.so@0x729b8 ][@ nsClipboard::HasDataMatchingFlavors] [@ nsHTMLEditor::HavePrivateHTMLFlavor]

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Martin Stránský [:stransky] (ni? me)]

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ý [:stransky] (ni? me)]

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

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

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

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 380384 [details] [diff] [review]
patch

Can you check it please?

Comment 4

[Karl Tomlinson (:karlt)]

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ý [:stransky] (ni? me)]

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 (:karlt)]

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ý [:stransky] (ni? me)]

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 10

[freeseek]

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 (:karlt)]

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]

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]

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 (:karlt)]

I've made a Firefox build with some logging here:
https://build.mozilla.org/tryserver-builds/[e-mail]-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]

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 (:karlt)]

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 18

[Jan Horak [:jhorak]]

Attachment: Warning messages when pasting from jEdit

Attached warnings for bug 518331.

Comment 19

[Karl Tomlinson (:karlt)]

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ý [:stransky] (ni? me)]

Jan will be working on it...

Comment 21

[freeseek]

Attachment: Firefox output when pasting text that would make Thunderbird crash

Comment 22

[freeseek]

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]

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]

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]

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]

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]

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]

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]

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]

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

Comment 31

[freeseek]

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ý [:stransky] (ni? me)]

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

Comment 33

[Martin Stránský [:stransky] (ni? me)]

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 (:karlt)]

(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 (:karlt)]

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ý [:stransky] (ni? me)]

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

Comment 37

[Martin Stránský [:stransky] (ni? me)]

s/scrcmp/strcmp

Comment 38

[Karl Tomlinson (:karlt)]

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ý [:stransky] (ni? me)]

Attachment: 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 (:karlt)]

Comment on attachment 412175 [details] [diff] [review]
v2

Thanks for tidying up the existing NULL checks.

Comment 41

[Karl Tomlinson (:karlt)]

(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]

(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 (:karlt)]

(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]

Attachment: Patch for thunderbird on OpenSUSE 11.1

Comment 45

[martin.vogt]

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 47

[Martin Stránský [:stransky] (ni? me)]

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

Comment 48

[Dão Gottwald [:dao]]

You need to request approval for 1.9.2.

Comment 49

[Thomas Keller]

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]

Attachment: Stacktrace I get on startup of 3.0b4

Comment 51

[Mark Banner (:standard8)]

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ý [:stransky] (ni? me)]

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ý [:stransky] (ni? me)]

with gtk2-2.18.3-21.fc12.x86_64

Comment 54

[Martin Stránský [:stransky] (ni? me)]

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ý [:stransky] (ni? me)]

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)]

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)]

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 (:karlt)]

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]]

Not blocking, a192=beltzner

Comment 60

[Mark Banner (:standard8)]

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

Comment 61

[Mark Banner (:standard8)]

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]]

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

Comment 63

[Karl Tomlinson (:karlt)]

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

Comment 64

[Karl Tomlinson (:karlt)]

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 (:karlt)]

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 (:karlt)]

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

Comment 67

[Karl Tomlinson (:karlt)]

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

Comment 68

[Karl Tomlinson (:karlt)]

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

Comment 69

[walter]

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)]

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]

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

Comment 72

[Karl Tomlinson (:karlt)]

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]]

Comment on attachment 380384 [details] [diff] [review]
patch

Approved for 1.9.1.9, a=dveditz for release-drivers

Comment 74

[Mark Banner (:standard8)]

Checked into 1.9.1:

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