46409 - [X] Mozilla crashes on clipboard code

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[Jeffrey Baker]

Hard to reproduce.  Observed on Linux i686 Build 2000072508, and also in the
past.  My system uses XFree86 4.0.1, but also observed on 4.0.  The problem is
that, sometimes, Mozilla won't start.  Using the mozilla script in the
distribution, I get this on the console:

[jwb ~/package] ./mozilla 
./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/jwb/.mozilla/default/chrome/user.css' failed.  Error code: 16389
WEBSHELL+ = 2

-->loadDS(): ds=[xpconnect wrapped nsIRDFDataSource], loaded=true, returning!
<--
WEBSHELL+ = 3

And the the browser stops.  No window is ever displayed.  This happens
persistently, even if I delete my profiles and reinstall the browser.  The only
solution is to quit and restart X, after which the browser launches fine.

This may be related to an adverse interaction between mozilla and
gnome-moz-remote.  I suppose there is some xlib code in Mozilla that allows
gnome-moz-remote to find and communicate with a running Mozilla.  I used
gnome-moz-remote to load a web page immediately before this problem happened,
but since I can't reproduce, I also can't say for certain that this is the
problem.

Comment 1

[Jeffrey Baker]

Give to blizzard since he seems interested (Bug 44847)

Comment 2

[Christopher Blizzard (:blizzard)]

vewwy interesting.  Before you start up the browser can you do an xprop -root
|grep MOZ and tell me if you see anything there?

Comment 3

[Jeffrey Baker]

xprop -root | grep MOZ doesn't come up with anything before or after the browser
starts, nor during the gnome-moz-remote action if I use xprop -root -spy.

When I use xprop -spy to watch the Mozilla window, I get this when gnome-moz
remote is running:

_MOZILLA_LOCK(STRING) = "pid2086@piglet"
_MOZILLA_COMMAND:  not found.
_MOZILLA_COMMAND:  not found.
_MOZILLA_RESPONSE(STRING) = "200 executed command:
openURL(http://www.yahoo.com,new-window, noraise)"
_MOZILLA_RESPONSE:  not found.
_MOZILLA_LOCK:  not found.

Dunno if that helps.  If it happens again I'll examine the root window properties.

Comment 4

[Jeffrey Baker]

Okay, I actually reproduced this.  What is happening is Mozilla mostly starts
up, then before it paints any windows, it spins on the CPU doing this:

ioctl(8, FIONREAD, 0xbfffaae4)          = 0

In a very tight loop.  File handle 8 is a socket, probably Mozilla's connection
to the X server.  Hence, this is a duplicate of bug 39093.  BUT, I am not duping
because that is the Bug of Perpetually Ignoring Jeff.  Instead, I am going to
leave my Mozilla in this state, in case someone would like to debug it in the
wild.  I will make a shell account for whomever steps up to debug this.  Mail
me.

Comment 5

[Jeffrey Baker]

Okay I've *finally* figured this one out.  Mozilla is crashing when another
X client uses the X clipboard.  Note that I'm talking about the clipboard, not
the X cut buffer.  The only way I know of to reproduce this is to a use a Motif
editor (NEdit) which uses the clipboard.  That's why this constantly bites me: I
use this editor for everything.  The simplest way to reproduce:

1) Start NEdit
2) Type "foo", select it, and pick edit->copy from the menu
3) Start Mozilla

Mozilla will not start, as previously described.  It loops around some X11 code.

You can also make Mozilla crash while running:

1) Start Mozilla and NEdit
2) in NEdit, type something, select it, and pick edit->copy from the menu

Mozilla spins forever, and it won't start afterwards.  The only way to get
Mozilla to start again is to exit NEdit.

cc'ing pavlov since he owns all the other X clipboard bugs.

Comment 6

[Stuart Parmenter]

mmmmmm.. neat.. i'm on it

Comment 7

[Peter Trudelle]

nsbeta3+, M18, P1

Comment 8

[Stuart Parmenter]

Attachment: workaround patch

Comment 9

[Stuart Parmenter]

heres a patch that "fixes" the problem... i think I might understand what is
happening here, but i'm not sure. I need to run some more tests...  it looks
like nedit is just being really slow to respond to my convert request, so I'm
missing it every responding.

Comment 10

[Stuart Parmenter]

although this patch breaks pasting.. heh

Comment 11

[Jeffrey Baker]

FWIW, even xclipboard(1) can't handle NEdit's cut/copy behavior.  A few seconds
after cutting from NEdit, I get a "CLIPBOARD conversion failed" message from
xclipboard.  I'll report the problem to the NEdit and LessTif folks.  Mozilla
shouldn't be crashing regardless.

Comment 12

[Stuart Parmenter]

I agree.  I should have some kind of timeout instead of looping forever.  This
will at least fix the hang.  I don't know what to do about nedit.  I feel pretty
sure that the code in mozilla is icccm compliant and should work fine.

Comment 13

[Stuart Parmenter]

Attachment: new patch

Comment 14

[Stuart Parmenter]

heres a patch that does fix the problem... but I really don't like guessing how
long it will take to get an answer...  With 10000, it takes a looooooong time to
get things back, but I see 2600 or so pretty often when running mozilla
locally... I'd hate to immagine what this could be remotely.......

Comment 15

[Jeffrey Baker]

I pulled cvs and applied your patch around 2000-08-17-20.  Mozilla no longer
crashes when NEdit mucks with the clipboard, but I do get this assertion
whenever Mozilla needs to clear the cut buffer:

###!!! ASSERTION: Null data passed to SelectionClearCB)
: 'PR_FALSE', file nsClipboard.cpp, line 1012
###!!! Break: at file nsClipboard.cpp, line 1012

Reproduce: select something in Moz, then select something in xterm.  Related? 
WIP?

Comment 16

[Stuart Parmenter]

the assertion in bogus.. i've removed it.  I'm going to try and figure out what
nedit is doing (or not doing).

Comment 17

[Stuart Parmenter]

ok, I think I have a real fix for this.  nedit (using motif) grabs ownership of
the _MOTIF_CLIP_LOCK selection and doesn't let go...  So I have added a check
when someone is asking for CLIPBOARD (motif's clipboard atom) to check
_MOTIF_CLIP_LOCK and do nothing if there is an owner for it.  I will attach a
patch once I have verified this works (waiting for build to finish...)

Comment 18

[Stuart Parmenter]

argh.  this doesn't happen with nedit on solaris (built using their motif
stuff)... i'm going to play around with different versions of lesstif and motif
on linux.  what version of motif/nedit/linux are you using?

Comment 19

[Jeffrey Baker]

Yeah, it is definitely not present when I build NEdit against Motif, or use the
statically linked binaries from www.nedit.org.  The problem is present in
Lesstif 0.91.4, which is the current release at the moment.

Comment 20

[Stuart Parmenter]

nedit built with openmotif works too.. sigh :)

Comment 21

[Stuart Parmenter]

Attachment: same patch, minus extra crap

Comment 22

[Stuart Parmenter]

Attachment: new patch.. I like this one better

Comment 23

[Stuart Parmenter]

er, addEventBack should return PR_TRUE, not PR_FALSE

Comment 24

[Stuart Parmenter]

Attachment: new patch

Comment 25

[Stuart Parmenter]

fixed

Comment 26

[John Morrison]

Hey Jeff, is this working correctly for you now?

Comment 27

[Jeffrey Baker]

Most definitely.  Pav is my X.hero.

Comment 28

[John Morrison]

Thanks for following up ... Pav is the man. (Marking verified).