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




19 years ago
15 years ago


(Reporter: pat, Assigned: kinmoz)


({crash, helpwanted})

crash, helpwanted

Firefox Tracking Flags

(Not tracked)



(1 attachment)



19 years ago
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 )-:

./ ./mozilla-bin
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/pat/.mozilla/default/chrome/user.css' failed.  Error code: 16389

-->loadDS(): ds=[xpconnect wrapped nsIRDFDataSource], loaded=true, returning! <--
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
Document: Done (2.304 secs)
*** check number of frames in content area
Error getting url widget service: TypeError: Components.classes[progid] has no
Document loaded successfully
### Here I selected Text in Mozilla
->>>>>>>>>>>>>> Write Clipboard to memory
### Here I switched to xemacs and selected some text ###
./ line 29:   846 Segmentation fault      $prog ${1+"$@"}

Comment 1

19 years ago
assigning to Kin, setting to m18 and adding to nsbeta3+ 
Assignee: mjudge → kin
Keywords: crash, nsbeta3
Whiteboard: nsbeta3+
Target Milestone: --- → M18

Comment 2

19 years ago
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.

Comment 3

19 years ago
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

Comment 4

19 years ago
I don't think it's the same thing anthonyd is looking at (MicroMagic).

Accepting bug. Adding to Cc list since this sounds like it's
related to the grabbing of XSelection. Akkana, can you repro this?

Comment 5

19 years ago
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.)

Comment 6

19 years ago
My base system is Suse 6.1 (XFree86, 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

Comment 7

19 years ago
I can't reproduce this either on my RedHat 6.1 system. (XFree86-3.3.5-3,

Comment 8

19 years ago
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...

Comment 9

19 years ago
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

Comment 10

19 years ago
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.

Comment 11

19 years ago
removing nsbeta3+ until we can reproduce, moving out to m19
Keywords: nsbeta3
Whiteboard: nsbeta3+
Target Milestone: M18 → M19

Comment 12

19 years ago
WFM on 2000080308 (M18), using KDE and even having klipper running. What
application is giving you the crash?

Comment 13

19 years ago
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). 

Comment 14

19 years ago
just asked another person to test this (jag) and he could not reproduce this 

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

Comment 15

19 years ago
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


Comment 16

19 years ago
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from to  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 
QA Contact: elig → BlakeR1234

Comment 17

19 years ago
blake -- can you reproduce this one, we can't seem to reproduce it

Comment 18

19 years ago
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.

Comment 19

19 years ago
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! <--
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
[New Thread 2140]
Document loaded successfully
->>>>>>>>>>>>>> Write Clipboard to memory

Program received signal SIGSEGV, Segmentation fault.
0x40286112 in _IO_fputs (str=0x875d9a8 "clearing PRIMARY clipboard\n",
    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",
    at iofputs.c:39
#1  0x4075738e in g_print (format=0x405e8f58 "clearing PRIMARY clipboard\n") at
#2  0x405c5a47 in NSGetModule () from
#3  0x40686871 in gtk_marshal_BOOL__POINTER (object=0x872d368,
    func=0x405c59ec <NSGetModule+155120>, func_data=0x0, args=0xbffff5b0) at
#4  0x406b2327 in gtk_handlers_run (handlers=0x8143668, signal=0xbffff56c,
    params=0xbffff5b0, after=0) at gtksignal.c:1909
#5  0x406b17ff in gtk_signal_real_emit (object=0x872d368, signal_id=36,
    at gtksignal.c:1469
#6  0x406afad0 in gtk_signal_emit (object=0x872d368, signal_id=36) at
#7  0x406e2b3b in gtk_widget_event (widget=0x872d368, event=0x81ebf58) at
#8  0x40685bca in gtk_main_do_event (event=0x81ebf58) at gtkmain.c:786
#9  0x405c9ce8 in NSGetModule () from
#10 0x4072ab92 in gdk_event_dispatch (source_data=0x0, current_time=0xbffff940,
    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
#16 0x4039020a in NSGetModule () from
#17 0x804dd0a in JS_PushArguments ()
#18 0x804e116 in JS_PushArguments ()
#19 0x4024ccb3 in __libc_start_main (main=0x804e00c <JS_PushArguments+11368>,
    argv=0xbffffb54, init=0x804aec4 <_init>, fini=0x8054544 <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffb4c) at


Comment 20

19 years ago
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). 

Comment 21

19 years ago
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?

Comment 23

19 years ago
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!

Comment 24

19 years ago
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.
Ever confirmed: true

Comment 25

19 years ago
i removed the assertion when aData is NULL, because it will always be null (and
isn't used)

Comment 26

19 years ago
I'm still seing this w/ the nightly 2000081808. The stack trace looks the same.

Comment 27

19 years ago
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

Comment 28

19 years ago
Accepting bug.

Comment 29

19 years ago
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.

Comment 30

19 years ago
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?

Comment 31

19 years ago
I don't think gfx is involved here ... most likely suspect is
mozilla/widget/src/gtk clipboard code.

Comment 32

19 years ago
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

Comment 33

19 years ago
*** Bug 53324 has been marked as a duplicate of this bug. ***

Comment 34

19 years ago
may be it helps...

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

Comment 35

19 years ago
Works fine w/ gtk1.2.8 here.

Comment 36

19 years ago
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.

Comment 37

19 years ago
yes updating gtk AND glib to 1.2.8 does the trick for me as well, finally!
WFM build 2000111421.

Comment 38

19 years ago
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.

Comment 39

19 years ago
As of build 2001010621 this seems to no longer be a problem for me.

Comment 40

17 years ago
changing selection qa to tpreston.
QA Contact: blaker → tpreston

Comment 41

17 years ago
removing myself from the cc list

Comment 42

16 years ago
By the definitions on <> and
<>, 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

Comment 43

16 years ago
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?

Comment 44

15 years ago
No objection...
-> WFM
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.