Causing and trapping SIGSEGV

This is a discussion on Causing and trapping SIGSEGV within the C Programming forums, part of the General Programming Boards category; An assignment I was given in my Operating Systems class was to determine how much memory is associated with a ...

  1. #1
    Registered User
    Join Date
    Oct 2007
    Posts
    11

    Causing and trapping SIGSEGV

    An assignment I was given in my Operating Systems class was to determine how much memory is associated with a program via probing all memory locations and seeing which give you a segmentation fault.

    So basically, start at 0 and increment by 4 (32 bit only) for all the memory and keep a counter going every time it doesn't fire the signal off (and SIGBUS I think, don't have a copy of the assignment on me at the time).

    My problem is since after the trapping function it just returns to the same line, it's constantly looping after the first segfault. I tried screwing around with global variables and changing the pointer location within the trap statement, but it's kinda hard to tell if that works any better.
    For example, having a pointer assigned to a global variable pointer that is incremented by 4 every time the trap gets the signal. Rough sketch, since I'm not on the right OS at the moment to see the file:
    Global variables
    Code:
    int *a, *b;
    int count = 0;
    Trapping function
    Code:
    if (signal == SIGSEGV)
            *b += 4;
    else
            count++;
    In main somewhere
    Code:
    *a = *b;
    That wouldn't exactly ever exit either. I tried some weird thing called a longjmp, which I was told was like a goto that could jump through functions, but it didn't really work out to well.

    Seems like I'm jumping through hoops, because the professor (who refuses to tell us how to do it in the slightest) says it should not be much longer than 20 lines.

    Is there some cheap trick I'm missing, because most places say you shouldn't be able to recover from a sigsegv in the first place, and if you do it's likely the rest of the behaviour is undefined.

  2. #2
    Registered User
    Join Date
    Oct 2007
    Posts
    11
    It's supposed to point to the next word in memory, so it ends up checking every bit of memory the system has. Makes testing impractical, which is partly the reason I want to get it right the first time.

    Edit: This was in response to a question that seems to have been deleted
    Last edited by ampersand11; 01-23-2008 at 09:48 AM.

  3. #3
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by ampersand11 View Post
    Is there some cheap trick I'm missing, because most places say you shouldn't be able to recover from a sigsegv in the first place, and if you do it's likely the rest of the behaviour is undefined.
    You are absolutely correct that the behavior after receiving a SIGSEGV is undefined. I cringed when I read the assignment description...

    But the solution is to install a signal handler for SIGSEGV which does nothing but set a global, volatile flag indicating that the signal occurred. In your loop checking addresses, you clear this flag before testing the memory location, and then check to see if it is set afterward (i.e. a SIGSEGV occurred).

    Your SIGSEGV handler function should be only one or two lines of code. To install it use the signal() call.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21