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().
Related
I'm writing a macOS launch daemon (in C++). It works for the most part, except that I am noticing some random crashes via SIGABRT (in the log.)
I've asked earlier about the use of the Core Graphics framework, which it turns out was not allowed in a launch daemon. I removed it, but I still get very rare crashes.
Thus I'm wondering which of the following frameworks am I allowed to use from a launch daemon?
There's no technical restriction on specific frameworks you're allowed or not allowed to link. Merely linking a library will not cause crashes. Some APIs need to be called from specific contexts, such as much of Core Graphics only making sense if a process is part of a windowing session, as you've found out. But even there, some of the off-screen drawing APIs which don't interface with the windowing system directly ought to work from a Launch Daemon context.
If you're seeing crashes calling specific APIs, you'll need to investigate those one by one. If you're seeing "random" crashes, I suspect you have a bug (memory overwrite? multithreading error?) in your code. Note that Apple's toolchain provides a bunch of different diagnostic options which you can use even when not running in the debugger, such as ASan, UBSan, and Thread Sanitizer. These may help you track down issues.
As you've specifically tagged this question with the IOKit tag and it's shown in your screenshot, I'll add that using IOKit from a launch daemon is very common. It's even possible to use IOKit matching events as a launch trigger for the daemon using XPC events/xpc_set_event_stream_handler - this way, your daemon can be started on-demand when a specific (type of) device is connected, for example. (As opposed to starting up at every system boot and consuming system resources even if it's not needed or doing anything.)
I'm attempting to resolve this weird problem with our OS X application.
As part of it's normal operation, it starts a long running background process — specifically a Web server, written in node.js.
After some time running, the background process shows up in the activity monitor as "Not Responding".
It's still functioning normally though, responding to requests from the web browser and not eating a high percentage of CPU or anything.
I would like to understand what exactly might be causing this status to be displayed, since it's not even a GUI application in the first place. What exactly does OS X use to determine if a command line application is not responding, if it doesn't have a Cocoa event loop?
Is it possible to flag it somehow as a background process so that the system does not query it for responses?
Thanks in advance.
Update: Just checked, the same seems to happen when launching the task from the command line. What makes a background app "Not respond" on the activity monitor?
Okay so as sergio pointed out in his comment, it was indeed something specific to Node.JS.
The dev responsible for Node.JS portion of our app was able to trace back the source of the problem to the usage of the process.title property in Node.JS.
It looks like the implementation of process.title in libuv does a lot of Core Foundation tricks to set the process title, so these are probably getting the process flagged as a GUI app by whatever heuristics the Activity Monitor uses to tell Cocoa apps apart from CLI apps.
We have filed a bug report on libuv about this, but for now we're skipping process.title as simply setting it causes the server to show up as "not responding" on the Activity Monitor after a couple minutes.
Update: This is now fixed in libuv as of this commit. It still hasn't propagated to a node release yet.
According to Apple's Process Manager Reference, GetCurrentProcess, GetFrontProcess (et al.) are deprecated in OS X 10.9 and causes the "not responding" issue in Activity Monitor (my observation).
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.
I have an application that is hosting some unstable third-party code which I can't control in an external process to protect my main application from nasty errors it exhibits. My parent process is monitoring the other process and doing "the right thing (tm)" when it fails.
The problem that I have is that Dr. Watson is still detecting crashes in the isolated process and attaching to the processes on the way down to take a crash dump. This has the two problems of:
1. Dramatically slowing down the time that it takes for me to detect a failure because the process stays alive while the crash dump is being taken.
2. Showing annoying popups to the user asking if they want to submit the error reports to Microsoft.
Clearly I would prefer to fix the bugs in the child process, but given that it isn't an option, I would like to be able to selectively disable Dr. Watson (and Windows Error Reporting in Vista+) for that process.
I am running some of my own code in the process before handing off to the untrusted bit, so if there is an API that I can call that affects the current process that would be fine.
I am aware of: http://support.microsoft.com/default.aspx/kb/188296 which would disable Dr. Watson for the entire machine. I don't want to do that because it would make me a bad citizen to trash a machine-wide setting.
I am also aware of the WerSetFlags option in Vista+ that would seem to disable windows error reporting for the current process, but I need something that will disable Dr.Watson on earlier OS versions.
The good doctor is invoked when a process does not handle a certain exception. Therefore, the common way to go would be to handle all exceptions yourself. In your case, it is much harder since you don't own the crashing process code. What you can do then, is to inject your code into the other process at runtime, and install an exception handler that will swallow the exception causing the crash. When caught, gracefully shut down the process.
There are quite a few questions here talking about injecting code into another process. As for the crash handler, you can either set an unhandled exception filter, or add a vectored exception handler. Note that for the latter, you'll have to be careful not to swallow legit exceptions that are in fact handled inside the other process, namely find a way to recognize the crashing exception and make sure it is the only one you handle.
You want to disable the GPF popup: http://blogs.msdn.com/oldnewthing/archive/2004/07/27/198410.aspx
How to reload a crashed process on Windows? Of course, I can run a custom monitoring Win service process. But, for example, Firefox: it doesn't seem to install such a thing, but still it can restart itself when it crashes.
On Vista and above, you can use the RegisterApplicationRestart API to automatically restart when it crashes or hangs.
Before Vista, you need to have a top level exception filter which will do the restart, but be aware that running code inside of a compromised process isn't entirely secure or reliable.
Firefox constantly saves its state to the hard disk, every time you open a tab or click a link, or perform some other action. It also saves a flag saying it shut down safely.
On startup, it reads this all back, and is able to "restore" based on that info.
Structured exception handling (SEH) allows you to catch program crashes and to do something when it happens.
See: __try and __except
SEH can be very dangerous though and could lead to your program hanging instead. Please see this article for more information.
If you write your program as an NT service then you can set the first, second and subsequent failure actions to "Restart the service".
For Windows 2008 server and Windows Vista and Windows 7 you can use the Win32 API RegisterApplicationRestart
Please see my answer here for more information about dealing with different types of program crashes.
If I recall correctly Windows implements at least some subset of POSIX and so "must" have the signal interface (things like SIGKILL, SIGSEGV, SIGQUIT etc.).
I've never done this but on linux, but you could try setting the unexpected termination trap with signal() (signal.h).
From quick scan of docs it seems that very few things can be done while handling signal, it may be possible that even starting a new process is on forbidden list.
Now that I've thought about it, I'd probably go with master/worker pattern, very simple parent thread that does nothing but spawns the worker (that does all the UI / other things). If it does not set a specific "I'm gonna die now" bit but still dies (parent process always gets message / notification that spawned process died) then master respawns the worker. The main theme is keep master very simple and hard to die due to own bugs.