Here's an obscure Friday Morning question:
Is it possible in LabVIEW to get the callees of a VI without loading the entire VI into memory? For instance, by reading static information from the binary?
Thanks
Well there is the private/scriptig method App.Read Linker Info From File, I don't think this will load the VI into memory, for more info have a look at the LabVIEW wiki (currently off-line , here is a Google cached page) page on the linker method.
The linker method will return all the info on the VI and it's external needs (VIs, DLLs, CHMs etc).
Ton
No, I don't believe so. When you open a reference to the top-level VI, it will be loaded into memory. That's even before you have the opportunity to query it for its callees.
Ton's answer is correct. The mentioned method is an application instance method not a VI reference method. You supply the path to the VI in question to that method and it will then parse the VI structure and extract all the relevant linker information without loading the VI as such into memory (Obviously it will read in the information from the file into memory to parse it but it will not load/instantiate the VI itself).
The problem with that node is however that it is private, because it has changed its interface in the past and may do so in the future again without warning. There even was a case between 7.0 and 7.1 or so, where the interface changed without any warning in the form of a broken arrow, but when executing it with the old data structure it would simply crash. As a private node that is fully valid, as no warranties are made about the functionality of private nodes.
Related
When attached to the debugger via Xcode, LLDB provides a useful view of local variables (the bottom left of the screenshot):
I found an LLDB command frame variable (and gdb's info locals) that provides a list of the local variables (as seen in the right side of the screenshot above).
My hope is that this functionality is possible to perform on the device at runtime. For example, I can access the stack trace using backtrace_symbols(), the current selector via _cmd, and a few others.
Has anyone had experience in this area? Thanks in advance.
Xcode/LLDB can show you this information because they have access to debug information in the binary, called a symbol table, which help it understand what memory locations correspond to which names in your source code. This is all outside the Objective-C runtime, and there's no interface in the runtime to get at it.
There's another reason why this won't work, though. When you're building code to run in the debugger, compiler optimizations are turned off, so all the variables you reference in your code are there.
When you build for release, though, generally the compiler optimizations get in there and re-arrange all your carefully named local variables to make things run faster. They might not even ever get stored in memory, just in CPU registers. Or they might not exist at all, if the optimizer can prove to itself that it doesn't need them.
My advice is to think again about the larger problem you're trying to solve...
I have a two broken VIs with front panels that open fine, but I can't edit or run them, or open theis block diagrams.
One of these was made as a replacement for the first when it started to have this problem. I need to at least find out how to avoid this problem in future, so I don't lose work on bigger VIs.
I'm not sure if it makes any difference, but I very recently upgraded to LabVIEW 2013.
Thank you in advance.
This is the error I get when I try to run them:
"
VI has a bad connection to or cannot find a subVI or external routine.
This VI has a bad connection to or cannot find a subVI or external routine but
it has no block diagram to show or fix the error. You must find or correct the
subVI or external routine. Check for more information in the Explain dialog box
in Get Info.
"
Before reverting to a previous version (using dropbox) I got a different error with one of them:
"
LabVIEW: Generic error.
An error occurred loading VI 'sweep harmonics first test.vi', LabVIEW load
error code 6: Could not load the block diagram.
"
One situation how this happened.
Sometime LabVIEW crashes, and it restart. After restart, LabVIEW will ask you to recover the autosaved code.
I personally always discard those autosaved code. If you do choose to recover autosaved code, there is a chance the recovered code is corrupted. Once you save corrupted code to disk, you are probably going to lose the ability to open/save the block diagram ever again.
Having a version control system is usually a way to avoid minimize the damage when LabVIEW crashes. At worst, you loose maybe an hour worth of work.
If you can't open Block Diagram of your VI, first check the suggestion by #Rodrigo - it is most likely just a "compiled" VI, which has Block Diagram removed.
If you think there is Block Diagram inside and it is just corruped - you may contact NI support. And if you want to look deeper by yourself, extract the VI to XML using pyLabview, and look into the XML - there you can modify every single part of the VI. For example, you may start removing parts until it starts working.
I wouldn't go into manual VI editing unless you have at least a dozen of affected files though. For a single file, it will be faster to re-create it in LabVIEW instead of trying to understand the internals. If many files are affected - may be worth finding the issue in one, as other files probably have the same glitch, so you can make a script which extracts, modifies and re-creates VIs automatically.
From the sound of it, I believe what happens is that you are trying to run the VI's created as "DATA" for an executable, instead of the actual source VI's.
When you build an executable LabVIEW creates a copy of all the Top Level VI's dependencies into the support (DATA) folder which should be in the same directory as your executable.
Try opening the VI's that are marked as not having a block diagram and navigate to File>>VI Properties to check the path from which the VI is being loaded. If it's not the original VI, you can just replace it.
I compile a DLL with mingw 4.5.0 and use it as a Game Maker 8.0 extension. Game Maker dynamically loads the dll. Everything appears to work (the dll functions are called and provide correct return values), but when I close Game Maker a dialog pops up: "Microsoft Visual C++ Runtime Library", "This application has requested the Runtime to terminate in an unusual way." After that, the process continues to linger in the background for a few seconds and then disappears.
This also happens when none of the functions of the dll are actually called. There is no DllMain, and all static/global variables are basic data types or std::string (it actually also happens when I remove the std::strings).
The dll statically links with zlib and libpng. The problem seems to vanish when I pass -static to the linker which (I assume) also links the runtime statically. However, this considerably inflates the size of my DLL, and it is at best a workaround until I understand what is going on.
Any ideas on what might be the cause?
Update: Actually, it seems that the problem only happens when two extensons are loaded in Game Maker: One with a dll linked with -static, and the other without. Linking both without -static makes the problem disappear. However, I still don't understand the problem, because the dlls never directly interact or share data structures.
Update 2: I recently found out that this might be related to strange behavior of Game Maker itself. It seems that global variables aren't initialized correctly when the DLL is loaded, which might cause a crash on unloading if global objects try to free memory they don't own. That would mean the -static was just a random factor that changed the value of the uninitialized memory the globals were associated with.
Update 3: Modified the above to include the info that this is about Game Maker extensions, since this is likely relevant as per Update 2.
It's just a guess. Try to look into something like the "static initialization order fiasco" that is described here. It may be that your problem is more related to the destructors (since it happens on close).
This is what I'm doing:
extract contents of my JRE's rt.jar
extract src.zip of my JDK (same version)
Now, if I copy Runtime.java from the extracted src folder and compile it using javac.exe without any modifications and then put it in the extracted rt folder to finally put everything back in a jar file using jar.exe, everything works as expected. The JRE runs fine.
However, if I make the slightest change to Runtime.java and compile it and put it in rt.jar, the JRE crashes whenever I attempt to start it. This is an example of a slight change that causes the silent crash:
/** Don't let anyone else instantiate this class */
private Runtime() {
System.out.println("This is a test.");
}
Instead of:
/** Don't let anyone else instantiate this class */
private Runtime() {}
Could anyone tell me why this is causing my JRE to crash?
Thanks in advance.
It's possible that System.out has not been initialised at the time that the Runtime() constructor runs. Usually console output is not considered a "slight" change, but at the wrong time it can invoke way too much stuff that may not be set up at all yet.
You're doing this all wrong. You can't distribute that modified JRE for a start, so it is only useful inside your organization . Install a SecurityManager and don't grant your codebase any of the RuntimePermissions you're trying to protect against.
#Tom - I advise you NOT to try to do this:
You cannot distribute the modified rt.jar file without violating the Sun binary license.
Even if you did, you would not be allowed to call it Java.
As you are finding, there are lots of complications that arise when you make changes, particularly when those changes might interfere with the JVM's behind the scenes initialization. And when things blow up during initialization, the JVM often cannot report the problem in an intelligible way.
If you do succeed in making the modified rt.jar work for one JRE, there is no guarantee that the same hacks will work for a different version.
Nobody in their right mind would knowingly use a modified JVM (especially one modified by a third-party) in a production app.
EDIT : judging from your other questions, I guess you are trying to reverse engineer or modify some third party Java application with a custom launcher. If you provided more information on what you were really trying to do, we might be able to suggest the right way to do it ... rather than using "desperate measures" such as modifying the JRE.
That's pretty strange, as I did the same trick with many classes in rt.jar in past.
Can you provide us with the crashed process output?
I have an old VW3/ENVY image with a parcel loaded as unmanaged code (exactly the situation Mastering ENVY/DEVELOPER warns against). Unfortunately, this problem happened a long time ago and it's too late to just "go back" to an image without the parcel loaded.
Apparently, there is a way to solve this problem (we have one development image where this has been solved, and there are normal configuration maps that contain the exact same code as the unmanaged parcel but they can't be loaded), but the exact way has long since been forgotten (and there are some problems with taking that particular dev image as the base for a new runtime image, so I need to find out how how to do it again).
In theory, it should be possible to remove the parcel and reload the code from a configuration map. In practice, all normal ways (using the ParcelBrowser or directly calling UnmanagedCode>>remove) fail. I even tried manually removing the offending selectors from the method dictionary, but past a certain point (involving a call to #primBecome:) the whole image hangs completely (I can't even drop into the debugger). I started hacking the instances of the classes and methods, hoping I'd trick ENVY into thinking that these particular methods are normal versioned code, but without any success yet.
Are there any smalltalk/envy gurus around that still remember enough of VW 3 to provide me with any pointers?
Status update
After a week of trying to solve the problem I finally made it, at least partially, so in case anyone's interested...
First, I had to fix file pointers for the umnanaged code (otherwise, all everything that tried to touch the methods would throw an exception). It looks like ENVY extends Parcel so that, in theory, all integer file pointers are changed to ENVY's void filepointer when loaded, but in my case, I had to do it manually (a Parcel provides enumeration for all selectors it defines). Another way would be to tweak the filePointer code, but that can't easily be done automatically on every image where it's needed.
Then, the parcel can be discarded, which drops the parcel information, but keeps the code. The official "Discard" mechanism needs to have a valid changes file (which envy doesn't use so it has to be set manually, and reset afterwards) and the parcel source (which we fortunately had).
To be able to make any changes to the methods (either manually, or via loading an application or class from ENVY), they need to get rid of their unmanaged status. This can be done by manually tweaking TheClass>>applicationAssocs (I also got rid of all references to the classes in UnmanagedCode sich as timestamps, and removed the reference to the discarded parcel). I actually had some info on how to get to this point from my boss, but I haven't been able to understand the instructions until I almost figured it out by myself.
This finally allowed me to load and reload all the Applications that contained the classes. In theory. In practice, the image still hung completely whenever I tried to load a newer version of the Application (that contained the code formerly in the parcel).
It turned out that the crashes had absolutely nothing to do with the code being unmanaged, but with the fact that the parcel in question modified InputState>>process:, where it caused an exception due to a missing and/or uninitialized class variable (the InputState>>initialize method wasn't called until after the new process: method was in place). I had to modify the Notifier class to dump all exceptions to a file to find out what was going on. Adding the class variable to the source of the class (instead of adding it via reflection), suspending the input processing thread via toBeLoadedCode and starting it again in the loaded method and creating a new version of the application solved even this problem.
Now everything works, in theory. In practice it's still unusable, because reloading the WindowSystem or VisualworksBase applications causes their initialization blocks to run, and a whole lot of settings are reset to their defaults - fonts and font sizes, window colors, UI settings... And there doesn't seem to be any way to just save the settings to a file and load them later on, or just to see what all the settings are (either the official Settings menu doesn't show everything, or we have a heavily tweaked image... so much for reconstructing it from scratch). But that's a completely different question.
Well, normally the recommendation would be that you should be able to rebuild your development image from scratch by loading your code from the repository. But if you had that, then the answer would be simple, just discard that image and reload. I think it's been long enough that I've lost whatever knowledge I've had about how to mess with the internal structures to get it back, and it sounds like you've tried a lot of things. So, although it might be painful, figuring out the recipe to rebuild your development image by loading stuff from the repository sounds like it may be your best bet. It probably isn't all that horrible, there just might be a few dependencies on the image state, or special doits that need to be executed.
You also probably need to validate what's in the repository against what's in the image you're working from. If there was unmanaged code loaded and then someone modified it and saved it, it's not clear to me that it would have been saved to ENVY. So you probably want to audit everything that was unmanaged code and if it's been changed, save that to a repository edition.
Sorry I don't have any better answers.