Closed Bug 36381 Opened 25 years ago Closed 24 years ago

crash when going to java.sun.com when Talkback is installed

Categories

(Core Graveyard :: Java: OJI, defect, P1)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
PowerPC
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: namachi)

References

(
URL
)

Details

(4 keywords, Whiteboard: [dogfood-][nsbeta3-]{PDTP1}[rtm need info])

Attachments

(2 files)

stdlog in Macsbug of crash
20.97 KB, text/plain
Details
stdlog from MacsBug of crash
27.30 KB, text/plain
Details
not sure if this is the correct component, but... found this testing opt comm mac bits 2000.04.19.10-m16. talkback link & info: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=104&cp=1&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=9010137 Trigger Reason: PowerPC access violation Call Stack: (Signature = .__ptr_glue 679e3ab1) .__ptr_glue .__dl__FPv [CPlusPlusLevel.cp] nsStdURLParser::~nsStdURLParser() [nsStdURLParser.cpp, line 29] nsStdURLParser::Release() [nsStdURLParser.cpp, line 26] nsCOMPtr_base::~nsCOMPtr_base() [nsCOMPtr.cpp, line 49] nsStdURL::~nsStdURL() [nsStdURL.cpp, line 188] nsStdURL::Release() [nsStdURL.cpp, line 191] nsStdURL::Release() [nsStdURL.cpp, line 191] nsCOMPtr_base::~nsCOMPtr_base() [nsCOMPtr.cpp, line 49] nsHTTPHandler::ReleaseTransport() [nsHTTPHandler.cpp, line 1170] nsHTTPPipelinedRequest::RestartRequest() [nsHTTPRequest.cpp, line 872] nsHTTPServerListener::OnStopRequest() [nsHTTPResponseListener.cpp, line 598] nsOnStopRequestEvent::HandleEvent() [nsAsyncStreamListener.cpp, line 306] nsStreamListenerEvent::HandlePLEvent() [nsAsyncStreamListener.cpp, line 97] PL_HandleEvent() [plevent.c, line 575] PL_ProcessPendingEvents() [plevent.c, line 520] nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp, line 316] nsMacNSPREventQueueHandler::ProcessPLEventQueue() [nsToolkit.cpp, line 132] nsMacNSPREventQueueHandler::RepeatAction() [nsToolkit.cpp, line 97] Repeater::DoRepeaters() [nsRepeater.cpp, line 119] nsMacMessagePump::DispatchEvent() [nsMacMessagePump.cpp, line 366] nsMacMessagePump::DoMessagePump() [nsMacMessagePump.cpp, line 244] nsAppShell::Run() [nsAppShell.cpp, line 100] nsAppShellService::Run() [nsAppShellService.cpp, line 364] main1() [nsAppRunner.cpp, line 758] main() [nsAppRunner.cpp, line 879] .__start
not a problem on winNT or linux (m16, today's comm bits).
Keywords: pp, smoketest
Bug 35852 also nebulously reports a crash at java.sun.com using WinNT.
FWIW: I don't see this at all on WinNT debug build from yesterday late afternoon.
Sairuh, do you see this even if you don't have the MRJ installed on the mac?
also, is this happening at any other java-using websites? or just java.sun.com?
another site where this happens: go to http://www.philly.com/packages/starwars/index.html and click on the "LucasFile strikes back!" link to load a page w/an java applet. boom, crash seamonkey.
If MRJ is removed, it does not crash.
component: OJI
Assignee: akhil.arora → drapeau
Component: Java-Implemented Plugins → OJI
QA Contact: rajendra.pallath → paw
can we make this a non-blocker, since there is a workaround?
okay...adding relnote in case this doesn't get fixed for the next milestone. ;-P
Severity: blocker → critical
Keywords: relnote
Putting on [dogfood+] for a fix ASAP. PDT spoke with ruslan, assigning since he says he is looking at it.
Assignee: drapeau → ruslan
Whiteboard: [dogfood+]
reassign to me
Assignee: ruslan → davidm
I wouldn't consider removing MRJ as a "workaround."
Not getting an inital crash but get an error on the screen. Java.Lan.NullPointerException. The applets are displayed on the page. If I then go to the applet page, I sometimes will crash. Sometimes I can even load the bubbles applet at www.sun.java.com/applets/bubbles and then I crash.
it is crashing sporadically for me. Sometimes everything loads and when I go to a different page it then crashes. I assume Java.Lan.NullPointerException is a java runtime bug ( ie bad java code) and not something that I should worry about. I noticed that we don't seem to be releasing the socket transport right away but that it occurs at some later date. Ruslan is this a result of keep alive? OJI/MRJ also seems to have bunch of drawing problems particually when scrolling.
Yes. The transport can be put on a keep-alive list and live there for a while. This is normal.
That stack trace is wrong;) The crash is in nsPluginInstancePeerImpl::ShowStatus() because mOwner was deleted. There is some ownership issues here since mOwner is not addrefed. Reassign to plugins.
Assignee: davidm → av
Component: OJI → Plug-ins
QA Contact: paw → shrir
Adding crash keyword.
Keywords: crash
What is the problem here? If the stack trace is wrong, can we get a good one, and hear about progress? Crashing at a major site like this has got to be making it hard for Java folks to even consider our build. Please put a landing date on the status whiteboard. This is a dogfood bug, and should have a very high priority relative to other work. Thanks, Jim
Correcting Component. FYI, I was able to load this page with the appplet displaying properly and I saw no crash(today's mac build). sairuh, could you please check what you see with today's build?
Assignee: av → drapeau
Component: Plug-ins → OJI
QA Contact: shrir → paw
Removing self from CC list since I don't care about java bugs. FWIW if you comment out the code in nsPluginInstancePeerImpl::ShowStatus() you don't crash which might be considered a short term workaround. And the crash is on leaving the page/reloading the page more than on loading it.
still crash and get the same trace info using today's opt comm bits, 2000.04.27.10. the MacsBug trace i got didn't have any info in it at all. perhaps my setup is incorrect (but i'd think i shouldn't get a crash).
see following comments in a second.
Assignee: drapeau → loki-sun
this is going to make your head pop, but this works for me; i don't believe the build process is to build the mrj plugin at this point (13848). i also have no idea what the status of the migration of tinderbox to build with universal 3.3.1 is, but perhaps an incompatibility lies there. i agree the stack trace doesn't have much to do with the mrj plugin. i can again send my compiled plugins to someone, or preferably i can just start leaving them at an ftp site somewhere, or 13848 can get closed..
I copy the mrj stuff from the daily internal netscape builds. I don't know where they get mrj from. Universal headers is a red herring. This is an memory ownership issue. If a later version of the plugin solves this fine. Also note this wasn't 100% reproduceable but if I reloaded the page often enough I would crash. I really hate marking bugs like these works for me if someone can't point out some code that at the very least could have fixed it.
when you write "copy the mrj stuff from the daily internal netscape builds", what do you mean exactly? is the plugin getting built daily on netscape internal builds? (are these internal builds not the mozilla builds, i take it?) or do you mean you're building the plugin yourself from source taken from a netscape internal tree? or ? can anybody tell me whether the plugin is now integrated in any build processes?
(just would like to verify that you're loading a currently built plugin; those crazy kids changed the vtable of nsIComponentManager a couple weeks ago.. this made for uglies on the windows plugin, so i'd make no bets on the reliabilities of a non-recent-compile mac plugin.)
I just downloaded todays mozilla build and I can still reproduce. What I did was go to java.sun.com hit reload a couple of times go to a different site ( I went to cnnsi ) hit back and I crashed with java plugin code on the stack. I can also reproduce by just hitting reload a lot. I do not know how/where the plugin is getting build but if there is better code out there, the release builds sure don't contain it.
agh! jimminy xmas... i'm not questioning whether you can reproduce this... the original question is: -- since the beginning of time, and for what i can still tell, the plugin is not being built with the nightly builds... conceivably the plugin you have has a version of 1.1eqd1 in the get info box which means it was built over a month ago.. this is why i'm inquiring as to what the state of the build process is; i'm very sure you are able to reproduce this - not questioning that..
Changing the milestone to "Future" since Loki is no longer working at Sun, or on this component, and it's unknown when somebody can take on the work. Also assigning ownership of the bug to the OJI module owner (uh, that would be me).
Assignee: loki-sun → drapeau
QA Contact: paw → shrir
Target Milestone: --- → Future
...and this still occurs for me, using today's opt commercial bits 2000.05.31.08 on Mac OS 9.0. is there *anything* i could do to stop the crashing? that is, could someone pls provide steps so i can clear out everything java-related that could be the root of the crashing? true, it doesn't solve the issue, but at least i won't get a crash everytime i access this high-profile site. :-)
Keywords: top100
If you look at original davidm comment - it appeared that the refcount was wrong inside of java plugin and that was causing random crashes. " .... nsPluginInstancePeerImpl::ShowStatus() because mOwner was deleted". It's likely an mrj plugin bug.
Changing the milestone to "--" to express that I don't know when it will get done, as opposed to "Future" which I recently learned means that this is for post-FCS for Netscape 6.
Target Milestone: Future → ---
Okay, I'm gonna be the bearer of bad news, and am actually painting it worse than the situation may be. There is currently nobody looking at Mac OJI bugs, so ETA is unknown. However, one of the fine people working on OJI code found a bug in nsPluginInstancePeerImpl::ShowStatus(); evidently it isn't thread-safe. That *could* be causing the problem here. Random failures as reported here could easily be caused by thread problems. When the code is fixed for Linux, we can try here and see if the problem goes away?
drapeau, d'you know the bugid for the linux issue you mentioned above? i'll pop it here as a [possible] dependency... thx!
Hey, "s.e.v.l." ( :-) )... oops, my bad. I was commenting based on a status message sent to me by one of our developers in Russia. He's working on the Linux port of Java Plug-In, and in the course of development evidently he ran into this problem. Best case, Nikolay should probably file a new Bugzilla bug (no, there's no bug yet) and then he can submit the patch to fix that bug as an attachment. Nikolay? By the way, bug 28461 is the bug for "Java doesn't work on Linux".
I'm sorry, I still am not in a position to be able to put an ETA on this bug. I have no Macintosh resources to work on the problem, and our Linux Java Plug-In isn't quite ready for testing, in case this turns out to be a PP bug. Will update status if/when I can.
*** Bug 43944 has been marked as a duplicate of this bug. ***
*** Bug 43945 has been marked as a duplicate of this bug. ***
*** Bug 43948 has been marked as a duplicate of this bug. ***
*** Bug 43949 has been marked as a duplicate of this bug. ***
Setting Qa to myself.
Priority: P3 → P1
QA Contact: shrir → junruh
*** Bug 44604 has been marked as a duplicate of this bug. ***
Checking into bug on request from jaworski since Sun has no Mac OJI resources. Added beard to cc: list, removed davidm. Added Macsbug log attachment with more info. Crash doesn't occur loading applet at http://java.sun.com/ or http:// www.philly.com/packages/starwars/index.html but does on quit with the latter. We also have some drawing problems, at least with my build, with the Applet frame drawing on the wrong part of the window but that's probably a different bug. Hopefully beard can shed some light on the situatiuon since he's intimately familiar with both OJI and the MRJ plugin. NOTE: My tests were done with MRJ 2.2.2. Your mileage may vary.
Hoping that somebody will volunteer to fix the bug, but since I cannot identify any resources, I'm removing the plus from the dogfood keyword to vote not to hold release on this. If I did a bad thing, please feel free to chide me, and I won't do that anymore.
Whiteboard: [dogfood+] → [dogfood]
Removing "relnote", since I added a relnote to vera's bug 37174.
Keywords: relnote
Replacing relnote2.
Keywords: relnote2
*** Bug 41870 has been marked as a duplicate of this bug. ***
Putting on nebeta3 nominee
Keywords: nsbeta3
Whiteboard: [dogfood] → [dogfood-]
Clarification; amplification. Just checked this bug out with M18-200080108 build running under Mac OS 9.0.4, MRJ 2.2, carbon libs 1.0.4 on an iMac DV. http://java.sun.com/ *did* load without crashing on this machine with that build. The funny stuff began when I started scrolling around. The java applet windows would hold their position as I scrolled up and down the browser window. It appeared the display was failing to refresh properly. I managed to get the applet to cover the buttons at the top of Mozilla, and also the buttons at the bottom of my browser window. I left the Sun site and surfed a couple other sites. I was able to get the screen to partially refresh and reveal some buttons (though lines existed between buttons). When I attempted to refresh the "offline" button in the bottom left corner, Mozilla blew up with a type 2 error. Hope this helps.
Some more clarification & amplification: While checking out bug 46662, I surfed to http://www.bigbrother2000.com . Machine and OS were same as my previous post. Lo, and behold, the java applet there behaved in a similar manner. The ticker kept running as I scrolled up and down the browser window, and it stopped where it darn well wanted to. No crash yet (I'm still surfing around), but thought I'd throw this out. Perhaps these two bugs are related somehow. I don't have enough programming skills to know. Have a lovely day.
Reassigning.
Assignee: drapeau → edburns
accept
Status: NEW → ASSIGNED
Whiteboard: [dogfood-] → [dogfood-][nsbeta3+]
Whiteboard: [dogfood-][nsbeta3+] → [dogfood-][nsbeta3+]{PDTP1}
Would not hold PR3 for this...
Can this bug be closed? Visiting java.sun.com no longer crashes the browser. The applet redraw/display problem is covered in bug 36500 and numerous others that are duplicates of bug 7366 (which has been around since May 1999). Since there are no resources for Mac java development, I think the less java bugs the better, no?
Change to nsbeta3-. Also, per adam kay's post, can we mark this fixed, since it doesn't crash any more (according to him)?
Whiteboard: [dogfood-][nsbeta3+]{PDTP1} → [dogfood-][nsbeta3+-{PDTP1}
9/20 Mac installer build. This is not fixed. Crash the first try, lockup the second try at http://java.sun.com/applets/other/Bubbles/index.html
confirming...this is still happening for me too (20000918m18)
Clarification; amplification. I'm still getting the "Java.Lan.NullPointerException" dialog box at http://java.sun.com/ . Mozilla build: 2000092120-M18. I've updated my iMac DV with MRJ version 2.2.3, which was released 22 Sep 00. Everything else on my machine is the same. This was, though, the first time I've seen the "Java.Lan.NullPointerException" dialog box.
Yet another clue. Just found this floating around in my Preferences folder in the System Folder of my machine after accessing http://java.sun.com/ (the file was called "MRJPluginAppletOutput" and was saved as a SimpleText document) : MRJ Console Output. MRJ Plugin Version: eerieQuarkDoll.v.b1 -------------------- [System.err] An exception occurred: [System.err] [System.err] java.lang.NullPointerException [System.err] [System.err] at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java) [System.err] [System.err] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java) [System.err] [System.err] at com.apple.mrj.JManager.JARCache$CachedJAR.openConnectionCheckRedirects(JARCache.java) [System.err] [System.err] at com.apple.mrj.JManager.JARCache$CachedJAR.checkUpToDate(JARCache.java) [System.err] [System.err] at com.apple.mrj.JManager.JARCache$CachedJAR.<init>(JARCache.java) [System.err] [System.err] at com.apple.mrj.JManager.JARCache.isCached(JARCache.java) [System.err] [System.err] at com.apple.mrj.JManager.JMAppletResourceLoader.loadJar(JMAppletResourceLoader.java) [System.err] [System.err] at com.apple.mrj.JManager.JMAppletViewer_OLD.doLoadCode(JMAppletViewerOld.java) [System.err] [System.err] at com.apple.mrj.JManager.JMAppletViewer_OLD.setState(JMAppletViewerOld.java) [System.err] [System.err] at com.apple.mrj.JManager.JMViewerEvent.post(JMAppletViewerOld.java) [System.err] [System.err] at com.apple.mrj.JManager.AVDispatcherThread.run(JMAppletViewerOld.java) [System.err] [end of document] Perhaps someone with better programming skills than me can make sense of this?
After encountering a Java null pointer alert at http://java.sun.com/ today, I have the same file content in System Folder:Preferences:MJRPluginAppletOutput as Kurt Weinschenker reported yesterday. (Mac G3/266 OS8.6 M18 build 2000092212 MJR 2.2.3) I also have encountered a trap by MacsBug several times: PowerPC unmapped memory exception at 150F35E0 nsPluginInstanceOwner::ShowStatus(const char*)+ 0004C When the cursor is over a link contained in either applet at java.sun.com, the URL is displayed in the browser window's status bar. However, when the cursor is moved out of the applet pane, the applet nevertheless continues to send the URL to the status bar. This is more amusing in SUG applet in the left hand side of the document because the URL in the status bar changes as the applet continues to scroll different links. The applets panes improperly float to maintain a fixed position relative to the browser window instead of maintaining a fixed position on the document. However, the status error is only apparent when the applets are in their "correct" position relative to the document.
Really marking minus per Ed Burns's comment. Nominating for RTM
Keywords: rtm
Whiteboard: [dogfood-][nsbeta3+-{PDTP1} → [dogfood-][nsbeta3-]{PDTP1}
Tested this bug with different machine: PM 9500/Newer G3-250 upgrade, Mac OS 9.04, MRJ 2.2.2 I think, 2000092804-M18 build. No crash on this machine, nor any of the funny null point exception stuff. I'll try to test this again on an iMac DV at home, but expect the same results. This bug appears to be rapidly turning into an applet draw/redraw issue. Having said that, let me say this. Bug 7366 doesn't exactly have an intuitive title, if indeed that's where Bugzilla's keeping track of the applet draw/redraw issue. Hopefully, we won't see crashes on this site again.
Okey-dokey. Tested on iMac DV at home. Did not get crash first time I visited http://java.sun.com/ in the session. I *did* get the Null Pointer exception and logfile. Also got the applet redraw problem -- the applet was redrawing *in the uppper Mozilla toolbar*, when I scrolled around by grabbing the slider bar on the right side. But no crash. Went to bugzilla. Visted a couple pages, bounced back to the Sun site, and boom! Crashed! MacsBug stdlog looks pretty much the same as the one from July, and I was using MRJ 2.2.3. Oh well...
Adding release note. "The Mac version will crash when visiting java-enabled web sites."
Keywords: relnote3
*** Bug 50830 has been marked as a duplicate of this bug. ***
*** Bug 32529 has been marked as a duplicate of this bug. ***
*** Bug 48605 has been marked as a duplicate of this bug. ***
*** Bug 37841 has been marked as a duplicate of this bug. ***
This worksforme with the 2000-10-09-17 M18 mozilla-mac-M18.sea.bin build, but not with the 2000-10-09-10-MN6 MacNetscapeInstaller.sea.bin build.
Mozilla does not crash, only the commercial builds crash when testing java applets. beard found that removing QFA.shlb from the commercial build allows testing to be done on OJI without crashing. http://junruh.mcom.com/oji.html
beard - what is your consensus on this bug? Do we need this file? Why didn't it crash on your system? Do you have this file installed?
Yes, I can confirm this crash. There is a real interaction between MRJ and QFA (TalkBack) that we need to get to the bottom of.
Reassigning to Shiva, to track TalkBack problems.
Assignee: edburns → namachi
Status: ASSIGNED → NEW
With Todays(10/10) build. - Installed Netscape 6 on Mac OS 9 - No problem in running. - Loaded URL www.javasoft.com - Netscape 6 crashed and Fullsoft DLL crashed. Took out Talkback Binaries. - Launched the app - Loaded URL www.javasoft.com - No Crash - Exited from Netscape 6 - Crashed on Exit. With Netscape 6 Beta 3 build - Installed Netscape 6 on Mac OS 9 - No problem in running - Loaded URL www.javasoft.com - Crashed Netscape 6 but Talkback picked the crash and Launched the Dialog to send the crash information. This crash scenario seems to be similiar to Windows 98 and Windows ME crash.
Mac commerical branch 101008 build. Start with a clean system, and do not install talkback. Now I have no problem visiting sites with applets. I am running MRJ 2.2.2 with the file MRJ Symantec JITC in place. The solution seems to be - don't install talkback if you want to visit java enabled sites. Here are some sites to try. http://junruh.mcom.com/oji.html
Thanks to everyone for narrowing this down. This is not good! Shiva - I'm going to mark this "rtm need info" because I think we need to figure this out for rtm.
Summary: crash when going to java.sun.com → crash when going to java.sun.com when Talkback is installed
Whiteboard: [dogfood-][nsbeta3-]{PDTP1} → [dogfood-][nsbeta3-]{PDTP1}[rtm need info]
Keywords: mostfreq
This is a duplicate of bugscape bug 2857. I leave it to the mac engineers which one gets closed and which stays open. http://bugscape.netscape.com/show_bug.cgi?id=2857
resolve fixed since the duplicate bugscape bug (http://bugscape.netscape.com/show_bug.cgi?id=2857) is fixed on the trunk. rtm- just to get it off the rtm radar.
Status: NEW → RESOLVED
Closed: 24 years ago
OS: All
Resolution: --- → FIXED
Verified fixed on trunk build 101308. Adding vbranch keyword.
Keywords: vbranch
Still not fixed on the branch 101608 build.
Right, it's not fixed in the branch builds because the fix hasn't been checked in it - see http://bugscape.netscape.com/show_bug.cgi?id=2857 . Fix was checked into the trunk.
Verified fixed on branch and trunk 10/17 Mac builds.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: