Re: App Crashes when ZeroLink isn't Used
Re: App Crashes when ZeroLink isn't Used
- Subject: Re: App Crashes when ZeroLink isn't Used
- From: "Nate Slater" <email@hidden>
- Date: Thu, 14 Sep 2006 17:11:47 -0700
OK here goes:
First I used otool to inspect my non-ZeroLink binary as will as my
libid3 installed in /sw/lib:
The non-ZeroLink binary:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 11.0.0)
time stamp 1153857107 Tue Jul 25 12:51:47 2006
/System/Library/Frameworks/CoreAudio.framework/Versions/A/
CoreAudio (compatibility version 1.0.0, current version 1.0.0)
time stamp 1153857107 Tue Jul 25 12:51:47 2006
/System/Library/Frameworks/AudioUnit.framework/Versions/A/
AudioUnit (compatibility version 1.0.0, current version 1.0.0)
time stamp 1153857107 Tue Jul 25 12:51:47 2006
@executable_path/../Frameworks/libid3.dylib (compatibility
version 4.0.0, current version 4.0.0)
time stamp 1082622615 Thu Apr 22 01:30:15 2004
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.3)
time stamp 1153857107 Tue Jul 25 12:51:47 2006
The libid3.dylib in /sw/lib:
/sw/lib/libid3.3.0.0.dylib:
/sw/lib/libid3.3.dylib (compatibility version 4.0.0, current
version 4.0.0)
time stamp 1157053352 Thu Aug 31 12:42:32 2006
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.3)
time stamp 1152127762 Wed Jul 5 12:29:22 2006
/sw/lib/libiconv.2.dylib (compatibility version 6.0.0,
current version 6.0.0)
time stamp 1139276425 Mon Feb 6 17:40:25 2006
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.6)
time stamp 1152127762 Wed Jul 5 12:29:22 2006
So by this I can deduce that the non-ZeroLink binary is using a copy
of libid3 compiled in April of 2004 and the libid3.dylib I have
installed in /sw/lib was compiled in August of 2006. Therefore my
non-ZeroLink binary is using the copy of libid3 that came in the
project folder--good.
Using otool to find info about libid3 on my ZeroLink binary gives:
@executable_path/../Frameworks/libid3.dylib (compatibility
version 4.0.0, current version 4.0.0)
time stamp 1082622615 Thu Apr 22 01:30:15 2004
Also using Activity Viewer, inspecting the development build process,
and sampling open files and ports gives:
/Users/peter/Documents/Development/AudioSlicer/Peter's Revisions/
AudioSlicer-Sources-1.0.3/build/Development/AudioSlicer.app/Contents/
Frameworks/libid3.dylib
Where the above is the only entry in the list of open files and ports
that includes libid3.
The otool report on libid3.dylib in the above location is:
@executable_path/../Frameworks/libid3.dylib (compatibility
version 4.0.0, current version 4.0.0)
time stamp 1082622615 Thu Apr 22 01:30:15 2004
/usr/lib/libiconv.2.dylib (compatibility version 5.0.0,
current version 5.0.0)
time stamp 1080645154 Tue Mar 30 03:12:34 2004
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 71.0.0)
time stamp 1078524309 Fri Mar 5 14:05:09 2004
So it appears to me that both the ZeroLink and the non-ZeroLink are
using the same libid3 library, and that library is the one that came
in the project folder along with its header files. A binary compare
of the libid3.dylib files in the Frameworks folders of the ZeroLink
and non-ZeroLink builds shows no difference.
I guess my idea of mismatched libraries is out.
j o a r, do you have any other ideas as to what could cause an
EXC_BAD_ACCESS exception?
Peter
On Sep 14, 2006, at 12:32 PM, j o a r joar-at-joar.com |Apple Xcode
Users List| wrote:
On 14 sep 2006, at 21.21, Nate Slater wrote:
That should be easy to verify, don't you agree?
Urm... Yes I think it should be easy to verify except I haven't
the slightest idea how. Is there a tool that will show me which
library a running binary is using? I tried renaming libid3.dylib
to libid3.dylib.old in /sw/lib, cleaned all, and then rebuilt with
and without ZeroLink with the same results as I described before.
The command line utilities "otool" and "nm" can very likely help
you with your investigations. Check your binary using "otool -L" as
a starting point.
...but, when I said that it would be easy to verify, I just thought
you should try what you already did - remove / rename any other
copies of the library in question.
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden