If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Mozilla 1.0 crashes on *leaving* a page with Flash

VERIFIED DUPLICATE of bug 154427

Status

External Software Affecting Firefox
Flash (Adobe)
VERIFIED DUPLICATE of bug 154427
16 years ago
a year ago

People

(Reporter: Robert Heller, Assigned: serge (gone))

Tracking

({crash, stackwanted})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

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

Updated

16 years ago
Severity: normal → critical
Keywords: crash

Updated

16 years ago
Keywords: stackwanted

Comment 1

16 years ago
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.
(Reporter)

Comment 2

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

16 years ago
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
Assignee: beppe → serge
(Assignee)

Comment 4

16 years ago
Robert are you running on remote display?
Any TB reports would be useful too.
(Reporter)

Comment 5

16 years ago
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.
(Assignee)

Comment 6

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

16 years ago
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
(Reporter)

Comment 8

16 years ago
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.
(Reporter)

Comment 9

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

16 years ago
> 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.
(Reporter)

Comment 11

16 years ago
Created attachment 88633 [details]
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.
(Reporter)

Comment 12

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

Comment 13

16 years ago
Created attachment 88683 [details]
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

16 years ago
looks like the stack from bug 58937 comment 60
(Reporter)

Comment 15

16 years ago
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.
(Reporter)

Comment 16

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

Updated

15 years ago
Severity: critical → normal

Comment 17

15 years ago

*** This bug has been marked as a duplicate of 154427 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 18

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

Status: RESOLVED → VERIFIED

Updated

8 years ago
Component: Plug-ins → Flash (Adobe)
Product: Core → Plugins
QA Contact: shrir → adobe-flash
Target Milestone: --- → 2002
Version: Trunk → 5.x

Updated

8 years ago
Summary: Mozzilla 1.0 crashes on *leaving* a page with Flash → Mozilla 1.0 crashes on *leaving* a page with Flash

Comment 19

a year ago
Version and milestone values are being reset to defaults as part of product refactoring.
Target Milestone: 2002 → ---
Version: 5.x → unspecified
You need to log in before you can comment on or make changes to this bug.