I am getting an error when calling fdopen and it sets errno to 22. I am using the exec command to call a child process. The child calls fdopen on file descriptor 4. The first child works and sends data back to the parent and errno is 0. After the parent creates the next child process, fdopen(4, "w"); is called again which is when errno is set to 22.
From what I've read, errno 22 for fdopen() could mean mode argument is incorrect. I also read that it could be an error from fnctl and that could mean a bad file descriptor. I specify file descriptor 4 and it works on the first child process. Could that be why errno is being set to 22 when I try to create another FILE*?
I cannot figure out when it works for one child process but not the next. Can anyone shed some light on this for me?
Here is the code:
int main(int argc, char* argv[])
{
cout << "Child " << argv[argc-1] << " starting" << endl;
//close(3);
if(argc < 1) fatal("Not enough arguments provided to ChildMain");
int id = atoi(argv[argc-1]);
//Child kid((int) *argv[1]);
cout << "Error before fdopen(): " << errno << endl;
FILE* out = fdopen(4, "w");
if(out == NULL)
{
cout << "Child ID: " << id << endl;
cout << "\tError: " << errno << endl << endl;
}
int ret = fprintf(out, "%d", id);
fflush(out);
return 0;
}
For the first child process, the file descriptor's number is 4. For the second child process, 4 is in use in the parent, so it gets some other file descriptor number. The child is either going to have to search for the file descriptor or the parent will have to communicate it to the child in the environment, on the child's command line, or some other way.
Related
Currently I am making a C/C++ program for the Linux Operating system.
I want to use a named pipe to communicate a PID (process ID) between two programs.
The pipe has been created and is visible in the directory.
The Get PID program says that the file descriptor returns 3, while it should return 0 if it could open the pipe. What am I doing wrong?
Get PID
// Several includes
using namespace std;
int main(int argc, char *argv[]) {
pid_t pid;
int sig = 22;
int succesKill;
int iFIFO;
char sPID[5] = {0,1,2,3,'\0'};
iFIFO = open("IDpipe" , O_RDONLY);
if(iFIFO != 0)
{
cerr << "File descriptor does not return 0, but: " << iFIFO << endl;
return EXIT_FAILURE;
}
read(iFIFO, sPID, strlen(sPID));
cerr << "In sPID now is: " << sPID << endl;
close(iFIFO);
pid = atoi(sPID);
cout << "The PID I will send signals to is: " << pid << "." << endl;
while(1)
{
succesKill = kill(pid, sig);
cout << "Tried to send signal" << endl;
sleep(5);
}
return EXIT_SUCCESS;
}
Send PID
// Several includes
using namespace std;
void catch_function(int signo);
volatile sig_atomic_t iAmountSignals = 0;
int main(void) {
pid_t myPID;
int iFIFO;
char sPID[5] = {'l','e','e','g','\0'};
myPID = getpid();
sprintf(sPID, "%d",myPID);
cout << "My PID is: " << sPID << endl;
iFIFO = open("IDpipe" , O_WRONLY);
if(iFIFO == -1)
{
cerr << "Pipe can't be opened for writing, error: " << errno << endl;
return EXIT_FAILURE;
}
write(iFIFO, sPID, strlen(sPID));
close(iFIFO);
if (signal(22, catch_function) == SIG_ERR) {
cerr << "An error occurred while setting a signal handler." << endl;
return EXIT_FAILURE;
}
cout << "Raising the interactive attention signal." << endl;
if (raise(22) != 0) {
cerr << "Error raising the signal." << endl;
return EXIT_FAILURE;
}
while(1)
{
cout << "iAmountSignals is: " << iAmountSignals << endl;
sleep(1);
}
cout << "Exit." << endl;
return EXIT_SUCCESS;
}
void catch_function(int signo) {
switch(signo) {
case 22:
cout << "Caught a signal 22" << endl;
if(iAmountSignals == 9)
{iAmountSignals = 0;}
else
{++iAmountSignals;}
break;
default:
cerr << "Thats the wrong signal.." << endl;
break;
}
}
Terminal output
Output
open() returns the newly created file descriptor. It cannot return 0 for the simple reason that the new process already has a file descriptor 0. That would be standard input.
The return value of 3 is the expected result from open(), in this case, because that would be the next available file descriptor after standard input, output, and error. If open() couldn't open the file descriptor, it would return -1.
But besides that, your code also has a bunch of other bugs:
sprintf(sPID, "%d",myPID);
// ...
write(iFIFO, sPID, strlen(sPID));
If your process ID happens to be only 3 digits long (which is possible), this will write three bytes to the pipe.
If your process ID happens to be five digits long (which is even more possible), this will write 5 bytes plus the '\0' byte, for a total of six bytes written to the five byte-long sPID buffer, overrunning the array and resulting in undefined behavior.
The actual results are, of course, are undefined, but a typical C++ implementation will end up clobbering the first byte of whatever is the next variable on the stack, which is:
int iFIFO;
which is your file descriptor. So, if your luck runs out and your new process gets a five-digit process id, and this is a little-endian C++ implementation, there is no padding, then the low order byte of iFIFO gets set to 0, and if the code got compiled without any optimizations, the iFIFO file descriptor gets set to 0. Hillarity ensues.
Furthermore, on the other side of the pipe:
char sPID[5] = {0,1,2,3,'\0'};
// ...
read(iFIFO, sPID, strlen(sPID));
Because the first byte of SPID is always set to 0, this will always execute read(iFIFO, sPID, 0), and not read anything.
After that:
pid = atoi(sPID);
atoi() expects a '\0'-terminated string. read() only reads whatever it reads, it will not '\0'-terminate whatever it ends up reading. It is your responsibility to place a '\0' that terminates the read input (and, of course, making sure that the read buffer is big enough), before using atoi().
Your logic appears to be incorrect.
if(iFIFO != 0)
should be
if(iFIFO == -1)
since open returns -1 on error. Otherwise it returns a valid file descriptor.
As I have just started with these concepts I might be missing out a few elementary things. I was trying to link the parent and the child processes (created by fork() function) using pipe. In the parent process, I wanted to write in the pipe descriptor (af[1]) and after closing up the write end, I wanted to read from the read end of the pipe with descriptor (af[0]) in the child process.
Here is my code:
#include <iostream>
#include <unistd.h>
#include <sys/types.h>
#include <cstdlib>
#include <sys/wait.h>
#include <sys/types.h>
#include <string.h>
using namespace std;
int main()
{
pid_t pid1;
pid1 = fork();
int af[2],nbytes,wbytes;
pipe(af);
char inside[20];
if(pid1 == -1)
{
cout << "No child process formed: " << getpid() <<endl;
exit(1);
}
else if(pid1 == 0)
{ cout<< "inchild" <<endl;
close(af[1]);
nbytes = read(af[0],inside,strlen(inside));
cout << "read bytes: "<< nbytes << endl;
cout << "child(read) inside descriptor: " << inside << endl;
close(af[0]);
cout << "in child's end" << endl;
exit(0);
}
else
{ cout<< "inparent" << endl;
close(af[0]);
wbytes = write(af[1],"Hello World",12);
cout<< "wrote bytes: " << wbytes<<endl;
cout << "Parent(write) inside string: " << af[1] << endl;
close(af[1]);
cout << "in parent's end" << endl;
exit(0);
}
return 0;
}
Then I was expecting this to run as follows:
Goes into the parent -> write string,
Close write end,
Goes into the child -> read string into inside,
Show result of string (Hello World),
Close read end.
But what I was getting here is this result:
inparent
shashish-vm#shashishvm-VirtualBox:~/Desktop$ inchild
read bytes: 0
child(read) inside descriptor:
A��M�N��sf�
in child's end
And it was still not terminating.
I was using Ubuntu 14.04 LTS on Oracle VM VirtualBox (32-bit O.S.). And I have no idea why it was doing like this. I knew it is the job of the scheduler to switch the processes but still pipe functionality of IPC was not working there. The write process occurred even if I removed close(af[0]) statement but still the reading was not happening properly.
You problem is that you open the pipe after calling fork. This means the parent and child have different pipes. You can fix it by moving the call to pipe before the fork to create a single linked pipe.
I am seeing unusual signal numbers (for example 50, 80 or 117) from the following code when waiting for a child process to terminate. I am only seeing this from one particular child process, and I have no access to the process source code and it only happens some of the time.
I want to know what these unusual values mean, given NSIG == 32, and where I can find some documentation in the headers or man pages?
Note that this code runs in a loop sending progressively more menacing signals until the child terminates.
int status, signal;
if (waitpid(m_procId, &status, WNOHANG) < 0) {
LOGERR << "Failed to wait for process " << name() << ": " <<
strerror(errno) << " (" << errno << ")";
break;
} else if (WIFEXITED(status)) {
m_exitCode = WEXITSTATUS(status);
terminated = true;
LOGINF << "Process " << name() << " terminated with exit code " << m_exitCode;
} else if (WIFSIGNALED(status)) {
signal = WTERMSIG(status); // !!! signal is sometimes 50, 80 or 117 !!!
terminated = true;
LOGINF << "Process " << name() << " terminated by signal " << signal;
} else {
LOGWRN << "Process " << name() << " changed state but did not terminate. status=0x" <<
hex << status;
}
This is running under OSX 10.8.4, but I have also seen it in 10.9 GM seed.
EDIT Modifying the code as below makes the code more robust, however sometimes the child process gets orphaned as I guess the loop doesn't do enough to kill the child process.
else if (WIFSIGNALED(status)) {
signal = WTERMSIG(status);
if (signal < NSIG) {
terminated = true;
LOGINF << "Process " << name() << " terminated by signal " << signal;
} else {
LOGWRN << "Process " << name() << " produced unusual signal " << signal
<< "; assuming it's not terminated";
}
}
Note this code is part of the Process::unload() method of this class.
From the OS X manpage for waitpid, when specifing WNOHANG, you should check for a return of 0:
When the WNOHANG option is specified and no processes wish to report status, wait4() returns a process
id of 0.
The waitpid() call is identical to wait4() with an rusage value of zero. The older wait3() call is the
same as wait4() with a pid value of -1.
The code posted does not check for this, which suggests to me that the value of status is likely junk (the value of the int is never initialized). This could cause what you are seeing.
EDIT: status is indeed only set when waitpid returns > 0.
So I'm writing a program that involves the creation of 2 sets of pipes so that a parent process can write to a child process & the child process can right back...
I have the following code for my child process:
if(pid==0){ //child process
cout << "executing child" << endl;
close(fd1[WRITE_END]);
close(fd2[READ_END]);
if(dup2(fd1[READ_END],STDIN_FILENO) < 0 || dup2(fd2[WRITE_END],STDOUT_FILENO) < 0){
cerr << "dup2 failed" << endl;
exit(1);
}
cout << "test output" << endl;
close(fd2[WRITE_END]);
close(fd1[READ_END]);
read(fd1[READ_END],buf,BUFFER_SIZE);
cout << "Child process read " << buf << endl;
execl("/bin/sort", "sort", "-nr", NULL);
} else { //... parent process
When I run my program, all I get as output from the child process is executing child but no test output.
However, when I remove the if-statement handling the dup2 calls, my output does include test output.
Any ideas as to why dup2 causes my child process to not finish terminating?
(and by the way, originally, my two dup2's were done in separate if statements... when I put the test output below the dup2(fd1[READ_END],STDIN_FILENO) < 0 test, it outputs, but not when I put it below the other dup2 conditional test, so I'm convinced that that's where my issue is)
Thanks in advance
The call to dup2(fd2[WRITE_END],STDOUT_FILENO) connects STDOUT (which is used by C++ cout stream) to your fd2 pipe. So 'test output' gets written to the pipe.
This is my code... I don't know why I'm get an error segment... could somebody explain the reason to me?
#include <iostream>
#include <string>
// Required by for routine
#include <sys/types.h>
#include <unistd.h>
using namespace std;
int globalVariable = 2;
main()
{
string sIdentifier;
int iStackVariable = 20;
pid_t pID = vfork();
if (pID == 0) // child
{
// Code only executed by child process
sIdentifier = "Child Process: ";
globalVariable++;
iStackVariable++;
cout << "PROCESO NUMERO"<<getpid()<<sIdentifier;
// printf("Proceso hijo: PID %d - PPID %d\n", getpid(), getppid());
cout << " Global variable: " << globalVariable;
cout << " Stack variable: " << iStackVariable << endl;
return (0);
}
else if (pID < 0) // failed to fork
{
cerr << "Failed to fork" << endl;
return (1);
// Throw exception
}
else // parent
{
// Code only executed by parent process
sIdentifier = "Parent Process:";
}
// executed only by parent
cout << sIdentifier;
cout << " Global variable: " << globalVariable;
cout << " Stack variable: " << iStackVariable << endl;
return (0);
}
Is this of use ? Note the caveats surrounding modification of variables.
The vfork() function has the same effect as fork(), except that the behaviour is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit() or one of the exec family of functions.
If you vfork() both processes are sharing an address space. You should probably only use vfork() if you are going to exec another process pretty much immediately in the child. The reason the system call was created was to avoid the overhead of copying every page in the parent process's address space only to have all those mappings discarded when the child exec's. For your case, use fork() instead.