OpenHome Forum
Error handling for sync invocations in Java - Printable Version

+- OpenHome Forum (http://forum.openhome.org)
+-- Forum: OpenHome (/forumdisplay.php?fid=1)
+--- Forum: Net (/forumdisplay.php?fid=5)
+--- Thread: Error handling for sync invocations in Java (/showthread.php?tid=506)

Pages: 1 2 3 4


RE: Error handling for sync invocations in Java - simoncn - 01-12-2011 09:53 AM

(01-12-2011 09:05 AM)simonc Wrote:  The most reliable way to retrieve a stack trace would be to debug it using visual studio. Your abort popup should include an option to launch a debugger at the point of the assertion failure. Once visual studio has launched, select Debug -> Windows -> Call stack for the stack trace.

Its also possible that you'll get a stack trace written to the console if you continue running beyond the initial assertion failed message.

I tried Abort, Retry and Ignore (on separate runs) and none of these gave me a stack trace on the console. I don't currently have Visual Studio installed on my test server machine. The disk is quite full so I'll need to do some reorganization there.

Although I can install Visual Studio (at the cost of a little inconvenience), it clearly isn't something that I could ask a user of my software to do if they had a problem like this. Would it be possible to add code to ohNet to print the stack trace information in the event of this kind of problem?


RE: Error handling for sync invocations in Java - simonc - 01-12-2011 10:37 AM

(01-12-2011 09:53 AM)simoncn Wrote:  Although I can install Visual Studio (at the cost of a little inconvenience), it clearly isn't something that I could ask a user of my software to do if they had a problem like this. Would it be possible to add code to ohNet to print the stack trace information in the event of this kind of problem?

Stack traces will already be printed to console for any unhandled exception (including assertion failures) in threads created by ohNet. I'm guessing that your exception occurs in your main app thread so isn't caught by ohNet code.

The solution to this would be to expose ohNet's unhandled exception handler to client code. I'll try to do this in the next couple of weeks. You'd then need to catch all exceptions in your app thread(s) and call the new ohNet function. This function would attempt to print a call stack then abort the process.


RE: Error handling for sync invocations in Java - simoncn - 01-12-2011 11:53 AM

(01-12-2011 10:37 AM)simonc Wrote:  Stack traces will already be printed to console for any unhandled exception (including assertion failures) in threads created by ohNet. I'm guessing that your exception occurs in your main app thread so isn't caught by ohNet code.

The solution to this would be to expose ohNet's unhandled exception handler to client code. I'll try to do this in the next couple of weeks. You'd then need to catch all exceptions in your app thread(s) and call the new ohNet function. This function would attempt to print a call stack then abort the process.

I'd be very surprised if this failure were in my main app thread, as this thread is just sitting idle when my application has completed its startup. I'll install Visual Studio on the test server to find out which thread is running at the time of the abort.

When you say that I would need to catch exceptions in my app thread(s), are you referring to Java exceptions or C++ exceptions? There's no problem if it's Java exceptions. If it's C++ exceptions, the ohNet JNI code would need to catch these and rethrow them as Java exceptions so that I could catch them in my app.


RE: Error handling for sync invocations in Java - simonc - 01-12-2011 01:03 PM

(01-12-2011 11:53 AM)simoncn Wrote:  I'd be very surprised if this failure were in my main app thread, as this thread is just sitting idle when my application has completed its startup. I'll install Visual Studio on the test server to find out which thread is running at the time of the abort.

Sorry, you're right, this is happening in a thread that is created by the OS abstraction layer and is used to monitor changes in available network adapters. It'll be much simpler to get the call stack printed now.

(01-12-2011 11:53 AM)simoncn Wrote:  When you say that I would need to catch exceptions in my app thread(s), are you referring to Java exceptions or C++ exceptions? There's no problem if it's Java exceptions. If it's C++ exceptions, the ohNet JNI code would need to catch these and rethrow them as Java exceptions so that I could catch them in my app.

Good point. I can probably catch and deal with any unexpected exceptions in the C bindings, saving the need to do anything in managed code.


RE: Error handling for sync invocations in Java - simoncn - 01-12-2011 02:48 PM

(01-12-2011 01:03 PM)simonc Wrote:  Sorry, you're right, this is happening in a thread that is created by the OS abstraction layer and is used to monitor changes in available network adapters. It'll be much simpler to get the call stack printed now.

I tried debugging the exception using Visual Studio. It was easy enough to see the stack trace in the pulldown, but I couldn't find a way to copy and paste it. In the end I was able to do this (very painfully) by using PrtSc and stitching three images together in Paint. I could attach it here, but I have the impression that you already know what it is. For future reference, I'd be interested to know if there's any better way to do this copy and paste.

Quote:Good point. I can probably catch and deal with any unexpected exceptions in the C bindings, saving the need to do anything in managed code.

OK, thanks. This sounds like the right approach. I've had to do something similar myself when unexpected Java exceptions are thrown by code running on a thread that was invoked as a result of a provider action.


RE: Error handling for sync invocations in Java - simonc - 01-12-2011 04:51 PM

(01-12-2011 02:48 PM)simoncn Wrote:  I tried debugging the exception using Visual Studio. It was easy enough to see the stack trace in the pulldown, but I couldn't find a way to copy and paste it. In the end I was able to do this (very painfully) by using PrtSc and stitching three images together in Paint. I could attach it here, but I have the impression that you already know what it is. For future reference, I'd be interested to know if there's any better way to do this copy and paste.

It sounds a bit like you were using the list of running threads. You can also make a separate window showing a call stack for the current thread visible. This allows the full stack to be copied/pasted in a single operation.

You can make this window visible from the Debug -> Windows -> Call stack menu option. (Note that you have to be running in the debugger for this to be visible.) Its possible that this window will be docked into the same area as a list of running threads so you might have to select a different tab (at the bottom of the thread list) to see the call stack.
(30-11-2011 05:02 PM)simoncn Wrote:  I tried the latest code (pulled down today so that I would get the proxy change as well) and I'm sorry to say that the situation is worse than previously. When I pull out the network cable on the server, there's an immediate abort pop-up with a console message:

ERROR: Recursive lock attempted on mutex DMSL from thread ____
Assertion failed. OpenHome/Thread.cpp:89

I've committed changes which should deal with this. All being well, they'll make it onto github this evening.


RE: Error handling for sync invocations in Java - simoncn - 02-12-2011 08:45 AM

(01-12-2011 04:51 PM)simonc Wrote:  It sounds a bit like you were using the list of running threads. You can also make a separate window showing a call stack for the current thread visible. This allows the full stack to be copied/pasted in a single operation.

You can make this window visible from the Debug -> Windows -> Call stack menu option. (Note that you have to be running in the debugger for this to be visible.) Its possible that this window will be docked into the same area as a list of running threads so you might have to select a different tab (at the bottom of the thread list) to see the call stack.

Thanks for this. I tried it and I was able to paste the call stack.

Quote:I've committed changes which should deal with this. All being well, they'll make it onto github this evening.

I checked late yesterday evening and again this morning, but I didn't see any recent activity.


RE: Error handling for sync invocations in Java - simonc - 02-12-2011 09:39 AM

(02-12-2011 08:45 AM)simoncn Wrote:  
(01-12-2011 04:51 PM)simonc Wrote:  I've committed changes which should deal with this. All being well, they'll make it onto github this evening.

I checked late yesterday evening and again this morning, but I didn't see any recent activity.

We run a lot of tests overnight and only push to github if they all pass. One of the tests stalled last night so no code was pushed. I've just re-run them; all passed so the latest code should be available now.


RE: Error handling for sync invocations in Java - simoncn - 02-12-2011 11:54 AM

(02-12-2011 09:39 AM)simonc Wrote:  We run a lot of tests overnight and only push to github if they all pass. One of the tests stalled last night so no code was pushed. I've just re-run them; all passed so the latest code should be available now.

I've pulled down this update and rebuilt ohNet.dll. There's no abort now.
Thanks for this fix.

There's still a small problem, though. If I then replug the server's network cable, the server device is no longer visible to the control point. Refreshing the control point's device list doesn't help, but it does work if I restart the control point. The latter suggests that this is probably an issue with the control point stack.


RE: Error handling for sync invocations in Java - simonc - 02-12-2011 04:16 PM

(02-12-2011 11:54 AM)simoncn Wrote:  There's still a small problem, though. If I then replug the server's network cable, the server device is no longer visible to the control point. Refreshing the control point's device list doesn't help, but it does work if I restart the control point. The latter suggests that this is probably an issue with the control point stack.

While it'd be preferable for the device list to automatically handle this case, note that you can handle it in client code without restarting the cp stack. You should be able to listen for changes in available subnets and manually select a previously active subnet when it reappears. (Sorry, I'm not sure of the Java APIs for this off-hand.)