I've just noted I have a runtime error occurring on the main game scene when I test the device, and I review logs coming out on XCode in the console area.  I do not see this on the simulator.  

Q1 - Any advice/tips on how to fault find this as so far I haven't managed to find the issue.  

Q2 - Are the line numbers those that I will see in my source files in textmate?  i.e. if I see line 401 then it will only come from a LUA file in my project from a line 401?  (i.e. if there was a blank line in file X, then it wouldn't be this one I assume)

Q3 - If I put a few extract blank lines in a file I suspect, then if this file was the culpret the line numbers in the console warnings should increase right?  so this would be an indication

Q4 - Any way to get full debug and filename, function names in the console log?

Console Output Snippet

Sep  1 20:50:00 MyIPhone MyApp [18715] <Warning>: Runtime error    ?:0: attempt to perform arithmetic on upvalue '?' (a nil value)
    stack traceback:
        [C]: ?
        ?: in function <?:401>
        ?: in function <?:218>


Sep  1 20:50:00 MyIPhone MyApp [18715] <Warning>: Runtime error
    stack traceback:
        [C]: ?
        ?: in function <?:401>
        ?: in function <?:218>
 

A1.  Many of the issues that are "device" related come from file name problems.  The devices are case sensitive with regards to filenames, where the simulator is not.  The 2nd most common problem has to do with problems in your build.settings.  It's not processed as part the simulator.  

A2. The line numbers should line up, but since all symbol data isn't there you can't tell which file.  Also those line numbers could be from Core functions making it a bit more challenging to track them.

A3. If you suspect you know about where the problem is, why not drop in some print statements so you can see some values and know exactly where it is rather than depending on the line numbers.  You are going to get more intelligence about what is going on from the prints anyway.

A4. No.

thanks Rob - I try these - mind if I ask

* when you say Core functions what do you mean here Rob?   I was having a difficult time trying to find a lua file of my own with such line numbers, so it could have been a Core function then?  

* What do you think about using an error handler that tries to log (say to flurry) or open an email (social plugin) to send error info?  Would this pickup errors that come from Core functions too?   I guess I'm wondering whether there is a risk that you get a flood of errors occurring, which then in itself could be an issue as they are attempted to be logged to flurry, or open up an email UI

* Actually should after trapping an error should you log it (e..g flurry) and then really halt the application, so there are no issues.  In fact how do you halt the program without calling "error" itself?   Should I use "os.exit"?

update - got it sorted Rob fyi - it was associated with use of the accelerometer - line number did point to the function heading of the listener in one of the files that did have a line 401, so I initially thought it wasn't this as it wasn't pointing to a line within the listener.  

Easy way would be to use http://www.coronalabs.com/blog/2013/03/06/run-time-error-handling/ and show message and stackTrace in native.showAlert()

ohhh, I had assumed it would be the same for the error handler, but you're pointing out you will get the line number I think..very nice.. I'll try this

Btw - any thoughts on whether to return true or false in general from the error handler?  ummm.....

PS - stuck my question in the comments there: http://www.coronalabs.com/blog/2013/03/06/run-time-error-handling/#comment-39236

I return false because what is the point to let app run when it is crushed by runtime error (I cannot do anything with app)?

makes sense

update - actually logging errors to Flurry, but I have found that the error handler that grabs the error and logs it still doesn't have file names / function names  

For example I see this in flurry for a stack trace:  

stack traceback: [C]: ? ?: in function '?' ?: in function <?:1525> ?: in function 'dispatchEvent' ?: in function <?:569> ?: in function <?:218>

Maybe I'm having a Deja Vu, but I could swear I've answered this a couple of times in other posts.

Compile byte code in your device app won't have any data symbols, module filenames, etc. for you to use. 

Maybe I'm having a Deja Vu, but I could swear I've answered this a couple of times in other posts.

 

Compile byte code in your device app won't have any data symbols, module filenames, etc. for you to use. 

Rob, you'll receive even more of those request until this is fixed. Having an unhandler error callback is useless if we can't get a meaningful stacktrace to log on our servers. And there is nothing we developers can do besides spam every single function with possibly unneeded print statements.

You guys have access to the Lua compiler's source code, right? It should be a piece of cake to remember the name for every function entered.The stack already contains line numbers - how difficult could it be to also include the function name at least? Just a few lines of code on your behalf will be a life-saver for your clients. Having access to the compiler, you could even put the competion to shame by also including the primitive values with which the functions are called

Please elaborate, what's hindering you from doing that?

The part about compiling to byte code.... that's whats hindering us from doing that.  Symbols are stripped and replaced with very small byte codes to represent them.  White space like line numbers go away.  Its one long string of bytes.  There are no lines to reference. 

Rob

Thanks for the quick response, Rob!

About this byte code:

1. Can it be changed to include debug data in future versions or it needs to be backwards-compatible? It obviously has some notion of stack/functions/jumps/gotos given that some mangled stack trace is still generated, why can't this be improved?

2. How can the simulator output a perfect stack-trace upon error and the device can't? If it is interpreted instead of compiled, that means the compiler is problematic. Other byte-code compilers like Java's and C#'s can still generate debug data, why isn't this possible with Lua/Corona?

Sorry for the annoying questions but this is really bugging me. I'm on the verge of writing an automated tool to append stack-trace data on every function of a project's source code. But I somehow feel this will be more elegantly approached on the compiler's end.

It might not be clear but debug symbols are only stripped from the compiled Lua code when doing "distribution" builds.  In Corona terms this means, on the iPhone, using a Code Signing Identity whose name begins with "iPhone Distribution:" and for Android it means using a keystore with any name other than "Debug" (I understand these are arbitrary definitions but we had to go with something).

This means you can't submit unstripped code to the app stores but you can run on the device with full debug info (just use an appropriate cert when building).

Just so I understand correctly, is the request to be able to distribute apps via the app stores with debug info in them?  Or were the conditions under which stripping occurs unclear?

My 20c worth.  From a user requirement point of view re a development platform my main point would be:  

    "Ability to quickly/efficiently track down bugs in general".  

The thing that sticks out is there is some functionality that you can't test on the simulator, but when testing on the device you hit the symbols issue.  This would seem to imply the need for the simulator to simulate all functionality (including plugins etc) to meet the user requirement.   What do you think?  (i.e. just from a "idealist" point of view)   i.e. should there be more focus on the simulator?  (I'm not sure of the answer, just asking the question)

As I said, you *can* run with debug symbols on the device, you just can't distribute to the app stores with debug symbols.

sorry Perry - I misread the thread (was just skimming through forum responses) - thanks for pointing this out - I'll start changing my process when testing on the device based on the Code Signing Identify...thanks again

We've added a build.settings parameter to allow distribution builds with debug info in them to be made. It'll be available in Daily Build 2014.2221 and later.

This is the documentation ...

Normally distribution builds of an app (those intended for app stores) have Lua debug info stripped from the compiled code while development builds are not stripped. Generally stripping debug symbols is preferred for distribution because it reduces app size and provides a small performance gain but the tradeoffs entirely depend on the type of app and how you like to do error reporting.

On the iPhone, distribution builds are made by using a Code Signing Identity whose name begins with "iPhone Distribution:" and on Android they are made by using a keystore with any name other than "Debug".

Sometimes it can be useful to have debug symbols available in distribution builds of your app. This means you get more detail in stack traces and runtime error messages. The neverStripDebugInfo setting can be used to turn off debug symbol stripping altogether. In theory, there's no reason why an app built with this setting could not be submitted to an app store but policies vary and there are no guarantees. The debug info may reveal details of your app that you would prefer to remain proprietary.

settings =
{
    build =
    {
        neverStripDebugInfo = true
    }
}

Perry, that's great news! This option is exactly what I was looking for - leaving debug symbols in for distribution builds.  The bugs we face are sometimes hard to reproduce, both in simulator or by manually testing debug device builds, so the only option we had was verbose logging on the user devices in the wild. Thanks a lot!

Has this been added to enterprise as well? It is not working for me on 2223

Is the neverStripDebugInfo option available for both Android and iOS?