Closed Bug 36381 Opened 24 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: