Program crashed for calling execvp to compile a program with error?

Question

I use execvp to compile a program with error. But then error message pop on my terminal screen which should not happen because if execvp fails, it will only let child return with exit status. I do not understand why my terminal will actually show the error message?

My command array: {gcc, studentcode.c, ourtest3.c, -o, ourtest3.x, NULL} and in ourtest3.c, I made several errors on purpose. My calling function is like this:

commands = {"gcc", "studentcode.c", "ourtest3.c", "-o", "ourtest3.x", NULL};
int compile_program(Char** commands) {
  pid_t pid;
  int status;

  pid = safe_fork();
    if (pid == 0) { /*Child*/
      if (execvp(commands[0], commands) < 0) {
    exit(0);
      }
    } else { /*Parent*/
      if (wait(&status) == -1) {
    return 0;
      }
      if (WIFEXITED(status)) {
    if (WEXITSTATUS(status) != 0) {
      return 1;
    }
      } else {
    return 0;
      }
    }
  return 1;
}

ourtest3.c is this:

#include <stdio.h>
#include <assert.h>
#include "studentcode.h"

int main(void) {
  assert(product(2, 16) == 32

  printf("The student code in public07.studentcode.c works on its ");
  printf("third test!\n");

  return 0;
}

My program should have ended normally with return value 0, but instead, on my terminal window, it shows that

ourtest3.c: In function 'main':
ourtest3.c:19:0: error: unterminated argument list invoking macro "assert"
ourtest3.c:13:3: error: 'assert' undeclared (first use in this function)
ourtest3.c:13:3: note: each undeclared identifier is reported only once for each function it appears in
ourtest3.c:13:3: error: expected ';' at end of input
ourtest3.c:13:3: error: expected declaration or statement at end of input

Where is the code that prevents the message from appearing on the terminal? I don't see any code between `fork` and `execvp` that would set where the error message goes. — David Schwartz, Nov 25 '18 at 22:04
@DavidSchwartz What you mean? I thought if execvp executes fail then it will return, and then my child process will exit — kluo, Nov 25 '18 at 22:05
Yes, all of that is true. But your code doesn't do anything to change where the error message goes. You need to add code after `fork` and before `execvp` to do that. — David Schwartz, Nov 25 '18 at 22:05
There is a difference between the compiler finding an error in the code, and `execvp` failing. The compiler does not fail to run, as shown by its error report. — Weather Vane, Nov 25 '18 at 22:06
@DavidSchwartz I'm sorry but all the examples I have seen so far did not have any methods to handle the error message, they just check the child exit status code to see if it terminates normally. Could you make an example? — kluo, Nov 25 '18 at 22:07
@KaiweiLuo If you want to make any changes to the execution environment, you can do that after `fork` and before `exec*`. A common change is to set stdin, stdout, and stderr where you want them. Another common change is to `close` any file descriptors you don't want the new process to inherit. See my answer. Your `execvp` call is succeeding and is doing everything it is supposed to do. The compiler is not failing, it's finding errors just as it's supposed to. — David Schwartz, Nov 25 '18 at 22:08
Please edit your question now that it has been established that there is no crash. — Antti Haapala -- Слава Україні, Nov 26 '18 at 03:02

David Schwartz · Accepted Answer · 2018-11-25T22:12:29.460

If you want to change the stdin, stout, and stderr of a process, you need to do that. Otherwise, it just inherits them from its parent. After fork and before execvp, you probably want to open /dev/null and dup it onto file descriptors 0 and 1.

Here's some ugly code with no error checking:

if (pid == 0) { /*Child*/

  /* Redirect stdin and stderr to /dev/null */
  int fd = open ("/dev/null", O_RDONLY);
  dup2(STDIN_FILENO, fd);
  dup2(STDERR_FILENO, fd);
  close(fd);

  if (execvp(commands[0], commands) < 0) {
_exit(0);
  }

You can also redirect them to files or pipes if you want the parent to have access to the child's output.

Note the call to _exit. Do not get in the habit of calling exit from failing children. That has caused bugs with serious security implications in the past. Imagine if your process has something it's going to do when it exits (such as flush a buffer to a terminal or network connection). By calling exit in the child, you do that thing twice. You might think that you know that you have no such thing, but you can't possibly know that (in general) because you have no idea what your libraries might be doing internally.

Program crashed for calling execvp to compile a program with error?

1 Answers1