BAD_EXC_ACCESS with CFSocket - iphone

I'm doing a small app which has TCP/IP server. I am familiar with BSD sockets and POSIX threads, but I selected CFSocket API. I wanted to do it in non-blocking/async/(very run-loop) scenario. I read a couple of tutorials and than started coding. Everything goes fine. Code for accepting connection works fine. I got 'kCFSocketAcceptCallBack' event. Things are not so good when I start to receive a data. I got BAD_EXC_ACCESS.
Code: http://www.nopaste.pl/18ka
It's my first 'hello world' app. I doesn't know very well X-Code, but it looks like "crash" occurs in internal 'select' function. My guess is CFSocket runs another thread which does 'select' all the time. Can anybody help ?
Whole project here: http://www.speedyshare.com/file/qbXjX/Playground.zip

If you run the app with no debugger, then the iOS will create a crash log which will detail the state of the stack.
You can retrieve the crash logs from the device with Xcode in the "Organizer" window.
EXC_BAD_ACCESS signals typically occur due to bad pointers.

Related

Catalyst Development Server - not showing routes and errors

To set the seem, I'm an experienced developer and have coded many languages over the years, including a good bit of Perl back in late 90's early 00's. Since then I haven't touched Perl, but now have a client who wants some changes making to an existing open source project built using Perl5 and Catalyst. I've quickly worked through the Catalyst tutorials, read a few books online and am now starting to feel my way.
I have the existing project up and running on a clean Debian Wheezy VM and am testing the code an my changes using the Catalyst Development Server.
While working through the tutorials and writing a few test apps, the development server would always output a lot of useful information when run, such as the configured routes etc.. But under this project, when I run the server I don't get a lot of output. I don't even get messages sent to $c->log->debug();
I run the server with the following command:
perl ./script/asnn_panel_server.pl -d -r
Which outputs the following:
HTTP::Server::PSGI: Accepting connections at http://0:3000/
I can access the server and the application is running fine.
In a test controller action I can try the following lines:
$c->log->debug("A test debug message");
print "A test print message\n";
The debug log message does not appear in my development server output, but the print line does. So I know the call to $c->log->debug() is not blowing up, because the next line is executing, but where is it going?
So essentially I feel I 'could' get more useful output from the Catalyst Development server, but am not.
I have googles but can't find anything of relevance. Sorry if I'm going in the wrong direction here, I do know what I doing in general, but have a lot to pick up here in a short amount of time!
I suspect my issues might be specific to the open source project I'm working on, but there's not a lot of help to be had from that direction. Could anyone give me any pointers as to what to investigate?
UPDATE : I now realise that the application is using log4perl, which is configured to send $c->log->debug() to syslog. I still don't know why the Catalyst Development server isn't providing much output.
:wq
For anyone coming upon this later, if you want to see the developer debug stream (stuff about the routes and classes and models your application is using, etc you need to be in debug mode, which you can do easily by setting CATALYST_DEBUG=1 in your env (I often start my app like "CATALYST_DEBUG=1 perl -Ilib script/myapp_server.pl"
There is sadly a difference between debug as a log level and debugging mode. The way catalyst works is that if you are in debugging mode (via CATALYST_DEBUG=1, or any of the other documented ways this gets turned on) all this debugging stream gets sent to the log, most of it logged at the debug level (again debug as a log level is distinct from debugging developer mode :( ) So you need both debugging mode and your logger should be set to listen at the debug level.
If you use the default catalyst log, it is debug level by default, so doing CATALYST_DEBUG=1 is all you need. If you use a different logger be sure to enable debug log level for your development setup, if you wish to see those developer stream logs.
Messages sent to $c->log->debug() are generally disabled in production environments. If it doesn't seem to matter whether you start your scripts with or without the -d switch, then I'd suggest something downstream in the sequence is setting the environment variable CATALYST_DEBUG to 0 or undef unilaterally.
That said, you should be able to see the output of $c->log->info() or $c->log->warn() calls. The answer to that question should help you determine if the problem is log4perl or Catalyst related.
Hopefully that will get you on your way.

I2cSlave reading issue on lpc1343

I'm trying to use the lpc1343 as a i2cslave to transmit some data. Writing to the board gives no problems and works exactly as I want it.
However, reading from the board gives problems. It seems I'm not getting any data back although I am sending the right commands. Whenever I try to debug it my board just hangs and I have to reset the driver and my pc to get it running again.
Also, I made a LED go on/off whenever I try to read from it. It only does this once and whenever I try to do it again nothing happens. I think the I2c is stopped then but I have no idea why.
I have found the example code on the website once but now it seems to be gone. Does somebody have an updated I2cslave code?
Which operating system are you writing code for and how can you tell that writing to the i2c chip is successful?
If the write function returns, it could be that the message has been sent but the chip is in a weird configuration that doesn't act on the message received.

Get previous run, crash logs on iPhone

I trying to write a a crash report feature that when you launch the app after a crash, it will offer to send the crash report to the server. I can't find how to get the crash log within the app. I saw there is a framework that doing so (PLCrashReporter), however this framework is large and I don't need most of it's features.
Does anyone knows how to simply access the log?
Thanks,
Guy.
I guess I don't have the karma to add a comment to Nimrod Gat's answer, so I have to provide my follow-up here. I'll try to make it worthy of a standalone answer.
It's very, very difficult to write a safe, correct, and reliable crash reporter, especially one that runs directly in-process. The code referenced in Nimrod Gat's answer is not correct and honestly, that blog post should be retracted. Signal handlers must only run async-safe code, and that code isn't async-safe:
http://www.cocoadev.com/index.pl?SignalSafety
Crash handling is even more complicated than normal signal handling, because that you can't expect the process to continue to run successfully after your signal handler returns.
It's tempting to think you can just hack together a simpler solution, and it will work some of the time, but there's a good reason people like Google's engineers have thousands of LoC dedicated to reliable crash reporting:
http://code.google.com/p/google-breakpad/
On iOS, you should just use PLCrashReporter. On other platforms (such as Mac OS X) you should use Google Breakpad. There's no point in re-inventing this wheel unless you're going to do it not only correctly, but better than what already exists.
I had this similar issue and the PLCrashReported seemed too complicated for what I wanted to do.
Note that you can't access the crash report generated by Apple, the PLCrashReport generates it's own reports and store them in the user's cache folder.
Eventually, I used the following example:
http://cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html
it's very simple and easy to use, just register exception and signal handlers using:
NSSetUncaughtExceptionHandler(&HandleException);
signal(SIGABRT, SignalHandler);
signal(SIGILL, SignalHandler);
signal(SIGSEGV, SignalHandler);
signal(SIGFPE, SignalHandler);
signal(SIGBUS, SignalHandler);
signal(SIGPIPE, SignalHandler);
and get the stack trace using the backtrace method in UncaughtExceptionHandler class.
Maybe a better solution will be to use a fully specialized end-2-end solution/service? Such as http://apphance.com. It is currently in closed beta testing phase, but you can ask for participation and we'll get back to you pretty quickly. The only thing you need to do is to register for an API key and embed a small framework library into your app (or .jar file in android). Then you have remote access not only to crashlogs but also to a debug logs generated by the application - which makes it much more useful. It is for now targeted to be used during testing, but there will soon be a lite version that you will be able to embed into app-store-released application.
Inside the framework we are doing all the magic of plugging-into the apple's framework and getting the crashlog information, decoding stack traces, even handling out-of-memory cases. All the comments by #nupark hold very much true: We spend countless hours on making it works seamlessly - thread-safeness, making sure that we can do the job of saving everything within the time required by Apple's framework before your app get finally killed, getting stack trace from out-of-memory case (that one was really difficult). The same for android - we've done some clever tricks there to make sure it's really working fine.
Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the solution.
There are a bunch of (SAAS) E2E solutions that you may be very happy to know.
Very very simple to integrate into your application
Have Fun...
crashlytics (Free and my preferred)
hockeyapp
bugSense
Crittercism
In our days you may use the built-in crash reports (iOS & Android)
iOS (Itunes connect) - Viewing Crash Reports
Understanding Crash Reports
on iPhone OS
Reading Android Market Crash Reports

No Internet Connection

I am a little confused on how to go about and do this....
On each page of my app i connect to PHP file to drag in data from my server. I have about 10 pages. Now if there is no connection to the internet then of course now data can be received.
Often the app crashes and we are putting this down to not having the data due to a change in connection or wifi whatever.
Now i have setup the reachability thing and that works, but i dont know how to link this in with the PHP calls. Should i check the reachability and if no connection then dont run the call. If so, what about all the variables, they will still be null and cause an error then?
I dont really know what is the best solution.
Hope you can help
Alex
Are the php calls just to receive data from a database without using a built in DB framework such as SQLite? If so, I went the same route to avoid the headache at first, but running SQLite in your app is a better solution overall, and reduces multiple dependencies (such as internet connection).
Now if the php calls that give you data back are receiving this information from yet another source and then feeding it into its own DB.....
Should i check the reachability and if no connection then dont run the call
Yes you should. This is done in multiple apps already. What variables would be null in this case? Pop the code that makes the call in an "if" block below this check, and only run it if true. Error handling other variables that might be null because the php call isn't setting them is up to you. You can do this is multiple ways.
You should certainly cache the data so the App doesn't HAVE to connect to the internet to display something, other than that I would make sure to use asynchronous requests and the timeout feature of NSURLRequest to control your attempts to request data in the background. If you don't get the data, just keep using what you have cached.

What can cause Bonjour to not call me back during browsing?

I have a rather popular Bonjour-based application in App Store. It works perfectly, but around 0.2% of my users report a bizarre bug: "no arrows appear on the edges of the screen, so I can't share stuff with other people!". Needless to say, displaying these arrows is tied to the browsing of a particular Bonjour service on the local domain.
The problem is, the Apple review team seems to intermittently happen to be in this 0.2%. This isn't good for review results, as you might imagine. No matter how much I try, I cannot reproduce this bug.
From the few logs I have, it looks like my app is running correctly, just not receiving NSNetServiceBrowser delegate calls. What can cause this?
Things I've tried:
Having a shorter service name < 14 chars in length to be in spec.
Publishing on #"local." rather than #"" (aka Go Look For The Default Registration Domain). My app is rather useless on a wide-area network anyway.
Things I haven't tried: restarting the browsing machinery periodically. (I have two browsers, though, one looking for the legacy longer name, one for the new shorter one.)
What to do?
There are many areas where things can go wrong. Since the NSNetService instance provided to your delegate methods is autoreleased, you need to retain it if you plan on reusing it out of scope for that method. Most people will add it to an NSMutableArray or NSMutableDictionary so that it is automatically retained, and only autoreleased when removed from the collection. If that is the case for your code, make sure that you have properly initialized your collection before adding the object. Since messages to nil are perfectly ok, you may be sending the addObject:netService message to nil. You will not receive an obvious indication that you never initialized your array or dictionary, and it will appear as though everything is working just fine…except that delegate messages “mysteriously” don’t fire off when peers change status, when you try to connect to one, etc. This crops up often enough in Bonjour troubleshooting that I would recommend it as the first place to start your troubleshooting. It happens to the best of us.
One easily missed problem for apps running network code on a background thread: throwing an un-handled exception on that thread. This can occur without crashing your whole app due to Cocoa/Unix’s rules on threading. If your networking code “just stops working for no reason,” then you may want to check your iPhones Console and logs for error messages. Make sure you have set a breakpoint on the objc_exception_throw symbol.
For more, read the full article "Troubleshooting Bonjour Networking for the iPhone" at my dev blog.