Closed
Bug 152884
Opened 22 years ago
Closed 22 years ago
Mozilla 1.0 crashes on *leaving* a page with Flash
Categories
(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 154427
People
(Reporter: heller, Assigned: srgchrpv)
References
()
Details
(Keywords: crash, stackwanted)
Attachments
(2 files)
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•22 years ago
|
Updated•22 years ago
|
Keywords: stackwanted
Comment 1•22 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•22 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•22 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•22 years ago
|
||
Robert are you running on remote display? Any TB reports would be useful too.
Reporter | ||
Comment 5•22 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•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
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•22 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•22 years ago
|
||
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•22 years ago
|
||
looks like the stack from bug 58937 comment 60
Reporter | ||
Comment 15•22 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•22 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•22 years ago
|
Severity: critical → normal
Comment 17•22 years ago
|
||
*** This bug has been marked as a duplicate of 154427 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Comment 18•22 years ago
|
||
mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"
Status: RESOLVED → VERIFIED
Component: Plug-ins → Flash (Adobe)
Product: Core → Plugins
QA Contact: shrir → adobe-flash
Target Milestone: --- → 2002
Version: Trunk → 5.x
Updated•14 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•8 years ago
|
||
Version and milestone values are being reset to defaults as part of product refactoring.
Target Milestone: 2002 → ---
Version: 5.x → unspecified
Updated•2 years ago
|
Product: External Software Affecting Firefox → External Software Affecting Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•