how to debug runtime error that doesn't occur on simulator, just on device?

[greg886]

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 &nbsp;1 20:50:00 MyIPhone MyApp [18715] \<Warning\>: Runtime error&nbsp;&nbsp;&nbsp;&nbsp;?:0: attempt to perform arithmetic on upvalue '?' (a nil value) &nbsp;&nbsp;&nbsp;&nbsp;stack traceback: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[C]: ? &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;?: in function \<?:401\> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;?: in function \<?:218\> Sep &nbsp;1 20:50:00 MyIPhone MyApp&nbsp;[18715] \<Warning\>: Runtime error &nbsp;&nbsp;&nbsp;&nbsp;stack traceback: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[C]: ? &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;?: in function \<?:401\> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;?: in function \<?:218\> &nbsp;

These warnings are coming many times a second, but actually every third “enterFrame” it seems.  

I should not I don’t actually notice any issue as such in the app when I use it.  Just noticed the error in the console log.  The reason it was an issue is I started to use an error handler, and then noted the error handler was going off all the time (i.e. to send an email with error details if an error was thrown in the app)

[rob]

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.

[greg886]

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”?

[greg886]

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.  

[piotrz55]

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()

[greg886]

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

[piotrz55]

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)?

[greg886]

makes sense

[piotrz55]

Regarding your question under the link. From my experience you can execute code just fine in handler scope. I was able to handle native alert and it’s buttons (however no idea what will happen when trying to call outer code). The reason I’d rather close app is because runtime errors corrupt application functionality completely.

[greg886]

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>

[piotrz55]

Strange, ‘?’ are in places where should be file or function name, it must be something with Corona itself. Have seen thread recently with this kind of problem. Can someone from Coronalabs help?

[greg886]

Coronalabs feedback would be great - especially if others have seen the event hander working whereby filenames etc are included…

FYI my code re event handler code (cut down to key bits):

local function myUnhandledErrorListener( event ) analytics.logEvent( "Error", { errorMessage=event.errorMessage, stackTrace=event.stackTrace }  ) end Runtime:addEventListener("unhandledError", myUnhandledErrorListener)

[rob]

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. 

[greg886]

Thanks Rob. It was wishful thinking to hope the error handler case might give a better result than looking at the console output on Xcode

[rob]

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.

[greg886]

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”?

[greg886]

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.  

[piotrz55]

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()

[greg886]

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

[piotrz55]

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)?