petru66
February 7th, 2003, 05:01 AM
...Well, it must have a code: A more correct question would be:
What to do when the runtime error does not report the code? ...When
it only says "Please report to developers", or something like that?
Well, I am _the_ developer :) so what am I supposed to do
to find out what is going on?
I have a C# application that handles (or at least tries to...) a bunch of threads - some of which interact with an in-process Java Virtual Machine. The interface to JNI is done by a dll created from unmanaged C++ - well, it's pretty complex.
Here is what I tried:
1. debug in Visual Studio .Net: So I tried to debug, and to break at each exception.
It did not break when the fatal runtime error occured.
Instead of clicking the OK button of the error message box, I did a break
in the debugger. The position in the code - a JNI call - suggested
something, but I could not figure out what was wrong, by looking at the
values of variables.
2. run as separate process, and when the error occurred, attach quickly
a Visual Studio to the process. I did this both with the debug and release
versions. Again, when I did break, the position in the code was
meaningless.
Now I have a hunch that this must be related to the calls of JNI functions;
it seems as though eventually, after many data and calls have been passed
to and fro between C# and Java, JNI gets tired (or bored, or angry) and
decides that hey! enough! that's it! take this runtime error and be happy
that I worked so far!
The thing is, I cannot check if this is so. I did (hopefully) all the tricks asked
by JNI for ensuring that it works smooth. And, you know, when a normal runtime error happens, it usually breaks the debugging process and locates
the line that produced it: that's the nice thing to do for a well-behaving runtime error. How do you catch, though, the wild thing? I put every JNI call within try-catch: what kind of runtime error does not let itself caught?
Maybe someone out there struggled already with this kind of problem.
Any help is highly appreciated.
Petru
What to do when the runtime error does not report the code? ...When
it only says "Please report to developers", or something like that?
Well, I am _the_ developer :) so what am I supposed to do
to find out what is going on?
I have a C# application that handles (or at least tries to...) a bunch of threads - some of which interact with an in-process Java Virtual Machine. The interface to JNI is done by a dll created from unmanaged C++ - well, it's pretty complex.
Here is what I tried:
1. debug in Visual Studio .Net: So I tried to debug, and to break at each exception.
It did not break when the fatal runtime error occured.
Instead of clicking the OK button of the error message box, I did a break
in the debugger. The position in the code - a JNI call - suggested
something, but I could not figure out what was wrong, by looking at the
values of variables.
2. run as separate process, and when the error occurred, attach quickly
a Visual Studio to the process. I did this both with the debug and release
versions. Again, when I did break, the position in the code was
meaningless.
Now I have a hunch that this must be related to the calls of JNI functions;
it seems as though eventually, after many data and calls have been passed
to and fro between C# and Java, JNI gets tired (or bored, or angry) and
decides that hey! enough! that's it! take this runtime error and be happy
that I worked so far!
The thing is, I cannot check if this is so. I did (hopefully) all the tricks asked
by JNI for ensuring that it works smooth. And, you know, when a normal runtime error happens, it usually breaks the debugging process and locates
the line that produced it: that's the nice thing to do for a well-behaving runtime error. How do you catch, though, the wild thing? I put every JNI call within try-catch: what kind of runtime error does not let itself caught?
Maybe someone out there struggled already with this kind of problem.
Any help is highly appreciated.
Petru