Is there a way to monitor processes in the Mac OS X before they Start & End?
I have a dynamic which I would like to inject in few selected processes before the start, so that hooking can be performed. And would like to do the reverse when application quits, i.e. when application quits I want to unload that library from those process & thus perform unhooking.
What can be the best solution for my situation?
In Carbon, you can register for the kEventClassApplication/kEventAppLaunched event. For quitting, I think looking for an event might not be the best approach; you may not be able to respond in time before the process actually ends. It may be better to have your injected code install an atexit handler or something.
When application quits it unload's that library from those process automatically. I had a bug which prevented calling of destructor from dylib.
Related
Heres a simple question - is there anyway that a non-console (ie a CWinApp) application can receive and process CTRL+BREAK, it would appear SetConsoleCtrlHandler doesnt do the job nor the installation of signal handlers?
I unfortunately am working with a legacy CDialog based app which is run under the control of Microsoft HPC and HPC uses CTRL+BREAK to cancel the program (assuming i guess that nobody in their right mind would have a non-console app running in the background)
Cheers.
Calling AttachConsole with ATTACH_PARENT_PROCESS should do the trick. This will attach your process to the HPC console so that it can receive the control-break signal. You should probably do this before calling SetConsoleCtrlHandler.
If that doesn't work, try AllocConsole instead. If HPC doesn't have a console of its own, it might be assuming that the sub-process will have created a new console group (this happens automatically for console-mode applications) in which case it will be sending a control-break signal to the sub-process PID. If so, it shouldn't matter whether the console group was created automatically or explicitly.
You may wish to start by making sure that HPC is indeed sending a control-break signal (presumably via GenerateConsoleCtrlEvent) by checking that SetConsoleCtrlHandler works as expected for a console-mode application. If it is calling TerminateProcess instead then there is nothing you can do about it.
I'm developing multi-threading application on mac os. I'm faced with next problem: when i'm trying to debug with xcode-cocoa application(NOTE: console application doesn't have same problem), my threads are returning with errors in next calls: kevent(), semaphore_wait(), semaphore_timedwait() with EINTR (for kevent) and KERN_ABORTED (for semaphore_*). I think this is due to lldb work.
The problem is: i can't debug my application as i'm crashing after receiving such events. If i will do their handling(just make recall of same function) then my application is working very strange. Anyway I can't(I can, but it's very ugly) make good handling for such situation when my semaphore_timedwait() interrupting as i should "remember" time before i have gone timedwait() to make new timedwait() correct.
So, solution for my problems would be if I could disable for current thread "interrupting" - ability to be interrupted from another thread\process, that my functions will not return if lldb will send some signal. Is it possible on mac os?
Few notes:
In some debugegrs (I know gdb supports that) you can say whether all threads or only the one are stopped on the breakpoint.
Generally, you should be ready in your code a signal comes even if it is more work.
In multithreading application you can consider blocking the signals in most (helper) threads, so the signals shall be handled in a thread which is ready for that. See pthread_sigmask().
I've got a program that calls SetClipboardViewer at startup to register for clipboard change notifications. At shutdown time, it will call ChangeClipboardChain to remove itself from the chain correctly.
This is all great as long as the program runs normally. But that's got me wondering, what happens if the program gets aborted, either by me killing it under the debugger, by a crash, or by the user killing the process because something went wrong? Then the cleanup never happens. Can that cause trouble for the system somehow?
Specifically, I know Windows can remove my viewer without trouble because it's a handle and Windows can clean up all handles when a process terminates, but will this cause the next value downstream in the chain, that I was holding a reference to, to get lost somehow?
Yes, failure to remove yourself from the chain will break the chain. Deadly sin #2. Please read the whole list to be sure that you're following all of the rules.
http://www.clipboardextender.com/developing-clipboard-aware-programs-for-windows/6
Lots of apps suffer from this, including the Delphi IDE. i.e. if Delphi crashes in certain ways, it'll kill the clipboard chain (D2005 anyway).
Consider using Vista style notification on Vista/Windows7.
Is there any way to suspend an application execution, store its process image to a file, and restore it later (keeping the application as it was at the moment of suspension)?
What I want to do is something like an "hibernate" for applications on WinXP.
Is there any application capable of doing this?
What I have so far, is a virtualized system using vmware, where I can suspend and resume applications, but to accomplish the task, I have to suspend the whole virtualized system.
Thank you in advance.
I could imagine if you had an object that would maintain the state of your application and always base the UI on that state object.
When your application is closing, that state object could be serialized/saved. When the application starts back up, it would load/de-serialize your state object and bring your UI back to where you left it.
I can only think of one example when this is done. Unfortunately, it's not done under favourable conditions! You can set up the operating system to create a memory dump whenever a process crashes. This crash dump can then be loaded into a debugger, which can see the exact state of every variable in the process at the time it crashed. I presume you want something similar, but without the process crashing? ;-)
Have you looked at VMWare ThinApp? It sounds like it does what you're trying to achieve...
I'd like to detect when someone terminates a suspended debugged process without informing the debugger. (For example, get to a breakpoint in a console app, and close the app's console window.) The process goes into a zombie-like state and cannot be interacted with further until the debugger releases its hold.
This state appears to set the PROCESS_EXTENDED_BASIC_INFORMATION::IsProcessDeleting flag when gathering information on the process via NtQueryInformationProcess, but both the flag, structure, and function are effectively undocumented and marked "do not use" on MSDN.
Is testing this flag reliable? Is there a better, "official" API I can use?
(Yes, I know IsProcessDeleting is also set when the process is (surprise, surprise) shutting down normally. This is not a problem from my perspective.)
Nope, not that I can see. NtQueryInformationProcess isn't going away anytime soon though, if that function was removed hundreds of apps would be broken by it.