I'm using Java 11, JNA with a DLL on Windows 10 64-bit, JUnit 4.12, Eclipse 20190314-1200, (aka 4.11.0). This is a gradle-based project, but I ran out of tags.
Quite a bit of that may not be relevant, but context never hurts, right?
While running any unit test that touches the DLL in question, the test silently fails, almost immediately. Almost. When I try to step into the goings on, I land in Structure.autoWrite() (the member function, not the static one), and when I step out, poof. The test ends. The call stack looks remarkably like I called autoWrite() directly, though it is actually a native method call. Eclipse's JUnit UI continues to show that test as if it were still running (little blue triangle overlay on the icon), but the tests all stop. JUnit doesn't even try to run any further tests.
I haven't found any logs. Standard out simply shows my last output (the path JNA uses to find DLLs). I got nuthin'.
Does anyone know of a relevant log file (not in user.name/appdata/local/temp, I checked quite thoroughly)? Some configuration I can tweak for more verbose output? Where I can find the JVM exit code maybe? Anything?
The DLL in question wasn't installed properly (by me), and when I first call an initializer function, it logged an error (in an unexpected corner of my hard drive) and called exit(), which is just rude.
Your DLL shouldn't end my program's process. At least it didn't cause Eclipse to shut down. That would have been... vexing.
And that was the last hurdle between me and a full suite of passing unit tests. Whew.
Upward and onward!
Related
We have a weird problem. We are using an automatic test tool. The DSL was implemented in Scala. The system which we test with this tool was written in Java, and the interface between the two components is RMI. Indeed, the interface part of the automatic test tool is also Java (the rest is Scala). We have the full control of the source code of these components.
We already have at the magnitude of thousand test cases. We execute these test cases automatically once every night, using Jenkins on a Linux server. The problem is that we sporadically receive a java.lang.NoClassDefFoundError exception. This typically happens when trying to access a Java artifacts from a Scala code.
If we execute the same test case manually, or check the result of the next nightly run, then typically the problem solves automatically, but sometimes it happens again in a completely different place. In case of some runs no such problem appears at all. The biggest problem is that the error is not reproducible; furthermore, as it happens in case of an automatic run, we have hardly any information about the exact circumstances, just the test case and the log.
Has somebody already encountered with such a problem? Do you have any idea how to proceed? Any hint or piece of information would be helpful, not only the solution of the problem. Thank you!
I found the reason of the error (99% sure). We had the following 2 Jenkins jobs:
Job1: Performs a full clean build of the tested system, written in Java, then performs a full clean build of the DSL, and finally executes the test cases. This is a long running job (~5 hours).
Job2: Performs a full clean build of the tested system, and then executes something else on it. The DSL is not involved. This is a shorter job (~1 hour).
We have one single Maven repository for all the jobs. Furthermore, some parts of the tested component is part of the interface between the two components.
Considering the time stamps the following happened:
Job1 performed the full build of both components, and started a test suite containing several test cases, which execution lasts about half an hour.
The garbage collector might swept out the components not used yet.
Job2 started the build, and it also rebuilt the interface parts, including the one swept out by garbage collector of Job1.
Job1 reached a test case which uses an interface component already swept out.
The solution was the following: we moved Job2 to an earlier time; now it finishes the job before Job1 starts the tests.
I'm currently working on developing a program in Netbeans. Unfortunately, my program tends to freeze a lot, however I'm having trouble figuring out where the issue is. What I would like to do is simply have the debugger highlight the currently executing line inside my code (not inside libraries). Basically stop the code at any point without using a breakpoint. Is there any way to do this in the Netbeans IDE?
Alternately, is there anyway for me to cause a break point to activate (and so show a workable stacktrace) whenever one of my lines of code doesn't move on for a certain period of time?
Profiling does work to some extent, however, it doesn't let me examine variables or get a definitive stack trace.
I am writing this program in Java and I'm using the Java SE version of Netbeans 8.0.2.
Most IDEs (Eclipse, IntelliJ which I use) have an option to pause all threads in a program. Look under the debug menus probably in the same place things like step into, step out of etc reside. A quick Google search on Netbeans IDE says there should be an option under that menu named "pause" that will do what you want.
It will pause all threads of execution in your program. You will be able to examine the stack of each thread and from there should should be able to figure out where your code is hanging.
I'm trying to test existing software and I'm running into an issue; if, during a junit test suite, I close a gui window, the whole test suite just ends. No errors, failures, or successes. It definitely ends too, because it closes all other windows as well, and terminates the thread.
I'm not using junit to the test the GUI - that's more of a system test obviously, and I'm using GUI automation software for that. However, in order to test a method in one of the classes in the software, I have to have stuff going on with the gui. At the end of the tests, I need to close the windows or they will remain open and will actually interfere with the other tests (it's networked software). However, as said, sending an onclosing event to any window immediately ends the test suite.
I became curious about the whole thing and slowly came to realize, to my horror, that even in normal execution, if I close a window, it's not handled within the software, it just magically stops executing! The main driver's loop doesn't even have any exit condition whatsoever, just while(true) with no breaks! My thinking is this must be related to why everything just stops when I close a window during the tests.
Anyways, I still don't fully understand what's happening, so if someone could fill me in, that would be great. But my main question is how can I fix/ get around this issue and close windows without killing the whole test suite.
Note: I can't change the behavior of the software. (As you may have guessed, this is for a class)
Sounds like the window close is calling System.exit(). If you have the ability to remove that, you could do so. If you don't, you could install a SecurityManager that prevents the call during testing. Example here: Preventing System.exit() from API
Is there any debugger that helps debug a Java JNI program along with the C library?
I should be able to debug the program starting from static void main in Java and continue to debug and place break points in the native c function and then continue to debug in Java after the control is transferred from C to Java.
A Java Virtual Machine debugger is very different from native code debugger. There is currently no such MATURE solution as one and the same debugger which would be able to seamlessly step from Java to native code and back. While this is a very irritant problem which makes some smart people trying to develop such a solution, there is undoubtely tons of un-imaginable problems involved. I personally do it in the following way:
start your Java code in debug mode and put a breakpoint at the first native call you are interested in. You can even implement a static native call, which won't do anything significant but will enable you to break as soon as possible.
fire up a native debugger. This absolutely can be the same instance of Eclipse, given two prerequisities: you have CDT installed and your native code was compiled in a way, that the debugging info is understood by CDT. Attach to the java(w.exe) process running your Java code. Put a breakpoint in the native code.
Whenever you need to transition over JNI interfaces, put breakpoints as close to the call entry/exit as you can (or need).
I have found that running the java code in an IntelliJ IDEA debugger and setting a very early break point allows one to attach CLion's debugger to the process (after sudo echo 0 > /proc/sys/kernel/yama/ptrace_scope). Then each IDE will stop the JVM and raise it's window at it's respective brake points in either Java or JNI Native code, with inspection of objects in memory in which ever context stopped. This makes for a fairly smooth experience.
In the last week or two, when I run Java code inside Eclipse Juno, it takes 2-3 seconds before it starts executing. I know it doesn't sound like long, but it adds up to being really annoying. (The same thing happens when I run JUnit tests).
It didn't use to take this long. It used to be almost instantaneous. I can't figure out what has changed in my system configuration and how to change it back.
In terms of the environment, the only thing that I can think of is that I recently installed a Java plugin into Chrome, but I can't see how that would affect Eclipse, as it's using a different JDK (and not the JRE I installed).
What should my next step be? How can I narrow-down what's causing it?
I bet this is because of having so many projects that are open in the workspace! You can close any non-used project by right-clicking on it and then select Close Project.