6

I am working on a lock-free shared variable class, and I want to be able to generate a SIGSEGV fault to see if my implementation works as I planned. I've tried creating a function that modifies a pointer and read it 100 times. I then call this function in both threads and have the threads run infinitely within my program. This doesn't generate the error I want. How should I go about doing this?

edit I don't handle segfaults at all, but they are generated in my program if I remove locks. I want to use a lock-less design, therefore i created a shared variable class that uses CAS to remain lockless. Is there are way that I can have a piece of code that will generate segfaults, so that i can use my class to test that it fixes the problem?

RaptorIV
  • 163
  • 3
  • 12
  • 3
    What the heck? What on earth would you try to do with a SIGSEGV? This makes no sense at all. Please explain to us what problem you're trying to solve. Have you created a program that attempts to react to problems by intercepting and discarding segmentation faults? Doesn't this concern you at all? `How should I go about doing this?` A 180º about turn is step one. – Lightness Races in Orbit Feb 26 '12 at 22:39
  • 1
    @LightnessRacesinOrbit I think that a shared-memory application where one of the clients can survive a segfault in the other (by having clients clean up if they segfault) is a reasonable application. Reading between the lines this sounds like what the OP is doing. – James Feb 26 '12 at 22:42
  • 4
    @Lightness: If you were trying to write an exception-safe smart pointer, don't you think you ought to unit test behavior when an exception occurs? This looks like a similar idea. – Ben Voigt Feb 26 '12 at 22:43
  • @Autopulated: It sounds stupid to me. If you have a segfault, then you are lucky to see a symptom of potentially mind-bogglingly-wide memory corruption. It's a wake-up call to fix your code, not some exceptional circumstance to discard and ignore. – Lightness Races in Orbit Feb 26 '12 at 22:43
  • @BenVoigt: I disagree. If your program -- in any thread -- causes a SIGSEGV, then by definition all bets are off, mostly because you have no idea what damage has been caused before the raising of the signal. Further handling attempts are complete folly. – Lightness Races in Orbit Feb 26 '12 at 22:44
  • 1
    What I'm doing it for is irrelevant, I just need to know how to produce a segfault – RaptorIV Feb 26 '12 at 22:45
  • 2
    @LightnessRacesinOrbit: So it would be ok to leave a shared resource permanently locked if the process which held the lock dies? Your approach turns possible data loss into guaranteed data loss. – Ben Voigt Feb 26 '12 at 22:49
  • 2
    This good enough? kill -s SIGSEGV – BoBTFish Feb 26 '12 at 22:50
  • @BenVoigt: What approach? I never proposed any approach. You're making things up again. – Lightness Races in Orbit Feb 26 '12 at 22:54
  • I don't handle segfaults at all, but they are generated in my program if I remove locks. I want to use a lock-less design, therefore i created a shared variable class that uses CAS to remain lockless. Is there are way that I can have a piece of code that will generate segfaults, so that i can use my class to test that it fixes the problem? – RaptorIV Feb 26 '12 at 22:54
  • 3
    Relax, this kind of thing is fairly common when writing/testing fault-tolerant code. – Mysticial Feb 26 '12 at 22:56
  • @BoBTFish: I think that's the answer to this silly question. – Lightness Races in Orbit Feb 26 '12 at 22:58
  • 1
    @Lightness: You said "Further handling attempts are complete folly." If that doesn't mean you advocate NO further handling, then what does it mean? – Ben Voigt Feb 26 '12 at 22:58
  • @BenVoigt: I didn't advocate anything at all. I am merely commentating, hence talking in comments. Please stop putting words into my mouth. Thanks – Lightness Races in Orbit Feb 26 '12 at 22:59
  • Your edit makes it sound like you're looking at race conditions (which happen to present themselves as segfaults in your program). If you're asking "can I reliably reproduce a race condition?" the answer is no, unless you can control the state of execution of every thread. (The only sane way to do that is to checkpoint all the threads and then (prove) manually that a given pre-crash checkpoint is going to hit the race condition) – Flexo Feb 26 '12 at 23:48
  • @awoodland yes that is exactly what i'm looking for. Is there any way i can generate a race condition that presents itself as a segfault that will happen eventually? i'm willing to leave it running overnight haha – RaptorIV Feb 27 '12 at 00:56

3 Answers3

21
#include <signal.h>

raise(SIGSEGV);

Will cause an appropriate signal to be raised.

TheMeaningfulEngineer
  • 15,679
  • 27
  • 85
  • 143
Flexo
  • 87,323
  • 22
  • 191
  • 272
  • I need the signal to be generated by something like dereferencing an invalid pointer – RaptorIV Feb 26 '12 at 22:46
  • @RaptorIV: Explain why you care what it is that generates the signal. – Lightness Races in Orbit Feb 26 '12 at 22:55
  • it needs to be generated in a real environment, as though a multithreaded program had caused it. Im not handling it at all, I just need to see my program crash because of it, so i can see if it doesn't exist when i implement my class – RaptorIV Feb 26 '12 at 23:21
  • Raising the signal like that will (with a few caveats) get treated exactly like a "real" segfault the signal will get delivered the exception handler will be invoked if one is present. It's still a "real" signal in every sense and if it's for testing then it's quite a good starting point if nothing else. – Flexo Feb 26 '12 at 23:39
6

malloc + mprotect + dereference pointer

This mprotect man page has an example.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
3

Derefencing pointer to unallocated memory (at least on my system):

int *a;
*a = 0;
Tudor
  • 61,523
  • 12
  • 102
  • 142