Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: GetDiskFragment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GetDiskFragment

On 08/14/2001 18:47, "George Warner" <email@hidden> wrote:

>> I have a cryptic CFM error message:
>> Error -2819, Error string "<IP Module Carbon Debug><IP Module Carbon
>> Debug><DEFANGED_Apple;Carbon;Networking><>"
>
> This means a closure rooted in "IP Module Carbon Debug" was being prepared,
> and while processing "IP Module Carbon Debug" a problem was noticed that was
> related to "DEFANGED_Apple;Carbon;Networking". A more understandable
> example might be -2804, where a library is missing. In this case the 2nd
> fragment is the one needing the library and the 3rd fragment is the library
> that is missing. The symbol name is only present for -2807, a missing
> imported symbol.

Well I don't get the "defanged" and have no idea where that came from (are
you running some arcane Apple only build of Mac OS X George?)

After a rather intensive hour or so spent analysing the bug with Cary
Farrier I think I'm in the position to shed a little more light on the
problem.

The problem manifests itself (on Mac OS X only) as a -2819 error the first
time (*) the OpenPlay shared library calls GetDiskFragment to load the
IPCarbonDebugModule module.

All four layers of the OpenPlay "layer cake" (NSP Test App, NetSprocketLib,
OpenPlayLib, IPModule) use staticly linked MSL libraries. Only the module
links in the C++ library. (A version built with dynamic MSL libraries worked
fine for me, but was failing for other people). All the exported symbols
within the libraries should be there. Both the OpenPlayLib and IPModule wrap
MSL's __initialize and __terminate in their own functions (this is done to
get the library's FSSpec and to shutdown OT correctly and other reasons).

I've checked most of the global and static variables in the OpenPlayLib to
see if the variables are being inited correctly and so far they are. (I've
not checked all the globals but I have a hunch this isn't the problem - esp.
as there doesn't seem to be globals used to store dynamically allocated
resources).

I've put debugstr() equivalent code into the very first line of the
OpenPlayLib (i.e. In the first line of __myinitialize) to try and see what
is going on. The error is occuring before even the first line of code in the
module is executed. So somewhere between GetDiskFragment() and
__myinitialize() CFM is choking (error -2819 kind of gave that away).

I've produced a dummy test application that reproduces the OpenPlay layer
cake structure. This dummy code mirrors as much of it as a can, the lowest
layer plugin/module uses a couple of OpenTransport (so the
Apple;Carbon;Networking fragment is linked in with CarbonLib). All MSL
libraries are the same ones used inside of OpenPlay. Oddly - this dummy
application works fine.

One difference between the test app and the openplay app is that the test
app loads 2 OpenTransport symbols from CarbonLib while OpenPlay loads 20-30
symbols. Perhaps the Mac OS X CFM implementation can't find some of those
extra symbols???

Today I'm leaning back to the "it's a Mac OS X CFM bug" stance...

Jon.

References: 
 >Re: GetDiskFragment (From: George Warner <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.