Has anyone noticed that when using iOS simulator for extended periods of time or during launch of Apps that there is a disturbance in the performance of osx and the magic mouse?
The other day a darkened view loading across the osx screen and it said I needed to restart.
These are the logs for my app from the console - there are stacks more though:
0x954c7000 - 0x954cafe7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x95598000 - 0x9573fff7 libSystem.B.dylib 125.2.1 (compatibility 1.0.0) <62291026-D016-705D-DC1E-FC2B09D47DE5> /usr/lib/libSystem.B.dylib
0x96675000 - 0x96695fe7 libresolv.9.dylib 41.0.0 (compatibility 1.0.0) <751955F3-21FB-A03A-4E92-1F3D4EFB8C5B> /usr/lib/libresolv.9.dylib
0x96e34000 - 0x96ea3ff7 libvMisc.dylib 268.0.1 (compatibility 1.0.0) <5C3D7DA5-29EB-A745-E32B-26DBF547D532> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x98210000 - 0x982edff7 com.apple.vImage 4.0 (4.0) <64597E4B-F144-DBB3-F428-0EC3D9A1219E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x991e6000 - 0x991f2ff7 libkxld.dylib ??? (???) <F0E915AD-6B32-0D5E-D24B-B188447FDD23> /usr/lib/system/libkxld.dylib
0xffff0000 - 0xffff1fff libSystem.B.dylib ??? (???) <62291026-D016-705D-DC1E-FC2B09D47DE5> /usr/lib/libSystem.B.dylib
This isn't an Xcode/simulator issue. THe "dark view" thing was a kernel panic, indicating something went horribly wrong in the OS.
This should be on superuser.
And they'd need to know more info:
system configuration? Model? Memory? Hard Drive?
anything interesting in the console log?
Related
I'm working on a Swift project which links agains libSDL2. I had to patch a few things in that library to fit my needs and thus it currently lives in the same directory as my project and is compiled and linked from there. When I run my application, I get a bunch of warning form:
objc[13894]: Class SDLApplication is implemented in both
/opt/local/lib/libSDL2-2.0.0.dylib (0x10f116228) and
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2-2.0.0.dylib
(0x10ef6d240). One of the two will be used. Which one is undefined.
I do have a globally-installed instance of libSDL2 under /opt/local, installed via MacPorts and used by some applications also installed via MacPorts, so I can't remove that.
I tried looking at the libraries that the compiled binary links agains but could not find a reference to the instance installed in /opt/local.
$ otool -L .build/debug/TestLines
.build/debug/TestLines:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib (compatibility version 3.0.0, current version 3.3.0)
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2-2.0.0.dylib (compatibility version 17.0.0, current version 17.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1770.255.0)
#rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1200.2.41)
<...>
How can I debug this issue?
In the end it was easy to figure out. It turned out that the libSDL2_image-2.0.0.dylib was linked against the instance of libSDL2 from /opt/local. To figure this out I simply had to follow the libraries linked by my binary and inspect those instead of just the main binary:
$ otool -L Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib
Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib:
/Users/<my-project>/Libraries/SDL-install/lib/libSDL2_image-2.0.0.dylib (compatibility version 3.0.0, current version 3.3.0)
/opt/local/lib/libSDL2-2.0.0.dylib
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 52.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1355.22.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1069.24.0)
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
(The root cause in this instance was that I had to pass --sdl-prefix in addition to --prefix to the ./configure script from SDL_image)
I want to know what compiler version was used exactly. In my example I tried the following:
otool -L TestFramework
TestFramework:
#rpath/TestFramework.framework/Versions/A/TestFramework (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1675.129.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
#rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.8.25)
It looks like 1103.8.25 could be useful, but when I look the version up (on Wikipedia) it doesn't help, as the versions there look like this:
5.3 (swiftlang-1200.0.29.2 clang-1200.0.30.1),
5.3.1 (swiftlang-1200.0.41 clang-1200.0.32.8),
5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
etc..
It looks like that my 1103.8.25 might hint to one of these:
5.2 (swiftlang-1103.0.32.1 clang-1103.0.32.29),
5.2.2 (swiftlang-1103.0.32.6 clang-1103.0.32.51),
5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53),
5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53),
5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)
, because of the 1103 but which one is it?
I am aware that I can check the .swiftinterface file if the binary has been compiled with ABI stability, but let's assume it hasn't been. How does Xcode do it?
Is there a list of libswiftCore.dylib versions somewhere that can be used for lookup?
I am using a third-party library,say: libABC.dylib
I want use the dylib in an open source application,and want to install into my iphone 4,with ios 6,without jailbroken.
On doing a
$ otool -L libABC.dylib
libABC.dylib:
libABC.dylib (compatibility version 1.0.0, current version 1.0.0)
libXYZ.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.5)
Now i want to ship the dylib, with my app , install into my iphone 4.
For that i have changed the dylib paths as
$ install_name_tool -id #executable_path/../Frameworks/libABC.dylib libABC.dylib
also,I added libABC.dylib to Frameworks under the project in Xcode.
This changes the inside dylib paths as
$ otool -L libABC.dylib
libABC.dylib:
#executable_path/../Frameworks/libABC.dylib (compatibility version
1.0.0, current version 1.0.0)
libXYZ.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.5)
The problem is:
libABC is loaded at app launch time,
i am unable to change this path, to a path relative to my mach-o binary
(inside my app bundle)
So my app is failing to load.
Dyld Error Message:
dyld: Library not loaded: /usr/local/lib/libABC.dylib
Referenced from:
....
Reason: image not found
Please suggest me some direction.
The third party library is only creating dylib, no static libs
I also tried setting XCode options to get dylib from "#executable_path" but
it didnt work.
and I don not load my dylib through code?
Please suggest. I am clueless here.
Advance Thanks :)
Unfortunately NO, you are out of luck, start looking for alternatives. You can't add custom/third party dylibs to an iOS project, iOS project only support addition of built-in dynamic libraries. Moreover any tries and success to add dylibs may cause you app rejected from apple.
Why? Have a look at this post for detailed discussion. specially the 2nd comment on marked answer.
Like you could read in #Adil Soomro's reference, third party frameworks are not supported because of security reasons. That's why you have to delete all the frameworks that appear inside the log when you try to build an app. Normally it should work if these Frameworks are not included. If the debugger will turn on while building you should press play till the app will be installed.
But keep looking what kind of frameworks you are using so you don't get rejected when the app will be reviewed.
Further more, a related error method can occure if you start an app on ios 5.1 or less and some of your frameworks are not supported on these os versions.
Hey, guys! I want to wrap the vlc, importing the vlc dylibs. But this simple iPhone App call those third-party dylibs failed at the beginning of loading without any prompts. I even try to make a 'hello world' xcode project, just add libvlc.2.dylib & libvlccore.0.dylib but not calling, without any 1 more code manually. After download it to the iPhone device(3.1.3), it splash and exit immediately, no info throw out. BTW, all the dylibs imported were put to the right dirs. It really make me confused! Could any body show me the solution, appreciated!
run otool on device:
root# otool -L test1
test1:
/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 678.51.0)
/System/Library/Frameworks/UIKit.framework/UIKit (compatibility version 1.0.0, current version 1000.0.0)
/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics (compatibility version 64.0.0, current version 359.16.0)
/System/Library/Frameworks/CoreData.framework/CoreData (compatibility version 1.0.0, current version 248.0.0)
#executable_path/PlugIns/libvlccore.0.dylib (compatibility version 1.0.0, current version 1.2.0)
#executable_path/PlugIns/libvlc.2.dylib (compatibility version 3.0.0, current version 3.2.0)
#executable_path/PlugIns/liblive555_plugin.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.2.1)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 478.52.0)
iPhone apps cannot link to any additional libraries except those that are on the iPhone already. You need to compile any external libraries into your binary (as a static library).
I'm running Xcode 3.2.3 with the iOS 4.0 SDK. I built my app with Base SDK = iphoneos4.0, Active SDK = iphoneos4.0, Deployment Target = 3.1.3, and Architecture = standard (arm6 arm7). Compiler = GCC 4.2. As I understand it, this is the correct way to build an app for both iOS 4 and 3.
The app runs fine on devices running iOS 4. But it crashes on startup when you try to run it on a device with iOS 3.1.3 (an iPod Touch 1G):
dyld: Symbol not found: __NSConcreteStackBlock
Referenced from: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
Expected in: /usr/lib/libSystem.B.dylib
It appears to be an issue with a fairly "low level" dynamically-linked library, BEFORE my main() function even gets called. I have even tried re-starting the device, etc., with no luck. Here's part of the the crash log:
Process: MyApp [60]
Path: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
Identifier: MyApp
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2010-07-22 17:16:17.942 -0400
OS Version: iPhone OS 3.1.3 (7E18)
Report Version: 104
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x00000001, 0xe7ffdefe
Crashed Thread: 0
Dyld Error Message:
Symbol not found: __NSConcreteStackBlock
Referenced from: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
Expected in: /usr/lib/libSystem.B.dylib
Dyld Version: 149
Binary Images:
0x1000 - 0x80fff +MyApp armv6 <d5f0ff6f233b4b034c222c16438c88d9> /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
0x2fe00000 - 0x2fe26fff dyld armv6 <544395a4b5546114b878d5131a84fd7f> /usr/lib/dyld
0x30410000 - 0x30536fff libSystem.B.dylib armv6 <0373fd64e915a17160732b29d343f95f> /usr/lib/libSystem.B.dylib
Thanks for any advice!
Ben Gottlieb pointed out yesterday that if you use blocks anywhere in your application, you'll see a crash similar to this on a pre-4.0 OS while building with the LLVM compiler. To work around this, you can specify the linker flag -weak-lSystem in your Xcode build settings.
Since most of these answers are specific to Xcode 3.x, just wanted to share what I did to fix this with Xcode 4.2.
Under your target in the "Build Phases" tab in the "Link Binary With Libraries" section I added "libSystem.dylib" and made it optional. This fixed the issue iOS 3.x devices while maintaining support for iOS 4.x and 5.0 devices.
If you happen to be using the cocos2d libraries, there is a cleaner way to do this, you should configure the cocos2d target's Deployment target to 3.0