Closed Bug 266785 Opened 20 years ago Closed 20 years ago

Crash if ipluginw.dll loaded in COMPONENTS therefore no Java (1.42)

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: mike.hitchcock, Assigned: darin.moz)

Details

Attachments

(1 file)

patch for build system
1.70 KB, patch
mkaply
: review+
mkaply
: approval1.8a5+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a5) Gecko/20041028
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a5) Gecko/20041028

If The Innotek Java file IPLUGINW.DLL which enables Java is loaded in the
components directory Mozilla fails to load & crashes with a SYS2070 error.
If the file is deleted, the browser loads but with no Java(in my case 1.42)
This error has only occured with this OS/2 build and and one previous build.
Before that the file would load and Java worked fine.

Reproducible: Always
Steps to Reproduce:
1.Extract new Mozilla_OS2.zip into working directory (E:\mozilla)
2.Copy Innotek IPLUGINW.DLL (2004/03/12) into e:\mozilla\compontents
3.Try to run Mozilla
Actual Results:  
Crashes with SYS2070
"System could not demand load application segment 
IPLUGINW->XPCOM._Z20ns_NewGenericModule2P12nsModuleInfoPP9nsIModule is in error
for more info HELP SYS127

Expected Results:  
Load browser with Java available
Yes, I see that here, too.

Together with the error message this tells me that ipluginw.dll is accessing the
method NS_NewGenericModule2(nsModuleInfo* info, nsIModule* *result) that until
recently was in xpcom.dll, but has now moved to xpcomcor.dll.

This should therefore be reported to Innotek. Until getting fixes at their end,
you have to stay with a version that works, like 1.7.3 or so.
Status: UNCONFIRMED → NEW
Component: Browser-General → Plug-ins
Ever confirmed: true
fixes->fixed

Not sure who from Innotek needs to know about it, CCing all of them. :-)
Darin, can you explain what happened here?

Thanks
It worked fine with 1.8a4
When CC'ing InnoTek please include /me, I'm the one doing iplugin, libc and gcc.
(btw. stauff@innotek.de doesn't exist.)

I've fixed the problem and we'll be putting up a new build of ipluginw.dll very
soon. The fix is to look for ns_NewGenericModule2() in both XPCOM.DLL and
XPCOMCOR.DLL.

This also uncovered a build error; this symbol should've been resolved
dynamically not statically by the loader like the error message indicates. We're
of course enabling that codepath now. (This means that if ns_NewGenericModule2()
is moved to yet another DLL ipluginw.dll will simply fail to instatiate itself.)

Achim or I will add a comment with the URL to the new ipluginw package when it's
ready.

Kind Regards,
 knut
I've tested the 2004-10-31 nigthly with npoji6.dll (IBM Java 1.3) and npj2.dll
(InnoTek Java 1.4.2_05). npj2.dll works fine. However, npoji6.dll doesn't, it
crashes on start (and exit if ipluginw.dll isn't present) with a SYS2070 because
nsOS2VACLegacy.cpp is in XPCOMCOR.DLL instead of XPCOM.DLL. This problem have
been posted on Bug #262218 too.
-> over to me
Assignee: general → darin
This patch takes care of xpcom/build/Makefile.in and xpcom/stub/Makefile.in,
but we may wish to get myk@mozilla.org or someone else to copy the CVS file for
nsOS2VACLegacy.cpp over to xpcom/stub.

BTW, why does the plugin need to use all of these private APIs?  There are
C-style exports for all of the frozen XPCOM APIs.  If the plugin uses only the
frozen symbols, then it will not have this problem.

It looks to me as if nsOS2VACLegacy.cpp exists to support a set of C++ methods
that should have either been compiled into the plugin or simply removed from
the plugin source.

If this is not an option, I understand.  I guess I don't really have a problem
continuing to support these APIs for OS/2 :-/
Attachment #164340 - Flags: review?(mkaply)
> I've fixed the problem and we'll be putting up a new build of ipluginw.dll very
> soon. The fix is to look for ns_NewGenericModule2() in both XPCOM.DLL and
> XPCOMCOR.DLL.

I strongly recommend that you do not code against XPCOMCOR.DLL.  It is a private
DLL that will likely be removed in the future.  Do not expect binaries that link
to XPCOMCOR.DLL to work with future versions of Mozilla.  (I.e., there are plans
to combine XPCOMCOR.DLL and many of the internal Mozilla libraries into some
common GECKO.DLL.)

Moreover, you should not expect that linking to private functions will be
supported in future versions of Mozilla.

The reason for bug 262218 was to make it very clear where the boundary lies
between frozen and unfrozen symbols.  If you only compile and link against the
contents of dist/sdk from a Mozilla build, then you are assured of binary
compatibility with future versions of Mozilla.  If you use headers from
dist/include or if you use libraries from dist/bin or dist/lib, then you are
risking future incompatibilities.  To be compatible with, for example, Mozilla
1.4 and later, you should compile and link against the dist/sdk from a build of
the Mozilla 1.4 source.  In that example your plugin would not necessarily be
compatible with Mozilla 1.3, so it is important to build your plugin against the
oldest version of Mozilla that you intend to work with.

I understand that in the past we have not done our job to inform developers of
these issues and requirements, so I completely understand that there may be some
code out there such as your plugin that may depend on private Mozilla APIs. 
That's why I said that I'm willing to continue to include nsOS2VACLegacy.cpp in
XPCOM.DLL, but I still wanted to encourage you to "do the right thing" :-)
I'd like to wait for comments from bird on ipluginw.dll.

He can go into more specifics.

Basically, we have to support the IBM Java which was compiled by VACPP and
linked against a VACPP XPCOM, which is why all this hackage is in here.
Action:

I will try implement functionality we're currently importing from XPCOM[COR].DLL
as Darin suggests.


History:

ipluginw, nsOS2VACLegacy.cpp and nsprpub/pr/src/md/os2/os2vaclegacy.s are all
instruments for making the IBM Java 1.3.x oji plugins work in a GCC based
browser. The plugins was built with VAC, and since GCC and VAC doesn't have much
in common C/C++ ABI wise some glue was needed. The ipluginw also glues the flash
5 and 7 scripting interfaces, and it works for the InnoTek Java plugins too.

The two sources listed above are needed because the bright guys doing the IBM
Java 1.3.x plugins have loadtime imports from NSPR4.DLL and XPCOM.DLL, and
missing exports on OS/2 causes nasty SYS2070 messages terminating the application.

The ipluginw was originally intended for being build as part of the OS/2 builds
and was written as just another XPCOM component. So, I based it on the XPCOM
component sample code and got a bunch XPCOM.DLL bindings. But then, for various
practical and legal reasons, IBM didn't want to build ipluginw and we had to
build it in a generic way so it would work with any GCC based 1.4 browser. And
that's how we got here.
Afraid I have to postpone this job because it's more work than I have time to do
right now. I'll look at again when you move NS_NewGenericModule2 interface the
next time. Somehow I don't expect the interface itself to be changed in an
incompatible way looking at the compatability features already present
(NS_MODULEINFO_VERSION, NS_NewGenericModule(),...).
Installed the new 20041104 IPLUGINW.DLL with Warpzilla 2004110412 build.
No longer crashes but Java build 1.4.2_04-b05 fails to work with it. When
encounters java - offers to download plugin
Tried the new 20041104 IPLUGINW.DLL with Warpzilla 2004110508 build.
No longer crashes AND Java build 1.4.2_04-b05 WORKS with it. 
Darin,

do we still need this patch since Innotek fixed IPLUGINW?
Mike, yes we do. It's fixing the problem with the
npoji6.dll-importing-from-XPCOM.DLL legacy. It's not a fix for the ipluginw
crash.  See my comment in #262218.
From Knut St.Osmunsen's comment #16, I suspect this may not be the bug that's
caused nightly builds (with Java 1.31 plugin) through much of November to have
failed, if ipluginw.dll is installed, with the following in popuplog.os2:
--------------------

11-20-2004  10:15:38  SYS2070  PID 003e  TID 0001  Slot 008b
G:\MOZILLA11-17-04\MOZILLA.EXE
NPOJI6->XPCOM.__dt__13nsCOMPtr_baseFv
127
------------------------------------------------------------

11-20-2004  10:17:52  SYS2070  PID 0044  TID 0001  Slot 008f
G:\MOZILLA11-17-04\MOZILLA.EXE
NPOJI6->XPCOM.__vft17nsGetServiceByCID15nsCOMPtr_helper
127
------------------------------------------------------------

11-20-2004  10:17:52  SYS2070  PID 0044  TID 0001  Slot 008f
G:\MOZILLA11-17-04\MOZILLA.EXE
NPOJI6->XPCOM.__dt__13nsCOMPtr_baseFv
127
---------------------
Current test was of Mozilla (Build ID:2004111708).  
Your suspicion is correct.
Comment on attachment 164340 [details] [diff] [review]
patch for build system

r=mkaply
a=mkaply for 1.8
Attachment #164340 - Flags: review?(mkaply)
Attachment #164340 - Flags: review+
Attachment #164340 - Flags: approval1.8a5+
this missed the boat for 1.8a5... i'll check it in once the tree opens for 1.8a6.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
(In reply to comment #21)
> Fix checked in to trunk.

mkaply: justdave hasn't moved nsOS2VACLegacy.cpp yet.  I don't the patch will
work until he has moved the file.  It would seem that this will break the OS/2
build until that file is moved, no?
I don't know who justdave is, but yes, it is currently broken. But it was easy
enough to just move the file from xpcom/build/ to xpcom/stub/ to continue building.
cvs move of xpcom/build/nsOS2VACLegacy.cpp to xpcom/stub/nsOS2VACLegacy.cpp has
been completed.  It exists at the new location ONLY on the trunk, if you require
its presence on any branches, you will need to re-branch the file.  If you no
longer require its presence at the old location, you will need to cvs remove it
from that location.
Peter, shouldn't xpcom/build/nsOS2VACLegacy.cpp be cvs removed from the trunk and the 1_8_Branch to clean the tree (and to prevent that someone think its usable)?
Yes, I have done that now. As this was an obvious oversight I didn't bother to ask for review.
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: