Perhaps a threadding problem? (REALbasic network user group Mailinglist archive)
Back to the thread list
Previous thread: Re: determining table relations in a database
Next thread: Recent items list : how to delete it
| FW: Special Valentine's Offer for Valentina - Beat the Price Increase! - Lynn Fredricks | ||
| Perhaps a threadding problem? - Jim Patek | ||
| Re: Perhaps a threadding problem? - joe strout.net | ||
| Perhaps a threadding problem? |
| Date: 01.06.07 15:39 (Fri, 01 Jun 2007 09:39:16 -0500) |
| From: Jim Patek |
|
I have a seemingly insoluble problem with a large console app that I
have written. The app sequentially processes units, well actually they are USGS flow gages, performs a bunch of statistics on the data and updates a number of database tables. When I compile the app an run it I invariably get a "NilObjectException" somewhere before the completion of execution. The app keeps a log, so I know where it was when it bombed out. If I run the USGS gage that it bombed out on in the debugger everything is fine. If I change the order in which gages are processed, it will process that gage without a hitch, but bomb out on another. If I just re-run the app, sometime it bombs in the same place, but more often it bombs in another place. It is a bit difficult to debug, since it only bombs 2 to 3 hours into the run (the runs are 4-5 hours long). The only thing I can think of is that, perhaps, I should include the pragma "NilObjectChecking". However, since the problem does not appear in the debugger I'm not sure this would accomplish anything. I was wondering if, since this is a very sequential or procedural app, I should use the pragma "DisableBackgroundTasks" to make sure it doesn't trip over its own threads. ANY thoughts on this would be welcome. Thanks Jim _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html> |
| Re: Perhaps a threadding problem? |
| Date: 01.06.07 15:45 (Fri, 1 Jun 2007 08:45:20 -0600) |
| From: joe strout.net |
|
On Jun 01, 2007, at 14:39 UTC, Jim Patek wrote:
> I have a seemingly insoluble problem with a large console app that I > have written. The app sequentially processes units, well actually > they are USGS flow gages, performs a bunch of statistics on the data > and updates a number of database tables. When I compile the app an > run it I invariably get a "NilObjectException" somewhere before the > completion of execution. The app keeps a log, so I know where it > was when it bombed out. Do you know exactly where the exception happened? If not, you can find out by implementing the App.UnhandledException event like so: Dim type As String if error IsA NilObjectException then type NilObjectException" elseif error IsA OutOfBoundsException then type 1OutOfBoundsException" elseif error IsA RegExException then type 0RegExException" elseif error IsA KeyNotFoundException then type 2KeyNotFoundException" elseif error IsA TypeMismatchException then type yTypeMismatchException" elseif error IsA IllegalCastException then type :IllegalCastException" elseif error IsA OutOfMemoryException then type lOutOfMemoryException" elseif error IsA StackOverflowException then type fStackOverflowException" elseif error IsA UnsupportedFormatException then type pUnsupportedFormatException" else type -RuntimeException" end if stderr.WriteLine "Unhandled " + type + "!" for each frame As String in error.Stack stderr.WriteLine " - " + frame next if error. Message <> "" then stderr.WriteLine "Message: " + error.Message if error.ErrorNumber <> 0 then stderr.WriteLine "Error Number: " + str(error.ErrorNumber) Now, let your app run, and when the exception occurs it should tell you the full call stack, including the actual method where it happened. Go and inspect that method, and look at all your object references therein. One of them is nil -- ask yourself how that could be, and I bet you'll see the problem. I don't think mucking about with pragmas will be helpful here. HTH, - Joe |