152884 - Mozilla 1.0 crashes on *leaving* a page with Flash

Status: VERIFIED DUPLICATE of bug 154427

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Robert Heller]

I installed Mozzilla 1.0 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0)
Gecko/20020614) on a RedHat Linux 6.2 system (Linux athos.cs.umass.edu 2.2.16-3
#1 Mon Jun 19 18:49:25 EDT 2000 i686 unknown, glibc-2.1.3-15), and downloaded
and installed Flash 5 (Shockwave Flash 5.0 r48).  It works fine -- I can visit a
site with flash content and it works.  However, when I go visit another site,
(flash or not), Mozzilla crashes.  I'm guessing something is broken in the
process run-down code.  I don't know if it is flash or mozilla.

Oh, just to make things interesting, this is a Pentium Pro @ 200mhz, and I have
NO sound card.  I'm using a S3/Virge video card in 24-bit mode. And FVWM2 in MWM
mode.

Comment 1

[shrirang khanzode]

there's one applet on this page and a flash movie. so it's..50-50. cc ing pmac 
to see if she can reproduce on linux. I could not.

Comment 2

[Robert Heller]

It also crashes leaving http://home.earthlink.net/~hellerest/intractv.htm, which
only contains an interactive flash application.  If I disable the flash plugin
(by removing the plugin's components, the libflash shared library and the flash
class file), both pages cause no problems (other than having a blank spot with
the missing plugin icon in the middle).  Seems pretty clear that it is flash,
somehow.

My *only* other thought I have is the version of Linux I am using (RH 6.2, 2.2
kernel) might be old -- I have no plans to rush out and upgrade to RH 7.2 or
7.3.  I did build the version of Mozilla from the *source* rpms.  Mozilla 1.0
seems to work just fine otherwise, including running Java applets with the JRE I
installed for Mozilla 9.5.  Oh, I also tried disabling the Java plug in and this
had no effect.

Comment 3

[rubydoo123]

this could well be a linux only issue, I tested this on winXP and I could not
reproduce the crash. I do recall a similar bug about a month or so ago but could
not find the reference in the db.

handing this one over to serge. As an fyi, I tested this using the branch build
from today (20020619)

I could not confirm this bug

Comment 4

[serge (gone)]

Robert are you running on remote display?
Any TB reports would be useful too.

Comment 5

[Robert Heller]

Running on the local display.

What is a 'TB'?  Traceback?  You want me to fire up mozilla with gdb?  I guess I
can do that, although I doubt that the mozilla executable was built with the -g
option -- I did not just download and build from the tarball.  I used the SRPM
for meant for RH 7.2 (I needed to make a *minor* change to the spec file
relating to a patch for the default initial page, which had problems under RH 6.2).

I have this installed on my work (UMass) desktop -- I won't have access to it
until Friday.

What is of course not known is how the flash plugin was built (which version of
Linux, which libc, etc.).  Also, my machine *does not* have a audio device --
flash applications often have an audio component.  I know that I had trouble
with Netscape 4.7<mumble> dealing with embedded WAV files and such like.

Comment 6

[serge (gone)]

TB == TalkBack is technology which allows to collect some crash info, a stack
trace etc, (http://climate.netscape.com/main/talkback.cfm)
RH mozilla RPM does not include TB support, but builds from
http://www.mozilla.org/releases/stable.html
http://www.mozilla.org/releases/
have such support.
Could you try the latest builds, please. Thanks.

Comment 7

[Andrew Schultz]

you can get stacktraces from RPM builds using gdb.  the "-g" option does not
work with RPM build's scripts, but you can start mozilla and then attach gdb to it.

% mozilla
% ps u -C mozilla-bin (get the pid)
% gdb mozilla_dir/mozilla-bin PID

Comment 8

[Robert Heller]

The version I have is built from the SRPM I downloaded from
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/Red_Hat_7x_RPMS/SRPMS/mozilla-1.0.0-9.src.rpm
-- I could not use the *binary* RPMs, since they were built for RH 7.x and I am
running RH 6.2.  I'll check to see if the version I built includes the TalkBack
support code.  If not I will use the gdb hack.

I would really rather not build yet another version of mozilla -- the machine I
am using has a limited amount of disk space.

Comment 9

[Robert Heller]

The link, http://climate.netscape.com/main/talkback.cfm, appears to be broken. 
I am getting a DNS failure on climate.netscape.com.

Comment 10

[Andrew Schultz]

> The link, http://climate.netscape.com/main/talkback.cfm, appears to be broken.

AFAIK, climate is internal to netscape.  I have never been able to access it,
although Netscape folks often reference it.  This URL works:

http://wp.netscape.com/communicator/navigator/v4.5/qfs1.html

> I'll check to see if the version I built includes the TalkBack support code.

you cannot build with talkback.  it's 3rd-party commercial software licensed to
Netscape.

Comment 11

[Robert Heller]

Attachment: GDB stack strace for crash (leaving a page with Flash)

This is a traceback I got with gdb (gdb /usr/lib/mozilla-1.0.0/mozilla-bin
9096) using gdb's 'where' command.

Comment 12

[Robert Heller]

OK, I got a dump of the stack.  It *looks* like it is in libflashplayer.so when
it crashes.  Maybe there is something screwy with libflashplayer.so???

Comment 13

[Robert Heller]

Attachment: Shockwave Flash crash TalkBack data

Here is the TalkBack data.  This is with a temp install of the latest 'stable'
release:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/mozilla-i686-pc-linux-gnu-1.0-sea.tar.gz
on the *same* machine as the RPM version was installed on.

Comment 14

[Andrew Schultz]

looks like the stack from bug 58937 comment 60

Comment 15

[Robert Heller]

The thing that it weird with this is that:

1) It is not a 'remote' display, although I am NOT using the local socket, but
the real network socket (eg hostname:0.0, not unix:0.0).  This is due to my
.xinitrc file changing the DISPLAY this way, so I can transparently pass it off
to other computers via rsh (I know, I really should be using ssh, but some of
this is old scripts and such -- eventually, everything will migrate to using ssh
and X11 forwarding).

2) Flash runs fine, once.  When I *leave* a page, things crash and burn.  I
visited bug #58937, and yes the stack dump looks very similar.  Actually it
looks the *same* (except for slightly different addresses).

And it does look like it is in fact crashing *in libflashplayer.so*.  I wonder:
is NS 4.x catching (and ignoring) this signal?  Or does NS 4.x have a
'protected' wrapper for __libc_free()?  It does *appear* that something is in
fact broken in libflashplayer.so.  I agree that although libflashplayer.so is
broken, Mozilla needs to do something to *handle* the error: catch the signal,
report that flash crashed, clean up flash's 'mess', and go on with life...  In a
sense, there are *two* bugs: 1) libflashplayer.so is broken -- *we* can't do
anything about this and 2) Mozilla does not properly handle 'broken' plugins and
it should.

Comment 16

[Robert Heller]

Some additional tests:

I created a wrapper script, which compares the hostname part of DISPLAY with the
hostname and if they are effectively the same (or if the hostname part of
display is 'localhost'), I reset the display to use 'unix:<screen>' instead of
'host:<screen>'.  Mozilla 1.0 AND libflashplayer.so play nice together --
libflashplayer.so does NOT crash when leaving a page with a Flash application.

I also (manually) tested with display set to 'localhost:0.0', and
libflashplayer.so did not crash then, which seems slightly weird to me.  Eiher
Mozilla or libflashplayer.so is testing for and special casing
localhost/127.0.0.1 or there is something different about the loopback device as
compared to the local EtherNet -- my understanding is that they are meant to be
interchangable, so network oriented software will have a fallback/failsafe
situation on machines with no external network.

So *I* presently have a sort of workaround -- this script which tests for true
localness of the display.  But this most certainnly does NOT fix the bug and is
nowhere like a general fix.  It only works for me because I generally surf on my
local box.

My only other thoughts:  Are there plans to 'bulletproff' mozilla from plugin
crashes.  And does any know of an *effective* means to presure Macromedia to
either fix their plugin properly (or better) Open Source their player code?

Comment 17

[rubydoo123]

*** This bug has been marked as a duplicate of 154427 ***

Comment 18

[shrirang khanzode]

mass duplicate verifications . For filtering purposes, pls use keywd
"massdupverification"

Comment 19

[BMO Automation]

Version and milestone values are being reset to defaults as part of product refactoring.