Parent process has successfully created named pipes for each helper process using
mkfifo(pipe_name, S_IWUSR | S_IRUSR)
Then it launches helpers, and opens each pipe by:
::open(pipe_name, O_WRONLY);
On the helper process side, it opens the reader side of the pipe by:
::open(pipe_name, O_RDONLY);
And there are some reading and writing going on afterwards.
The program almost always works, expect in occasional cases, it stucks!
And when I attach the processes to ddd, I see that both the main and helper processes stuck at opening the pipe.
I have been confused by this phenomenon by days and can't figure it out. Plus I've no idea how to debug this: how do I have the processes time out and return the error code?
Related
I am trying to detect / get notified whenever a new process is created in MAC. The easiest way is to poll all the processes and see if a new process has been launched but that is too time consuming and i wanted to know if i could somehow get some notification whenever a new process is launched using "forked" and "execve". Here is what i have already found :
On how a new process is launched in MAC :
OS X is a variety of Unix. New processes are created with the fork() system call. This creates an almost identical copy of the process that makes the call (the difference is that fork returns 0 in the child and the pid of the child in the parent). It's then normal to use one of the exec() syscalls in the child to transform the child into a process running a different executable.
How is new application launched on Mac?
On getting the list of all processes through polling
http://www.cocoabuilder.com/archive/cocoa/92971-bsd-processes-with-code.html
I have also gone through kAuth kext thing, but it seems beyond my level unless i have some example code for made simple so that i can understand on how to generate the kext and use it in a sample app.
https://developer.apple.com/library/mac/technotes/tn2127/_index.html
NSWorkspace has a notifier but that is only true for applications and not for all processes.
Any tutorial/ sample code with some basic understanding on how to go about this problem, will be greatly appreciated.
I'm planning on developing a Monopoly game using a Console application in VB.NET, but with a separate GUI (probably a Forms application) that displays the state of the Monopoly board based on the information in the Console application, so that it can be ignored or used as the players wish. I've been looking into ways of sending information between two programs, and came across Pipes, except they seem complex and I'd like to use a different method if I can avoid it. The following is the methodology I'm currently considering to send information - I'd like to know if there is any way I could improve this methodology, or if you think it's completely stupid and I should just use Pipes instead -
Program 1 is the Console application which controls everything: the state of the game depends on the Console. Program 2 is the GUI/Forms application which follows instructions sent by Program 1 and displays the board accordingly. Program 1 and Program 2 communicate using two text files, Command.txt and CommandAvailable.txt. When something changes on Program 1 - e.g. a player makes a move - a command string is made and added to a queue. Program 1 continually checks CommandAvailable.txt to ensure that the file is empty, and if so, it clears Command.txt and then appends every command string in the queue to Command.txt. When it has finished, arbitrary text is added to CommandAvailable.txt, e.g. "CommandAvailable".
Program 2 continually checks CommandAvailable.txt until it is not empty, meaning that Program 1 has added at least one command to Command.txt. Program 2 then reads every instruction on Command.txt and adds it onto a queue on the other side. CommandAvaiable.txt is then cleared, which will permit Program 1 to add more Commands to Command.txt (because it only adds commands when CommandAvailable.txt is empty and hasn't already been marked by itself.) A separate thread on Program 2 empties the queue of command strings, parses them and executes them.
For example, in the Console, Player 1 may move to Trafalgar Square (or whatever the square would be called.) Program 1/Console would add the Command "move player1 trafalgar_square" to the queue, then check CommandAvailable.txt, and if it is empty, add all the commands in the queue to Command.txt. Program 2/The GUI would check CommandAvailable.txt and as it had been marked by Program 1, read the command, add it to the queue, and then move a picturebox that represents Player 1 to a square.
Please let me know if you think this methodology could be improved, or if you think it's simply stupid and there are far better alternatives or that I should just use Pipes instead. I'm going to be using VB.NET.
Ok, my task is to write a C program that would run a particular process in background or foreground depending on whether & is the last argument or not. On googling, I found out that to run a process in background all you have to do is skip the line 'wait(&status)!=pid' in the parent process. The child process will run in the background.
That brings me to a query about fork(). When I type fork(), a child process is created. Now, my question is - Is the control of the program, right after calling fork(), passed to the child process before the parent process ALWAYS? Is it possible that the control is passed to parent process first? Or do both the processes run in parallel?
If the processes run parallel, I can see how skipping the wait part might work but not if the processes run sequentially.
For example:-
pid=fork()
if(pid==0) execvp("ls",argv);
else if(pid>0) return pid;
If suppose, the child process runs first. "pid==0" evaluates to true, execvp is called, ls is overwritten over the child process. "ls" terminates, control transfers to parent process. Here the wait command is not there and ls terminates and only then we go back to the parent process. Background working does not happen.
If parent process runs first, it sees that pid>0, control is transferred to main function. Since the wait command is not there, child process is not run at all, not at least until the parent process terminates.
So, how does it actually work? A few of my concepts might be way off the mark. if they are, kindly correct me.
Thanks.
Both parent and child processes are treated equally by the scheduler. You must not assume any predefined execution order and program synchronization if you need it.
Background
We have a .NET WinForms application written in C# that interfaces to a handheld store scanner via a console application. The console application is written in good ol' VB6-- no managed code there. The VB6 application consists of several COM objects.
The .NET WinForms application refreshes the data in the scanner by invoking the console application with the right parameters. When the console application starts, it pops up a modal form reminding the user to place the handheld device into its cradle.
Problem
A customer has a bizarre situation in which the call to start the console application appears to hang before it displays the reminder form. If the user presses any key-- even something innocent like Shift or Alt-- the application unfreezes, and the reminder form appears. While it is hung, the CPU usage of the console application is very high.
We have obtained a memory dump from the command line application using ProcDump. I have some experience debugging managed dump files, but this VB 6 dump is strange to me.
We captured several full memory dumps in a row. In some of them, there appears to be COM glue stacks. For example, several dump files show a call stack like this:
msvbm60!BASIC_DISPINTERFACE_GetTICount
msvbm60!_vbaStrToAnsi
msvbm60!IIDIVbaHost
msvbm60!rtcDoEvents
msvbm60!IIDIVbaHost
msvbm60!BASICCLASS_QueryInterface
[our code which I think is trying to create and invoke a COM object]
It doesn't help that the only symbols I have are from our code. The Microsoft symbol server does not have a PDB file for msvbm60.dll (or at least not from their version which is 6.0.98.2).
Questions
I am suspecting there may be some COM threading issue that is happening only on their system.
1) How can I determine the thread state of each thread in a dump file? If this were a managed dump file, I would look at !threads and then !threadstate to figure out the thread states. There is no managed code, so I can't use sos.dll. I didn't see any hints using ~ and !teb.
2) Is there a way to see what COM objects have been created in a dump file? Again, in a managed dump, I can do a !dumpheap to get a list of managed objects. Is there something similar I can find for COM objects?
3) Can I determine the threading model of COM objects in the dump file?
You can dump thread state by using command:
~*
this will not display 'background' as a state, you will only see running, frozen or suspended.
I'm not sure how you can get information from COM objects, I have never tried but will investigate and get back to you, regards to threading model it will be difficult to infer that without painful monitoring of application state after stepping through and even with that, when you step through all other threads will run unless you use .bpsync 1 which syncs all threads to the current one, but that could cause a hang (e.g. gui thread has now been told to freeze) so I think it will be difficult unless you have access to the source code.
I can only answer question 1. Use !runaway to find the thread or threads consuming the CPU. To get all thread stacks use ~*kb1000.
If I launched a shell script using AuthorizationExecuteWithPrivileges what would be the easiest way to kill the script and any other processes that it spawned.
Thanks
It's running as root, so you can't kill it from a regular-user process. You're going to have to ask it nicely to exit on its own.
Apple has sample code that uses stdout to pass the PID back to the caller.
Use the communications pipe that AuthorizationExecuteWithPrivileges() returns by reference in its last argument, FILE **communicationPipe, to send a message to the child process that asks it to take itself and its descendants out. It can then kill itself and all its descendants using kill(0, SIGINT), or, if more drastic measures are required, SIGKILL.
The message you use can be as simple as closing the file while the child waits for the file to close; at that point, it knows you're done talking to it and it's time to take itself out.
There are some caveats about the descendants that will actually receive this message, for which see the kill(2) manpage. The caveats mostly won't matter so long as the process you started via AEWP hasn't dropped privileges, though one implicit issue is that this approach won't work if any child processes have put themselves in a new process group.