Closed Bug 46643 Opened 24 years ago Closed 21 years ago

crash when marking text in another application with an existing selection in mozilla

Categories

(Core :: DOM: Selection, defect, P3)

Product:
Core
Component:
DOM: Selection
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: pat, Assigned: kinmoz)

References

Details

(Keywords: crash, helpwanted)

Attachments

(1 file)

Suggested patch to return if any of the args are null
724 bytes, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.13 i686; en-US; m17) Gecko/20000725
BuildID:    2000072521

crash if I mark text in another X application like xemacs, netscape, kedit (all
verified) after I have previously marked text in mozilla

Reproducible: Always
Steps to Reproduce:
1. select text in a browser window
2. switch to another application
3. select text in that application

Actual Results:  mozilla crashes

Expected Results:  mozilla shouldn´t be affected

This is what got printed on the shell (I didn´t get a core dump):
I mark this critical, because it happened when I tried to select the shell
output the first time so I had to go back and enter everything again )-:

./run-mozilla.sh ./mozilla-bin
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.
     LIBRARY_PATH=.
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
WEBSHELL+ = 1
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/pat/.mozilla/default/chrome/user.css' failed.  Error code: 16389
WEBSHELL+ = 2

-->loadDS(): ds=[xpconnect wrapped nsIRDFDataSource], loaded=true, returning! <--
WEBSHELL+ = 3
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
WEBSHELL+ = 4
Document: Done (2.304 secs)
*** check number of frames in content area
Error getting url widget service: TypeError: Components.classes[progid] has no
properties
Document http://www.mozilla.org/ loaded successfully
### Here I selected Text in Mozilla
->>>>>>>>>>>>>> Write Clipboard to memory
### Here I switched to xemacs and selected some text ###
./run-mozilla.sh: line 29:   846 Segmentation fault      $prog ${1+"$@"}
assigning to Kin, setting to m18 and adding to nsbeta3+
Assignee: mjudge → kin
Keywords: crash, nsbeta3
Whiteboard: nsbeta3+
Target Milestone: --- → M18
I can't reproduce this on Linux with Builds 2000072608 (M17), nor 2000072621
(M18).  I select text in Mozilla, then I select test in Netscape,
gnome-terminal, NEdit, XEmacs.  No crash.  I tried selecting normal text,
<input> text, and <textarea> text.  BTW I use XFree86 4.0.1 and GTK+ 1.2.8, if
it matters.

This has already garnered nsbeta3+, but nobody has confirmed it.
actually it has been conformed that we have issues on windows (Kin -- Anthony is 
working on that bug). Kin, you may want to reassign this one to ANthony since he 
is already looking at this stuff
I don't think it's the same thing anthonyd is looking at (MicroMagic).

Accepting bug. Adding akkana@netscape.com to Cc list since this sounds like it's
related to the grabbing of XSelection. Akkana, can you repro this?
I can't reproduce it either.  Patrick, what version of Linux are you running,
and what version of X and gtk do you have?  (Most of us are running Redhat
variants of one sort or another; I'm RH 6.2, XFree86-3.3.6, gtk+-1.2.6.)
My base system is Suse 6.1 (XFree86 3.3.3.1, gtk+ 1.2.1 - never touched those),
however I have updated some packages (e.g. Kernel, it is 2.2.13 now). Maybe it´s
a window manager thing, I use KDE (1.1) rather than gnome. Hope this helps
I can't reproduce this either on my RedHat 6.1 system. (XFree86-3.3.5-3,
gtk+-1.2.5-2)
I updated GTK+ to 1.2.7, but I still see this bug with recent builds (just tried
on 2000073104 M17). Have a look at bug #47045, it sounds a lot like this one
(look at the shell output, there is clipboard activity), which means someone
besides me has this problem...
Long shot: Run "ps aux | grep klipper" right after this happens.  Are you
running klipper?  kde's klipper app can cause strange problems with mozilla; kde
is aware of the problem now and has a fix which will go out with the next
release.  If you are running klipper, try killing it and see if this bug goes
away.
Nope, there is no klipper running, neither before nor after the crash. I also
tried this using fvwm2 as window manager, and it still crashes. Looks like it´s
not a KDE issue.
removing nsbeta3+ until we can reproduce, moving out to m19
Keywords: nsbeta3
Whiteboard: nsbeta3+
Target Milestone: M18 → M19
WFM on 2000080308 (M18), using KDE and even having klipper running. What
application is giving you the crash?
I can still reproduce this with recent builds. I have generated talkback traces
for build 2000080712 M17 (talkback id is TB15445253W) and build 2000080714 M18
(talkback id is TB15445535W). 
just asked another person to test this (jag) and he could not reproduce this 
either.

reporter: is there anyway you can test this on another system? we had another 
bug fix that resolved clipboard issues, that may have solved the problem
I've had exactly the same problem on my machine (RH5 cum RH61-ish) for some 
time now and reported it with a talkback today.

I'm running the KDE desktop but I'm not running klipper. XFree86-3.3.5

Showstopper.
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
elig@netscape.com to BlakeR1234@aol.com.  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...
QA Contact: elig → BlakeR1234
blake -- can you reproduce this one, we can't seem to reproduce it
Additional information...

* I'm still having this problem with nightly 2000081515.

* I don't have to actually leave the text marked - this makes the Summary
slightly incorrect.

* It doesn't occur if, instead of marking text with the mouse, I choose 'Select
All' in either the URL input-field or the browser window.

* The problem occurs immediatly after Mozilla outputs the 'Write Clipboard to
memory' string.

* It doesn't occur after pasting text /into/ Mozilla even though the 'Write
Clipboard...' is shown.
I managed to produce a backtrace using GDB 5.0 (I tried attaching it first but
that gives me new consistent segfault.)

-->loadDS(): ds=[xpconnect wrapped nsIRDFDataSource], loaded=true, returning! <--
WEBSHELL+ = 3
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
[New Thread 2140]
Document http://www.mozilla.org/ loaded successfully
->>>>>>>>>>>>>> Write Clipboard to memory

Program received signal SIGSEGV, Segmentation fault.
0x40286112 in _IO_fputs (str=0x875d9a8 "clearing PRIMARY clipboard\n",
fp=0x4031d480)
    at iofputs.c:39
39      iofputs.c: No such file or directory.
(gdb) backtrace
#0  0x40286112 in _IO_fputs (str=0x875d9a8 "clearing PRIMARY clipboard\n",
fp=0x4031d480)
    at iofputs.c:39
#1  0x4075738e in g_print (format=0x405e8f58 "clearing PRIMARY clipboard\n") at
gmessages.c:660
#2  0x405c5a47 in NSGetModule () from
/usr/local/mozilla/package/components/libwidget_gtk.so
#3  0x40686871 in gtk_marshal_BOOL__POINTER (object=0x872d368,
    func=0x405c59ec <NSGetModule+155120>, func_data=0x0, args=0xbffff5b0) at
gtkmarshal.c:28
#4  0x406b2327 in gtk_handlers_run (handlers=0x8143668, signal=0xbffff56c,
object=0x872d368,
    params=0xbffff5b0, after=0) at gtksignal.c:1909
#5  0x406b17ff in gtk_signal_real_emit (object=0x872d368, signal_id=36,
params=0xbffff5b0)
    at gtksignal.c:1469
#6  0x406afad0 in gtk_signal_emit (object=0x872d368, signal_id=36) at
gtksignal.c:552
#7  0x406e2b3b in gtk_widget_event (widget=0x872d368, event=0x81ebf58) at
gtkwidget.c:2860
#8  0x40685bca in gtk_main_do_event (event=0x81ebf58) at gtkmain.c:786
#9  0x405c9ce8 in NSGetModule () from
/usr/local/mozilla/package/components/libwidget_gtk.so
#10 0x4072ab92 in gdk_event_dispatch (source_data=0x0, current_time=0xbffff940,
user_data=0x0)
    at gdkevents.c:2129
#11 0x407546b6 in g_main_dispatch (dispatch_time=0xbffff940) at gmain.c:656
#12 0x40754c71 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#13 0x40754de9 in g_main_run (loop=0x81cbb50) at gmain.c:935
#14 0x4068549a in gtk_main () at gtkmain.c:476
#15 0x405c292c in NSGetModule () from
/usr/local/mozilla/package/components/libwidget_gtk.so
#16 0x4039020a in NSGetModule () from
/usr/local/mozilla/package/components/libnsappshell.so
#17 0x804dd0a in JS_PushArguments ()
#18 0x804e116 in JS_PushArguments ()
#19 0x4024ccb3 in __libc_start_main (main=0x804e00c <JS_PushArguments+11368>,
argc=1,
    argv=0xbffffb54, init=0x804aec4 <_init>, fini=0x8054544 <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffb4c) at
../sysdeps/generic/libc-start.c:78
(gdb)

HTH
What Björn is seeing seems to be slightly different from what I am seeing: I am
also getting the crash if I select text via "select all" in mozilla. I sent
another talkback trace ( TB15876570G ) of this incident. Furthermore, I am not
getting the crash *immediately* after the "write clipboard" message, rather
after I *finish* selecting text in another X application.

Björn is right though, that the crash also happens when the text is not selected
in mozilla any more. However, what i meant with "existing selection" is, that
whatever you selected in mozilla is still the current XSelection (i.e. gets
pasted if you middle-click). 
The common element of Patrick's talkback traces is
nsClipboard::SelectionClearCB() (the rest of the traces are lost in gtk code,
not mozilla code) and talkback on linux doesn't give line numbers.  Bjorn's
stack trace, unfortunately, only hits mozilla code in NSGetModule and doesn't
have a line number in mozilla code either.

It does seem like nsClipboard::SelectionClearCB() needs a close look.  Looking
at it, I notice that it doesn't check aEvent before dereferencing it, and
doesn't check its other arguments before passing them to gtk functions.

Pav, how about if I added some checks to all the arguments in this function, and
we see if that makes the problem go away for the people who are experiencing it?
Just checked in a slight modification of the patch, with Pav's okay.  Those of
you seeing the bug, please try tomorrow's builds and send an update indicating
whether it helped!
Marking this bug confirmed.  If we are working on a patch and others are seeing 
the bug then it seems like it should be new instead of unconfimred.
Status: UNCONFIRMED → NEW
Ever confirmed: true
i removed the assertion when aData is NULL, because it will always be null (and
isn't used)
I'm still seing this w/ the nightly 2000081808. The stack trace looks the same.
I am also still seeing this with build 2000082008. I couldn´t get another
talkback incident, because there wasn´t a talkback build for Linux on my local
mirror.
Accepting bug.
Status: NEW → ASSIGNED
FWIW this happens on my freshly compiled CVS version as well. I couldn't compile
the whole tree w/ debuginfo as I didn't feel I could spare more than 1Gig of
disk for this (company computer).

If someone wants to hold my hand I'll enable debug info on the relevant shared
libraries, widget_gtk I guess.

Debug info for widget_gtk would be a good start, and possibly also in htmlpars
(not clear whether that's involved or not, but it'll probably show up in the
stack trace).  Layout may also be involved, but that's a big library so you
might as well wait and see whether you need it before enabling it.  Kin: gfx
isn't likely to be involved here, is it?
I don't think gfx is involved here ... most likely suspect is
mozilla/widget/src/gtk clipboard code.
moving this out to future until we get a better handle on why this is sporadic, 
adding helpwanted
Severity: critical → normal
Keywords: helpwanted
Target Milestone: M19 → Future
*** Bug 53324 has been marked as a duplicate of this bug. ***
may be it helps...

I also had this problem but just now I have installed gtk1.2.8 and all works
quite fine now!

Works fine w/ gtk1.2.8 here.

Bug 59835 seems to be a duplicate of this bug although the stacktrace is quite
different. Upgrading to glib/gtk 1.2.8 apparently helps.
yes updating gtk AND glib to 1.2.8 does the trick for me as well, finally!
WFM build 2000111421.
I am using glib 1.2.8, gtk 1.2.8, XFree86 4.0.1, 2.2.16 and the 2000120608
nightly build for linux.  This crashing problem is still occuring for me.
As of build 2001010621 this seems to no longer be a problem for me.
changing selection qa to tpreston.
QA Contact: blaker → tpreston
removing myself from the cc list
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
This seems to work now (for three years) even for those few people who saw it),
possibly due to a gtk update three years ago.
I guess this bug can be resolved as WFM, no?

No objection...
-> WFM
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: