I'm using IntelliJ IDEA 2021.1 to debug the processing difference between two very similar executions of a Legacy Java6EE app. I want to capture the full call and/or stack trace of an application, maybe a thread dump as well since it may be offloading some work to another thread. I'm trying to test only one difference in parameters to determine why it fails with one more explicit parameter set. I'm primarily concerned with the difference in logic followed and maybe see if the query executions are different.
However, I can't find a resource for this process. I'm only able to find the importation of external traces and thread dumps for comparison in the Analysis tab from the JetBrains forum and guides, but nothing showing how to get the initial trace aside from hitting a breakpoint and exporting that small chunk.
Related
Generally I try to make my questions Reproducible.
In this case I couldn't find a way. Please feel free to guide me how to grab more details and I will attach.
In some cases, we are using the ABAP call stack programmatically to get additional info. I.E: logging user calls, accessing variables from lower calls in the stack as a last resort when there is no other proper way to retrieve them.
We have encountered a case, in which weird chars were added as a prefix in the call stack for central programs of HR module 'MP9XXX00'(Module-Pool generated programs for customer-specific PA infotypes). The weird chars are /A\.
The full string for calling program is /A\MP9XXX00.
The code used to get the whole call stack:
lt_call = cl_abap_get_call_stack=>format_call_stack_with_struct( cl_abap_get_call_stack=>get_call_stack( ) ).
There aren't such programs /A\MP9XXX00 in SE80.
Also, when tried to receive variables from calling program as mentioned, like this:
ASSIGN |( { ls_call-prog })PSYST| it failes, it caused dump. And when we looked into ST22 the stack didn't contain any /A\MP9XXX00 but just MP9XXX00 (ls_call-prog contained /A\MP9XXX00).
As said, we didn't manage to reproduce and debug it. just saw the result.
Where could those chars come from?
What we thought of
We thought that it might be related to the fact that our customer namespace starts with /A, but still, why it's shown up? why just a few times? why just the first two characters? and where did the other \ come from?
We thought that the prefix /A\ might be temporary added to (those) program names, say while importing related transport requests. And that maybe A is for Active/Activating. What made us think so is that it happens more in QA than in production.
I have a web application, using Spring-Boot. There is now a need for this application to use a custom dll (in house build dll file). There is nothing wrong with this dll, as we use it on our other applications, and have no problems with it.
To load the library in this new web application I'm writing, I have added the dll file to the procrun directory. This directory is on the library path, so that makes sense.
During startup I put in code to immediately load the dll, and also test some of its functionality. This works fine.
However, I have a timer, that schedules the execution of some functions, which may or may not include function calls to the dll.
At some point, about 10 minutes or so into execution, the service unexpected and seemingly without any valid reason, stops.
Although I try/catch exceptions at the appropriate logical places in code, there are no relevant log entries printed.
The Event Log shows something that reminds me of a null pointer exception:
Another bread crumb is that the event log will print something about the dll_unload. (see picture)
I need some help figuring out why the service is failing/stopping.
Kind Regards.
EDIT: After about three days of debugging and scratching my head, I came upon a forum thread that explained that this problem has something to do with the manner in which the system releases the memory during garbage collection. It seems that the dll in question was being unloaded by the garbage collector, even though it could still be called at some time later - which of course was the cause of the service falling over.
To solve the problem, I put in a timer that would call a method in the dll at three minute intervals (on my system this would not impact performance). I know this solution is a hack, but it works for me.
My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.
Recently, I've been digging in to JVM heap dumps using Eclipse MAT. I like it, but the one feature that I seem to use the most is the Dominator Tree. Eclipse's example screenshot:
Anyways, I find that a lot of the time, I usually get the most value out of just looking at that table and getting the first few entries. Since the turnaround time for getting this is:
Create Heap Dump (jcmd <pid> GC.heap_dump)
Download/Pull heapdump to a location (MAT isn't installed on our servers)
Run Eclipse MAT's ParseHeapDump.sh tool to build the various trees
Open MAT, click Dominator Tree icon.
Analyze
Is there a way to get this equivalent information off of a running JVM programmatically? I'd like to run some kind of gather_dominators.sh <pid> script on a host and get the Top X Objects from a JVM, but I don't know where to start.
If by "running jvm" You meant - "getting the info without doing stop-world heap-dump" then the obvious answer is: in order to do such thing without "full-scan" - the data needs to be collected throughout system life-time by tapping creation/release of each object and by maintaining the statistics. You could achieve such things by instrumentation or by using a ready-made custom agents (jol/jamm/etc). Note that many GCs are already doing similar work to collect (and print) statistics. IIRC - newer JVMs even keep track of such info within the class-metadata area (so getting statistics is instant).
https://github.com/google/allocation-instrumenter
(google-allocation-instumenter)
http://blog.javabenchmark.org/2013/07/compute-java-object-memory-footprint-at.html (with JAMM)
https://github.com/jbellis/jamm (JAMM src)
In Java, what is the best way to determine the size of an object? (JOL/etc here)
http://www.javaworld.com/article/2074458/core-java/estimating-java-object-sizes-with-instrumentation.html (short DYI guide)
https://www.youtube.com/results?search_query=Understanding+Java+GC
(webCast on how GC traverses objects for similar purposes)
On other hand - if You're fine to grab a heap-dump (which should be fine on any production system with any proper node-redundancy in place, designed for handling unavoidable Sun-JVM stop-world GC pauses), then Jhat, MAT-api, YourKit and Jol are probably Your best friends:
Programmatically analyze java heap dump file
How to analyse the heap dump using jmap in java
It is important to note that currently-existing heap-dump format loses the info about actual sizes of objects, so all tools (MAT/etc) are just trying to GUESS it properly:
http://shipilev.net/blog/2014/heapdump-is-a-lie/ (What Heap Dumps Are Lying To You About, by Aleksey Shipilёv)
HTH :)
Whether this is possible I don't know, but it would mighty useful!
I have a process that fails periodically (running in Windows 2000). I then have just one chance to react to it before having to restart it and painfully wait for it to fail again. I didn't write the process so don't have the source to debug. The failure is seemingly random.
With a snapshot of the process I could repeatedly and quickly test reactions to the failure.
I had thought of running inside a VM but this isn't possible in this instance.
EDIT:
#Jon Cage asked:
When you say a snapshot, you mean capturing a process when it's about to fail (including memory, program state etc. etc.) ...and then replaying it's final few seconds repeatedly to see what effect it has on some other component?
This is exactly what I mean!
I think minidump is what you are looking for.
You can also used Userdump:
The User Mode Process Dumper
(userdump) dumps any running Win32
processes memory image (including
system processes such as csrss.exe,
winlogon.exe, services.exe, etc) on
the fly, without attaching a debugger,
or terminating target processes.
Generated dump file can be analyzed or
debugged by using the standard
debugging tools.
This article shows you how to use it.
My best bet is to start the process in a debugger (OllyDbg being my preferred tool).
The process will pause on an exception, and you can try to figure out what happened shortly before that.
This needs some understanding of assembler and does not allow to create a snapshot of the process for later analysis. You would need to write your own debugger for that - it should be theoretically possible.