What happens when module_exit is triggered, while the module is still running? And Is it possible that the module will still run afterwards?
Once module_exit has returned, nothing in the module should run. If something does, the system will likely panic when the module's memory is released.
You must either:
1. Prevent this by holding a reference on the module, and not releasing it as long as anything can run.
2. Unregister all hooks you've registered in module_exit and use proper synchronization, to assure that everything which was running has stopped.
Related
I'm still rather new to the world of API programming in Solidworks PDM, and i have run into a cumbersome problem i was hoping to get some insight in: For many normal API's in PDM, it is simply enough to add the .DLL file in PDM-Administration as 'Debug', and from thereon out, whenever the solution in VisualStudio is being rebuild, the PDM-Administration will automatically grab the same DLL-file, the next time it is being called from PDM. This is great for Debugging, no problem here.
But, as soon as the API has to trigger a task (to be executed on a client PC), it can only be added to PDM as a normal task (no debug mode), then added to the 'Task Host Configuration' on the client, and then configured as a 'New Task' in PDM-Administration.
This all works fine; BUT, it takes quite some time to change anything, since the only way i can get changes to take effect, is first to rebuild the Solution in VisualStudio, then manually overwrite the DLL-file in PDM-Administration, and finally reboot the client-PC (to force-update which version of the add-in it sees).
I have tried; logging out/in-again(in PDM), restarting the explorer, and clearing the local PDM-Cache... nothing has happened here
Can any of you give me some advice on how you debug PDM API's?
or at least force-reload a addin on the clients.
Specifically suggestions to task-add'ins will be much appreciated. Thank You.
Unfortunately there isn't a clean way to debug task addins.
It is possible to attach your debugger to the PDM process itself but its not trivial. Here's the gist of it as explained by Lee Young,
It depends on what portion of the task you're attempting to debug. If
you're looking to debug the task setup in the Administration Tool, all
you need to do is attach to the conisioadmin.exe process.
To debug an executing task, it gets a little trickier. Load up your
add-in as usual and select your machine to be the only machine that
will execute the task. (In the task setup.) Close the administration
tool. You'll need to create a symlink from the file in the plugins
directory to your debug dll. I personally use DirLinker. The plugins
directory is located at AppData\Local\SolidWorks\SolidWorks Enterprise
PDM\Plugins\VaultName.
In your sourcecode, place a messagebox.show in the OnCmd method and
place a breakpoint at that line. Once the task loads up, the task will
wait for the messagebox to be closed. When the messagebox is shown,
you can attach to TaskExecutor.exe and then you'll be able to debug.
If you're not hitting breakpoints, make sure you have the correct .NET
framework version selected when debugging.
If you're still not hitting breakpoints, EPDM probably loaded another
instance of your dll into the plugins directory.
For simple task addins, my approach is to debug via the method you described (reload it manually every time). Proper logging will help a lot here (Print ex.StackTrace on every exception).
For more complex tasks, you can create a separate 'debug' project that has some hardcoded (or dynamic) inputs and calls your code. This will get you close before testing in the PDM environment. A PDM task is basically a COM process on the client machine so that's pretty simple to mimic, aside from the actual PDM Task environment, which is full of bugs.
Hope this helps.
Is there a Cypress event hook that is called one time when either cypress run or cypress open are used?
I know that there is the plugins file on('before:browser:launch') that will run before cypress open (https://docs.cypress.io/api/plugins/browser-launch-api.html#Modify-args-based-on-browser) but will this also run before cypress run?
Not sure which event I should hook into to fire off some Node code before either cypress open or run are used.
Well, the support/index.js file is usually ideal for this kind of setup code. It does run before every spec file, not just once on startup, but you can usually put anything you need to set up in there.
It's also worth having a read of the CI docs if you haven't already, as they point out potential pitfalls with running processes before Cypress. If your code is a simple "run then exit successfully" scenario, you could always go with:
node foo.js && cypress run
It's when the node process is backgrounded that things can get a bit hairy.
I have a Windows Service written in a managed language (.NET Framework v4.0) that is currently running.
For some reason, I am able to rename the service main executable while the service is running.
I would suspect the file to be locked by Windows while the service is running, but this does not appear the case.
More interestingly, it's still present in the task manager after renaming.
I'm not complaining that this is possible, but I'm wondering why. Anyone have an explanation for this?
Taken from this answer on superuser,
and How can we overwrite EXE files while users are running them?,
executables that are not exclusively locked, can be renamed. The windows service manager obtains a file handle on the service executable, which it keeps open as long as the service runs, and is totally unaffected by a rename. It does not lock the directory entry itself. So the executable can be read by other processes, and the directory entry of the file can be renamed.
Implications:
After the rename, a different version of the file can be placed.
If you, or an automated update process, fail to place the new version, any service that points to that executable will fail to start next time (on restart/reboot)
If the new version has issues, like bugs or missing dependencies, the service may fail to start next time (on restart/reboot)
When you place the new version, but fail to restart the service immediately, then it will become active at any time in the future which is not something admins (and users) like in a production environment.
Recommendations:
Do not rely on this mechanism. Have your update process stop the service. Fail the update when your update process has insufficient permissions to do so. Then replace the executable and all dependencies, and restart the service.
I want to load the newer version of bundle to the target process but it's impossible because the bundle with same name already loaded. Changing CFBundleVersion or CFBundleShortVersionString of bundle doesn't work. The easiest way to do it is simply kill the target process and restart it. But I don't think that it's a best way to do it. So is there another way to do it?
I am facing the same problem with mach_inject. I don't see a straight forward solution without modifying mach_inject.
My solution is to create two bundles. Consider the 1st bundle to be a plugin manager for the real plugin. The plugin manager is very simple and hopefully never needs to be upgraded, it loads and unloads the original bundle with cleanup code added.
I am using Apple's NSBundle class to load and unload the plugin. Before unloading I call the principal class in the original plugin to have it clean up.
Unloading bundles written in objective C is dangerous. 2 & 4 are true in general.
Mach_override can not be undone, but can be called in the plugin manager and call code in the real plugin.
Categories and protocols are not safe to use in plugins meant to be unloaded.
You need to un-swizzle what you swizzled, and remember you can not remove methods, so when you reload the plugin, you need to replace (not add) the old dangling methods. You will need to check your swizzle code.
You need to invalidate timers installed, remove observers, and remove anything else added to the run loop.
I am attempting to debug a test, but it is not being executed
Warning 7/12/2012 9:16:53 AM Test run 'xxx#YYY 2012-07-12 09:14:52'
could not be executed. Timed out waiting for the process that runs
tests to initialize.
I however do not have any initializer code at all.
This was working previously, but I just modified Nuget in the solution to allow for Nuget Restore. I am unsure of whether this is the cause or not.
How can I debug through my test again?
I restarted my computer and my tests started debugging fine.
It looks like that Nuget Restore is the cause. In order to confirm it 100% disable Nuget Restore..
Also check if you have any setup methods in your tests (Check attribute [TestFixtureSetUp]). If so, put a breakpoint on them...