if((sem_init(sem, 1, 1)) == 1) perror("error initiating sem");
If I include this line of code my program simply starts and exits. I just started learning how to use semaphores. I'm using cygwin and when this line is commented out the printf's ABOVE this print to console but when include this, nothing happens.
I did the following to get cygserver going-
CYGWIN=server
ran /bin/cygserver-config
ran /usr/sbin/cygserver
for the config it said the cygserver is already running
And for the sygserver it saids-
initailaizing complete
failed to created named pipe: is the daemon already running?
fatal error on IPC transport: closing down
Any ideas?
I figured out what was wrong. I was using data(struct) = shmat() before I was assigning any memory to data. That for some reason was stopping my 'printf' from working.
Related
I'm on a VirtualBox with Ubuntu 18.10 installed on, and I'm new using it. My code creates 100 forked child that works on a shared memory. SOMETIME I get this message
Sender(Pid = (childPID)) terminated with status 0x008B.
Searching in the web I found that could be a SIGSEGV error. Is it true?
Finally, is there any way to find WHERE the code fails in over 1000 lines? I tryed using this Guide: http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html to find the error with gdb but my terminal says me that I have "No Stack". I'm totally new with this kind of problems, any hint will be appreciated.
Sender(Pid = (childPID)) terminated with status 0x008B.
Searching in the web I found that could be a SIGSEGV error. Is it true?
Yes, that indicates termination by signal 11 (0xB).
Finally, is there any way to find WHERE the code fails in over 1000 lines?
I'd run the program with valgrind.
I am developing a shared-library L which is used by an other system service S. In my program I need to call a small program P, which uses Oracle shared libraries.
The small program P is packaged and installed correctly, and the environment variables, such as PATH,LD_LIBRARY_PATH and ORACLE_HOME are set correctly. I can run P on command line without any problem.
But when service S call my library L which runs the small program P via system(), it gives me a return code 127. I've googled, people says it's a command not found error, probably a PATH issue, so I've tried with absolute path like the following
int status = system("/usr/bin/myprog --args");
if (status < 0) { ... }
ret = WEXITSTATUS(status);
ret still equals 127.
Any idea please ? Thank you.
Update
It turns out that the service S is launched via command daemon, in its init.d script, I have found the following line:
daemon /usr/bin/myserv
if I export explicitly all my environment variables (PATH, ORACLE_HOME and LD_LIBRARY_PATH), it works. I don't know if daemon eliminates my environment variables.
this excerpt from the man page for system()
-----------------------------------------------------------------
The value returned is -1 on error (e.g., fork(2) failed), and the
return status of the command otherwise.
This latter return status is
in the format specified in wait(2).
Thus, the exit code of the command
will be WEXITSTATUS(status).
In case /bin/sh could not be executed,
the exit status will be that of a command that does exit(127)."
-----------------------------------------------------------------
indicates the 127 means that /bin/sh could not be executed.
Well, I have found the answer:How to make unix service see environment variables?,the environment variables are removed in init.d script.
I am invoking make from my C program, which intern executes another program. I am redirecting both the standard out and standard error to a file. However, when the program run by make terminates due to segmentation fault, a core dump is generated and printed to the console (standard out) of the main program that is invoking make.
How can I get around this and not have the core dump show on the console?
The following is my code to invoke make :
int pid = fork();
if(pid==0){
dup2(make_logs, 1);
dup2(make_logs, 2);
close(make_logs);
execvp (args[0],args);
}
Where make_logs is the file opened using 'open'
Thanks
I would try to fix the core dump rather than suppressing the message, but the message about the segmentation fault is being generated by the shell (which detects the exit value of the child and recognize a core dump situation), so you can suppress it by installing your own program that handles the fork() and wait() rather than having the shell do the work.
To suppress the core dump, just use limit coredumpsize 0.
Sample of suppression (sloppy code; you should really be checking for errors):
#include <sys/types.h>
#include <sys/wait.h>
main( int argc, char **argv )
{
int pid;
if( (pid = fork() ) > 0 ) wait( 0 );
else if( pid == 0 ) {
execl( "program-that-cdumps", "program-that-cdumps", 0 );
perror("failed in execl");
} else perror("failed in fork");
}
Read core(5) and signal(7) man pages.
Compile all your programs with gcc -Wall -g. Then use
file core
to understand which binary dumped the core. It probably says something like core dump from foo to tell you that program foo dumped the core. Then, start a post mortem debugger on it:
gdb foo core
and use the common gdb commands (notably bt to backtrace, p to print, etc...).
The message dumped core is given by some shell (or perhaps by make when it is acting like a shell). I don't think that the core file is output to stdout (it is a big binary file).
If you wish to avoid the core (which IMHO is a bad idea, a core dump is a good symptom of something wrong), you could call the setrlimit(2) syscall with RLIMIT_CORE and a 0 limit after your fork and before the execvp. I believe you should not do that (or at least have some way of configuring that setrlimit is not called: sometimes you really need the core dump to debug the problem).
You should fix the problem which gives the core dump, not try to avoid the dumped core message!
If you run make on a user provided Makefile so that the core dump is from a user program, you really want to keep the user informed that a core did happen, so you should keep the core dumped message.
Having read the relevant docs and tutorials and found a similar question, I am still unable to proceed. My aplogies in advance if this is a common question. I did searches but I wasn't really sure what I was looking for...
I am experimenting with the Libssh for C in Debian.
rc = ssh_channel_request_exec(channel, "ls -l");
if (rc != SSH_OK) {
ssh_channel_close(channel);
ssh_channel_free(channel);
return rc;
}
This returns SSH_OK to state that the command was sent successfully. As I understand from a similar question this is because the return listens for the successful 'sending' of the command. The return does not listen to see if it has been successfully executed.
My questions is, how can I:
Execute the command (which by the above function presently does not execute it merely sends the command)
Listen for it's execution
print the returning output?
I am aware of the ssh_channel_read() function but as the command never executes, I usually get the output
Read (256) buffered : 0 bytes. Window: 64000
Take a look at examples/exec.c in the libssh source code!
I have a command line app and have the code
chdir("/var");
FILE *scriptFile = fopen("wiki.txt", "w");
fputs("tell application \"Firefox\"\n activate\n",scriptFile);
fclose(scriptFile);
and when I run it in Xcode I get an EXC_BAD_ACCESS when it gets to the first fputs(); call
Probably the call to fopen() failed because you don't have write permissions in /var. In this case fopen() returns NULL and passing NULL to fputs() will cause an access violation.
Are you checking to make sure the file is properly being opened?
Normally you will need superuser privileges to write into /var, so this is likely your problem.
I already answered this in the comment and a couple people have told you what you've done wrong as answers but I decided to add a little sample code with error checking:
chdir("/var");
FILE *scriptFile = fopen("wiki.txt", "w");
if( !scriptFile ) {
fprintf(stderr, "Error opening file: %s\n", strerror(errno));
exit(-1);
} else {
fputs("tell application \"Firefox\"\n activate\n",scriptFile);
fclose(scriptFile);
}
Now you will see an error if your file is not opened and it will describe why (in your case, access denied). You can make this work for testing by either 1) replacing your filename with something world writeable, like "/tmp/wiki.txt"; or 2) running your utility with privileges sudo ./your_command_name.