I have some issues on the new Mac Mini 2014, when I'm running my application, I've got the crash, when the application uses some audio calls.
For example:
The issue is that we always receive nil input device.
And I went to settings on my Mac. I've seen the following:
No input devices found. Why???
And I see on my old Mac Mini 2012:
If I insert jack into line in, the issue is fixed. But it's some lifehack :)
Anyone else encountered this problem? How to resolve this issue?
Later model mac mini's have hardware to detect when a cable is inserted and use that to add or remove the audio input device. A lot of PCs have been doing this for awhile now. There is no workaround to this that I know of.
So the correct way to answer you is to say that you need to check return values and add proper handling in your code to deal with the case where no input device is present. For example, in your call to alcOpenDevice I can see that deviceName is nil. You should probably be testing for this condition rather than marching blindly along until you get a null reference exception.
Related
Some of us know that the framework multipeer conectivity is a problematic framework, which has some bugs. In my case it was not different, I walked realizing that sometimes when I try to connect with other devices I run into the following problems
1) I see the same duplicate devices more than 2 times.
2) Sometimes when I send an invitation to connect with another device,
the call does not reach it! (but most often arrives)
I believe this not to be a problem with my code, as who is responsible for opening the view to display the device list for us to connect is the MCBrowserViewController.
In my case, I am testing the exchange of information between a iphone4s and my simulator (iphone4s), I do not know if this is what might be giving the problem, what you guys think?
When you get desperate over a bug, you should eliminate the simulator, since it is added complication. However I have had reasonable success using it. And rebooting devices (both the host of the simulator and the real device) sometimes has helped with strange MPC behavior after hours of testing different versions of my MPC app. Finally, be sure to handle MPC data on the main queue as noted in the docs. Unless you post example code, you only get opinions.
I experience an unpleasant problem for which I can't really find a conclusive reason: if I reprogram my BLE112 module (BLEBee from Michael Kroll / seeedstudio), for some reason the settings (especially the UUID keys to peripherals) are not being updated.
This is very unpleasant since that almost makes it impossible to connect to the device via iOS / Xcode.
Any leads on how to solve this and what would cause this issue?
Note: I reprogram them using CC Debugger and BLEUpdate from Bluegiga. I'm sure the values are in fact being reprogrammed, but iOS seems to keep the old info at least for some time.
(iOS 8 / Xcode 6 beta)
Have you tried to reset the settings of your phone? This is a common problem with iOS. Once you connected to the e.g. original firmware of the BLEBee and change the services and characteristics, iOS will show you the cached ones. Try to initially turn off Bluetooth, kill you app, restart BT and start your app again.
If this does not help Reset the Settings of your Phone.
Hope this helps,
Michael.
This guy seems to have a similar problem, except mine doesn't work at all, not just on the first try. Today I installed xcode 4.2/ios simulator 5.0 hoping that would fix the problem, but it hasn't helped. The app has consistently run on actual devices, but all the developers who own Iphones are out of the office today and the company ipod is in use elsewhere.
I've tried closing both xcode and the ios simulator, changing between 5.0 and 4.3, changing between regular iphone and iphone retina, trying with simulator running first and trying with simulator closed first. It just sits there on the loading screen. As far as I know the simulator has never worked, I'm not the one who setup xcode or any of the devices (he doesnt work on Mondays and didn't know how to fix it on Friday anyway). Any help would be appreciated.
Turns out adding "localHosts" to ExternalHosts fixed the Simulator, but the simulator doesn't like the ajax call to our services site, so it still isn't working, but now at least we have an acceptable reason for it. (Devices work correctly, so it isn't that big of a deal) Hope this helps someone.
If anyone can think of a way for the simulator to work with the reference to external calls I'll transfer the answer to their answer :P.
Like Luke said in a comment to you: just use JSONP.
It's not the simulator's fault, that's just how browsers work. They don't allow cross-domain ajax requests. That's why there is a solution to this problem, namely JSONP. In essence, the response must be a regular JSON object that is enclosed in a function call, something like callback_function({json: 'object'}).
I know it's a bit weird but I have no code at all to put here, unless I copy all of it.
My project is crashing with no apparent reason. I've read this solution: iPhone application is crashing and not leaving behind a .crash log file
and I'm using Instrument for searching for leaks and other possibilities for those crashes.
Another strange thing is: even when I run my app with debug on XCode, it just stop to work on my IPad but it looks it is still running.
And the last and more strange thing: there's no crash log at all on my device. Before somebody ask, it is enable to record crash logs.
Does anybody have any idea for helping me?
Regards
I've had this happen to me before on various platforms. If its crashing on you, whether its an iPhone app, openGL / DirectX program, try these steps:
Have you tried to undo your last change and get to the point where it last worked?
Have you tried placing a print outputs to the terminal to see how far your program is executing? Start at the beginning and work your way into your program. This is especially useful when there is no crash log.
Also in particular to iPhone apps: Have you checked your xib's? Did you recently re-factor and change the name of a class maybe? You might need to re-link your nib to your classes. This on more than one occasion has caused apps of mine to crash with no error. Hope this helps.
I doubt you are still wondering about this, but my answer is that you were experiencing your app getting killed by the OS due to using too much memory. This will silently fail in the log in my experience when running on the device.
You will have to go into the Organizer to the device console and crash reports that get stored on the device to see the clues.
The reason your crash stopped when you got an iPad 2 is because the iPad 2 has twice the memory of the iPad 1 (which is dramatically under-stocked with RAM)
An update of my app has just been approved by Apple and users are now complaining the app does not launch anymore. It also happens to some new users.
I have absolutely no idea where the problem is nor can I reproduce the problem. I have tested the update on various devices (& simulator) before submitting the update: iPhone 2G running 3.1.3, iPod Touch 2G running 4.3 , iPhone 3G and iPhone 4 running 4.3.1. They ALL work as expected. The update has a few new features like random picking photos from user's photo library using AssetsLibrary framework, I have weak-linked the framework to support iOS 3 and the feature does not load until selected by the user so it should not be the problem. After all, the update has been tested and approved by Apple.
I have difficulty collecting crash information from users with the problem, but I know one of them uses iPhone 4 with iOS 4.3.2. A quick google search reveals that iOS 4.3.2 has problems launching third party apps, I suspect my problem has something to do with this but I can not confirm it. I am planning to downgrade my dev iPhone 4 to iOS 4.3.2 to test it.
Does anybody here experienced similar problem? My app's ranking has dropped significantly because of the negative reviews so I need to fix this as soon as possible.
Edit:
There should not be any watch dog problem, I tested the update on the above mentioned devices with and without Xcode/debugger.
Memory management. I can not reproduce the problem (I tried quite hard) so I can not confirm if it's EXC_BAD_ACCESS, I did check reference count and nil released objects (safely release) when applicable, I am absolutely not a pro in memory management so I take it seriously, I checked leaks and allocations with instruments, stress-tested and did memory warning simulations, no problem was found.
I have UIApplicationWillEnterForegroundNotification in -loadview, it's only available after iOS 4.0 so I check if it exists with & operator because I use it.
I do not persist data other than saving facebook connect token and expiry date (NSDate) in NSUserDefaults, since the problem also happens to new users so I think it's something else
We're going to need more info, unfortunately. But just off the top of my head:
Watch dog? What sorts of stuff are you loading when you launch your app? It may be that resources are constrained on the devices having this issue and you are doing work that should be done a separate thread, or otherwise delayed until after the app has launched.
EXC_BAD_ACCESS. There could be a race condition going on that is resulting in most people able to launch OK, but for some it just isn't working because of bad references. I know, you write good code and manage your references like a pro, but sometimes a non-obvious slip-up can creep in.
Are you safely instantiating some types of classes? An example that bit me once was with the MFMailComposeViewController class. Before instantiating you're suppose to call its static method canSendMail. If a user hasn't setup any mail accounts on their device (hard to figure there would be anyone that fits this scenario, but hey! found out after an update that there are quite a few!) then the app would crash.
What data persistence (if any) do you have? Are you using Core Data? Serialized objects in a plist? NSUserDefaults? Your strategy may be corrupting data you are persisting and that is leading to a crash.