longjmp() from signal handler

Question

I'm using the following code to try to read an input from user and timeout and exit if more than 5 seconds pass. This is accomplished through a combination of setjmp/longjmp and the SIGALRM signal.

Here's the code:

#include <stdio.h>
#include <setjmp.h>
#include <unistd.h>
#include <string.h>
#include <sys/signal.h>

jmp_buf buffer;

// this will cause t_gets() to return -2
void timeout() {
    longjmp(buffer, 1);
}

int t_gets(char* s, int t)
{
    char* ret;
    signal(SIGALRM, timeout);
    if (setjmp(buffer) != 0)
     return -2; // <--- timeout() will jump here
    alarm(t);
    // if fgets() does not return in t seconds, SIGALARM handler timeout()
    // will be called, causing t_gets() to return -2
    ret = fgets(s, 100, stdin);
    alarm(0);
    if (ret == NULL ) return -1;
    return strlen(s);
}

int main()
{
    char s[100];
    int z=t_gets(s, 5);
    printf("%d\n", z); 
}

Now, my question is if there's anything that can go wrong with this function. I've read that calling longjmp() from a signal handler can have undefined behaviour, what exactly is it refferring to?

Also, what if the alarm triggers right after fgets() returns, but before alarm(0) is called? Will it cause the function to return -2 even if the user did input something?

LATER EDIT: I'm not interested in ways to improve the code. I just want to know how it might fail.

Answer 1

From the man page for longjmp:

POSIX does not specify whether longjmp() will restore the signal context. If you want to save and restore signal masks, use siglongjmp()

Your second question: Yes, the function will return -2 because longjmp() will cause it to go to the setjmp(buffer) part, but the timing will have to be very precise.

Answer 2

I don't think you need to use setjmp/longjmp. fgets should be interrupted by signals (errno is set to EINTR), though you'll probably need to use sigaction(...) rather than signal(...) to ensure SA_RESTART is clear.

void timeout(int) {
   // doesn't actually need to do anything
}
int t_gets(char* s, int t)
{
    char* ret;
    struct sigaction action = {0};
    action.sa_handler = timeout;
    sigaction(SIGALRM, &action, NULL);
    alarm(t);
    // if fgets() does not return in t seconds, SIGALARM handler timeout()
    // will be called, interrupting fgets and causing t_gets() to return -2
    ret = fgets(s, 100, stdin);
    // even if the alarm is called after fgets returns, it won't erroneously cause
    // t_gets to return -2
    int err = errno;
    alarm(0);
    if (ret == NULL) { 
        switch (err) {
        case EINTR:
            return -2;
        // add other cases as warranted
        default:
            return -1;
        }
    }
    return strlen(s);
}

Answer 3

About your second question you can add a lock that blocks the return -2 when the main thread has passed the fgets call.

Answer 4

what if the alarm triggers right after fgets() returns, but before alarm(0) is called?

You could initialize ret (to NULL, possibly) and check that in the body of the if(setjmp()) statement:

/* NOT TESTED */
int t_gets(char* s, int t)
{
    char* ret = NULL;
    signal(SIGALRM, timeout);
    if (setjmp(buffer) != 0) {
        // timeout() will jump here
        if (ret == NULL) {
            return -2;
        } else {
            goto end_of_function;
        }
    }
    alarm(t);
    // if fgets() does not return in t seconds, SIGALARM handler timeout()
    // will be called, causing t_gets() to return -2
    ret = fgets(s, 100, stdin);
end_of_function:
    alarm(0);
    if (ret == NULL ) return -1;
    return strlen(s);
}

Answer 5

When it comes to what could go wrong when behavior is undefined, the only answer you can count on is "anything, including nothing". Maybe nothing goes wrong, maybe you get a segfault, maybe you get nasal daemons.

More specific answers depend on which system and release you're working with. For example, on Linux distros (at least, all since 2000), the kernel performs some tasks after the signal handler returns. If you longjmp, you'll probably leave junk on the kernel stack that could cause problems later on, such as erroneously returning to the code your program was executing when the signal was caught (the call to 'fgets' in the example). Or not.

Calling longjmp within a signal handler can also (in general, but probably not in your example) introduce a security hole.

Answer 6

You can replace the longjmp/setjmp with siglongjmp/sigsetjump and then won't have the issue of the signal context being undefined after the jmp. You may not really care here since you aren't explicitly changing the mask. I forget if the mask is altered by signal call itself.

What is perhaps the bigger issue is ensuring that your code is signal safe. For example, does fgets() acquire any mutex (perhaps implicitly as a part of a malloc call)? If it is and your timer goes off while that mutex is held, your program is toast next time you try to do a heap allocation.

Answer 7

Another nice (or ugly depending on your perspective) way to make fgets bail out would be:

int tmp = dup(0);
ret = fgets(s, 100, stdin);
if (!ret && errno == EBADF) clearerr(stdin);
dup2(tmp, 0);
close(tmp);

And in the signal handler:

close(0);

Presumably this works even on ancient systems without sigaction and with BSD signal semantics.