Closed Bug 57135 Opened 24 years ago Closed 24 years ago

Browser crashes on page http://www.defense-data.com

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
DEC
OpenVMS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jakobus, Assigned: colin)

References

(
URL
)

Details

(Keywords: crash)

Attachments

(2 files)

output of nm libjavaplugin_oji.so
203.18 KB, text/plain
Details
patch
1.29 KB, patch
Details | Diff | Splinter Review 
The URL: http://www.defense-data.com crashes with the report:
Document http://www.mozilla.org/ loaded successfully
->>>>>>>>>>>>>> Write Clipboard to memory
Document http://www.defense-data.com/ loaded successfully
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=000000000200048E, PC=00000000011E4C84, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 DECW$XTLIBSHRR5                            0 000000000003EC84 00000000011E4C84
 LIBGTKXTBIN  GTKXTBIN  gtk_xtbin_realize
                                        28959 0000000000000A18 0000000001E1CA18
I can confirm this bug with 2000101608 on Win2k.
Without Java the page works fine but with Java my mouse pointer is flickering
and after a short while my mouse pointer is away and seconds later Mozilla seems
to hang.

over to plugins, could be OJI though
Assignee: asa → av
Severity: normal → critical
Component: Browser-General → Plug-ins
Keywords: crash
QA Contact: doronr → shrir
This works fine on WinNT 4, NS6 release build id 2000101608.

Over to George, likely an OJI problem.
Assignee: av → drapeau
URL: http://www.defense-data.com
Status: UNCONFIRMED → NEW
Component: Plug-ins → OJI
Ever confirmed: true
It works for me with commercial build on Solaris with JRE 1.3.0_01.  Also works
for me on NS6 PR 3 on Windows 2000.

How the heck did you get a Java VM on Open VMS?   I didn't know that there was
an OJI-compliant JVM available for recent Mozilla builds.

I also am sorry to say that I'm not familiar enough with VMS to understand the
stack trace included with the bug report.  It looks as if the browser crashed
somewhere in GTK, not in Java or the OJI module.  Can you put more information
about the crash in here, please?  Do you have a JVM associated with your
browser?  Can you successfully go to http://java.sun.com/ (which also has
applets on it) and view the Industry News scrolling applet on that page?

Wow, man: this is interesting.


The reporter does not talk about java.
I have this problem with the page and installed java.
I tried this page without java and I have a crash.
I used aa trunk build.

I try this page later with a new trunk build (report after the download)
o.k. i have load the page with the a new trunk build.
Now I´m on Windows 98.
Open the page http://www.defense-data.com
After finish loading open one of the "Lead Articles".
I get this Error-Message :

java.lang.StringIndexOutOfBoundsException: String index out of range: -342
	at java.lang.String.substring(Unknown Source)
	at PopupMenu.loadMenu(PopupMenu.java:307)
	at PopupMenu.loadData(PopupMenu.java:298)
	at PopupMenu.init(PopupMenu.java:132)
	at sun.applet.AppletPanel.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I have no crash on this system but I try this on the win2k system, where mozilla 
hang.

This URL now crash not my the new Mozilla trunk build at my win2k system.
But I get this Java error message at the linked page.


The Java error is not a Mozilla bug, nor does it appear to be a J2SE (Java 2,
Standard Edition) bug.  It looks like a bug in the applet itself; the applet
developer should look at this behavior and see what's going wrong in the applet.

Looks like there's no bug here, unless the original bug reporter can produce
some more data.

George, are you going to mark this INVALID?
I checked the system and installed the latest patches for: OpenVMS V7.2-1 next I
installed the JAVA 2 SDK v 1.2.2-1 with the Virtual Machine 1.2.2-Beta2, but the
system still crashes.

$ java -version
java version "1.2.2-beta2"
Fast VM (build J2SDK.v.1.2.2:08/23/2000-10:42, native threads, jit_122)
$
$
$ show symbol mozilla
  MOZILLA == "@SYS$COMMON:[MOZILLA]MOZILLA"
$
$
$ mozilla
Starting mozilla-bin...
Setting content window
*** Pulling out the charset
Loading page specified via openDialog
in SetSecurityButton
Document http://www.mozilla.org/ loaded successfully
->>>>>>>>>>>>>> Write Clipboard to memory
Document http://www.defense-data.com/ loaded successfully
X Toolkit Error: Couldn't find per display information
%CXXL-F-TERMINATE, terminate() or unexpected() called
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 MOZILLA-BIN                                0 00000000000335DC 00000000000435DC
 MOZILLA-BIN                                0 000000000003568C 000000000004568C
----- above condition handler called with exception 03AB8204:
%DWT-F-NOMSG, Message number 03AB8204
----- end of exception message
                                            0 FFFFFFFF80083C3C FFFFFFFF80083C3C
 DECW$XTLIBSHRR5                            0 000000000003E2D8 00000000011F42D8
 DECW$XTLIBSHRR5                            0 000000000003DEF0 00000000011F3EF0
 DECW$XTLIBSHRR5                            0 000000000003E108 00000000011F4108
 DECW$XTLIBSHRR5                            0 000000000003D104 00000000011F3104
 DECW$XTLIBSHRR5                            0 000000000003ECBC 00000000011F4CBC
 LIBGTKXTBIN  GTKXTBIN  gtk_xtbin_realize
                                        28959 0000000000000A18 0000000001E3CA18
 LIBGTK  GTKSIGNAL  gtk_signal_real_emit
                                        13215 0000000000002960 0000000001732A90
 LIBGTK  GTKSIGNAL  gtk_signal_emit     12327 0000000000000B20 0000000001730C50
 LIBGTK  GTKWIDGET  gtk_widget_realize  24920 0000000000003C0C 000000000176EF2C
 LIBGTK  GTKWIDGET  gtk_widget_map      24859 0000000000003878 000000000176EB98
 LIBGTK  GTKSIGNAL  gtk_signal_real_emit
                                        13215 0000000000002960 0000000001732A90
 LIBGTK  GTKSIGNAL  gtk_signal_emit     12327 0000000000000B20 0000000001730C50
 LIBGKPLUGIN  NS4XPLUGININSTANCE  SetWindow
                                        79368 0000000000001564 0000000001DBD924
 LIBGKPLUGIN  NSPLUGINHOSTIMPL  InstantiateEmbededPlugin
                                        73415 000000000000B0A8 0000000001DC9798
 LIBGKLAYOUT  NSOBJECTFRAME  InstantiatePlugin
                                        66409 00000000000050D8 0000000002617CA8
 LIBGKLAYOUT  NSOBJECTFRAME  Reflow     66229 00000000000042A8 0000000002616E78
 LIBGKLAYOUT  NSLINELAYOUT  ReflowFrame
                                        41839 0000000000001A30 000000000260EE70
 LIBGKLAYOUT  NSINLINEFRAME  ReflowInlineFrame
                                        36642 00000000000016A0 0000000002609AD0

cut, the full list doesn't fit in this window.

The page: http://java.sun.com/ crashes just as the reported URL.

I can't mark this bug as INVALID just yet.  There's enough data here to suggest
that it's a real problem.  *My* problem?  I don't know enough about OpenVMS!
(nor do I have a machine running OpenVMS)
Here's what I'm thinking, though, based on the last stack trace that Theo posted
(thank you, Theo): it's looking to me as if the Java Plug-In being used is a 4.X
style plug-in, not an OJI plug-in.  Ed, check out the stack trace and see if you
agree with me.

Continuing, it looks as if what's happening is that the browser realizes it
needs a plugin, is finding some sort of plugin that claims it can handle the
MIME type for Java, and the browser is trying to hand over a parent window to
the plugin instance.  If this is the case, it *could* be that the browser is
handing over a structure when a simple XID is expected, or vice versa.  In other
words, maybe this is the same bug we saw last week on Linux, wherein a pavlov
fix ended up breaking compatibility with 4.x-style plugins?  (see bug 57046 for
details)  One way to verify this is to create two different builds of Mozilla:
one from, say, today, and another from, say October 10 or a bit earlier.  One of
them should work, the other should crash.  If so, then I predict that this is
the cause.

Unless you have a libjavaplugin_oji.so in your mozilla/dist/bin/plugins
directory, and it has symbols that very closely match those found in this
attachment <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=18099>, we
can't help you.  If neither of these conditions are met, and you still want
help, you need to tell us exactly who supplied your java plugin.

Marking Invalid.  Please reopen if you can give us the required information.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
I've found in the release notes
http://www.openvms.compaq.com/openvms/products/ips/mozilla_relnotes.html#notes

Java Support in Mozilla
Q: Why is there no Java support in Mozilla for OpenVMS?
A: Mozilla implements Java using OJI (Open JVM Integration). OJI is part of Java
Version 1.3, but V1.3 is not yet available on all platforms, including OpenVMS.
As soon as Java Version 1.3 is available on OpenVMS, it will be supported in
Mozilla.

Advantages of using OJI are:
    Multiple Java Virtual Machines (JVMs) can be supported
    Upgrading the JVM used by Mozilla is very easy

With previous browsers, you were bound to the JVM that had been embedded in the
browser code.

For more information, see http://www.mozilla.org/oji/

I'm reopening this bug and will assign to myself (I'm the OpenVMS Mozilla
maintainer). I'll explain why once I've re-assigned.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
OpenVMS doesn't have Java 1.3_01 or whatever release is required for a working
OJI. We will have, but we don't yet. So I don't expect this to work. But I
don't expect it to crash either. Problem is, I'm not sure why its crashing and
I'm going to need some help in tracking this one down. I'll attach a full trace
(I've removed the line numbers because they don't correspond to reality).

If I disable Java in the prefs it doesn't crash, but with Java enabled (which is
the default), it crashes. Surely there's a more user friendly way of saying
"java not supported"!!

Colin.
Assignee: drapeau → colin
Status: REOPENED → NEW
Here's the full trace from the crash. Hopefully this will mean something to 
someone, could like I said, I need a hint to get me started if I'm going to be 
able to fix this one.

  image    module    routine             
 LIBGTKXTBIN  GTKXTBIN  gtk_xtbin_realize
 LIBGTK  GTKSIGNAL  gtk_signal_real_emit
 LIBGTK  GTKSIGNAL  gtk_signal_emit     
 LIBGTK  GTKWIDGET  gtk_widget_realize  
 LIBGTK  GTKWIDGET  gtk_widget_map      
 LIBGTK  GTKSIGNAL  gtk_signal_real_emit
 LIBGTK  GTKSIGNAL  gtk_signal_emit     
 LIBGKPLUGIN  NS4XPLUGININSTANCE  SetWindow
 LIBGKPLUGIN  NSPLUGINHOSTIMPL  InstantiateEmbededPlugin
 LIBGKLAYOUT  NSOBJECTFRAME  InstantiatePlugin
 LIBGKLAYOUT  NSOBJECTFRAME  Reflow     
 LIBGKLAYOUT  NSLINELAYOUT  ReflowFrame
 LIBGKLAYOUT  NSBLOCKFRAME  ReflowInlineFrame
 LIBGKLAYOUT  NSBLOCKFRAME  DoReflowInlineFrames
 LIBGKLAYOUT  NSBLOCKFRAME  DoReflowInlineFramesAuto
 LIBGKLAYOUT  NSBLOCKFRAME  ReflowInlineFrames
 LIBGKLAYOUT  NSBLOCKFRAME  ReflowLine  
 LIBGKLAYOUT  NSBLOCKFRAME  ReflowDirtyLines
 LIBGKLAYOUT  NSBLOCKFRAME  Reflow      
 LIBGKLAYOUT  NSBLOCKREFLOWCONTEXT  DoReflowBlock
 LIBGKLAYOUT  NSBLOCKREFLOWCONTEXT  ReflowBlock
 LIBGKLAYOUT  NSBLOCKFRAME  ReflowBlockFrame
 LIBGKLAYOUT  NSBLOCKFRAME  ReflowLine  
 LIBGKLAYOUT  NSBLOCKFRAME  ReflowDirtyLines
 LIBGKLAYOUT  NSBLOCKFRAME  Reflow      
 LIBGKLAYOUT  NSCONTAINERFRAME  ReflowChild
 LIBGKLAYOUT  NSHTMLFRAME  Reflow       
 LIBGKLAYOUT  NSBOXTOBLOCKADAPTOR  Reflow
 LIBGKLAYOUT  NSBOXTOBLOCKADAPTOR  DoLayout
 LIBGKLAYOUT  NSBOX  Layout             
 LIBGKLAYOUT  NSSCROLLBOXFRAME  DoLayout
 LIBGKLAYOUT  NSBOX  Layout             
 LIBGKLAYOUT  NSCONTAINERBOX  LayoutChildAt
 LIBGKLAYOUT  NSGFXSCROLLFRAME  Layout  
 LIBGKLAYOUT  NSGFXSCROLLFRAME  DoLayout
 LIBGKLAYOUT  NSBOX  Layout             
 LIBGKLAYOUT  NSBOXFRAME  Reflow        
 LIBGKLAYOUT  NSGFXSCROLLFRAME  Reflow  
 LIBGKLAYOUT  NSCONTAINERFRAME  ReflowChild
 LIBGKLAYOUT  NSVIEWPORTFRAME  Reflow   
 LIBGKLAYOUT  NSHTMLREFLOWCOMMAND  Dispatch
 LIBGKLAYOUT  NSPRESSHELL  ProcessReflowCommands
 LIBGKLAYOUT  NSPRESSHELL  HandleEvent  
 LIBXPCOM  PLEVENT  PL_HandleEvent      
 LIBXPCOM  PLEVENT  PL_ProcessPendingEvents
 LIBXPCOM  NSEVENTQUEUE  ProcessPendingEvents
 LIBWIDGET_GTK  NSAPPSHELL  our_gdk_io_invoke
 LIBGLIB  GMAIN  g_main_dispatch        
 LIBGLIB  GMAIN  g_main_iterate         
 LIBGLIB  GMAIN  g_main_run             
 LIBGTK  GTKMAIN  gtk_main              
 LIBWIDGET_GTK  NSAPPSHELL  Run         
 MOZILLA-BIN  NSAPPRUNNER  main1        
 MOZILLA-BIN  NSAPPRUNNER  main         
 MOZILLA-BIN  NSAPPRUNNER  __MAIN           
 MOZILLA-BIN
Status: NEW → ASSIGNED
Ed, I am still seeing this problem with OpenVMS (in a trunk build of about
a week ago and my M0.6 build). I have some debug output that may be relevant
and it has your name all over it!

InstantiateEmbededPlugin for application/x-java-vm
Inside nsPluginHostImpl::FindStoppedPluginForURL...
dlsym: looking for NSGetFactory in /dka0/work/m06dbg/plugins/libnullplugin.so
dlsym: failed to find NSGetFactory in /dka0/work/m06dbg/plugins/libnullplugin.so
debug: edburns ns4xPlugin::CreatePlugin
debug: edburns ns4xPlugin::CreatePlugin: cleared callbacks
dlsym: looking for NP_Shutdown in /dka0/work/m06dbg/plugins/libnullplugin.so
dlsym: looking for NP_Initialize in /dka0/work/m06dbg/plugins/libnullplugin.so
debug: edburns: ns4xPlugin::CreatePlugin: callbacks->newstream: 28EA7A0
Inside ns4xPluginInstance::Start(void)...
Inside ns4xPluginInstance::SetWindow(4D78E68)...
About to create new ws_info...
About to create new xtbin of 400 X 100 from 5500018...
About to show xtbin(4D6C208)...

Next is the access violation.

Does this mean anything to you? I don't have a Java plugin. I think its trying
to use the null plugin since that claims to handle *, right? But I never get
the "do you want to download the plugin" window pop up.

Any info you can provide would be very much appreciated.

Feel free to assign the bug back to me. I'm just looking for input,
not a fix!

Thanks, Colin.
Assignee: colin → edburns
Status: ASSIGNED → NEW
Adding myself as a CC
I found the problem. Now I just need to figure out how to fix it!
Assignee: edburns → colin
Status: NEW → ASSIGNED
Component: OJI → Plug-ins
The problem is caused by the call to XtRegisterDrawable at
http://lxr.mozilla.org/seamonkey/source/widget/src/gtkxtbin/gtkxtbin.c#338

XtRegisterDrawable and XtUnregisterDrawable were new in X11R6, and OpenVMS
only has X11R5. We have code in our "porting layer" which we thought was
doing the R5 equivalent, but clearly it wasn't.

What is the R5 equivalent in this case? Other places in Mozilla where R6
specific code is used uses an #ifdef so that its not compiled on non-R6
platforms. Is that what we should be doing here?

Adding blizzard to the cc list in case he has any ideas for R5 equivalents.
Attached patch patch — — Splinter Review 

    
    

    
  
Chris,

Here's a patch to make this code work on pre-R6 systems. Please check in.

Thanks,
Colin.

    
    

    
  
r=pavlov

    
    

    
  
sr=blizzard

    
    

    
  
Looks ok to me, but are we sure that the mozilla supported compiler and 
preprocessor supports this >= operator on all platforms?

    
    

    
  
Every C preprocessor I know of handles all the usual C operators in #if.

Nit: how about a space after the >=, just as there is one before it?

/be

    
    

    
  
Space added after >= (twice).

I'll check in once the tree opens.

    
    

    
  
Checked in. gtkxtbin.c rev 1.6.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
Theo, can you please verify since I do not have the required OS.
QA Contact: shrir → jakobus

    
    

    
  
It's ok now using Mozilla 0.7 for OpenVMS which has build ID: 2001010817

    
  
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: