CODEWITHSUNDEEP
clinuxprocessopenwrt
Anis_Stack
Anis_Stack

Reputation: 3442

segmentation faults when process launched in foreground is stopped with Ctrl+C

I develop program for openWrt platform, when I launch the process with option foreground, the process runs well.

/usr/sbin/myprocess -f -b 

(" -f, --foreground        Run in the foreground\n")  
(" -b, --boot              Run with boot event\n")

At the end I stop the process with command Ctrl + C. This leads to segmentation faults.

In my main program the code used for that is : 

 void main ()
    {
    ..........
    ..
   bool foreground = false;
    while (1) {
        c = getopt_long(argc, argv, "fb", long_opts, NULL);
        if (c == EOF)
            break;
        switch (c) {
            case 'b':
                start_event |= BOOT;
                break;
            case 'f':
                foreground = true;
                break;
          } 
      }
    pid_t pid, sid;

        if (!foreground) { // *fourground false* 
            pid = fork();
            if (pid < 0)
                exit(EXIT_FAILURE);
            if (pid > 0)
                exit(EXIT_SUCCESS);

            sid = setsid();
            if (sid < 0) {
                D("setsid() returned error\n");
                exit(EXIT_FAILURE);
            }

            char *directory = "/";

            if ((chdir(directory)) < 0) {
                D("chdir() returned error\n");
                exit(EXIT_FAILURE);
            }
        }

    ..........


    }

I wonder if a process launched in foreground mode must be stop with a specific way. How to modify my C code to avoid this segmentation fault ?

Upvotes: 0

Views: 307

Answers (1)

abligh
abligh

Reputation: 25119

Compile your program with -g, then run your program under gdb. If this is on openwrt you might need to use remote gdb. That will tell you where the segfault is.

You will need to read this page to ensure that you know how to pass your ^C to the program, i.e. use

handle signal int nostop noprint pass

before you run.

You've given us no debugging information to go on, but I'm guessing you have a problem either in your signal handler for SIGINT, or in your exit code (assuming you trap the signal), or in things invoked at __atexit or similar. Occasionally memory corruption can cause this too when exit routines try to clean up - try running under valgrind.

Upvotes: 1

Related Questions