Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

About SIGSEGV segmentation fault

LegacyForum
LegacyForum Posts: 1,664 ✭✭
edited December 2016 in Insure++
seg fault when compiling with insure
When running my program it gives a segmentation fault if it is compiled with insure, but if not compiled with insure, it doesn't.

The only change between the Insure build and the non-Insure build is the word "insure" before the g++ statement.

If it's a genuine seg fault scenario, can you suggest why it wouldn't occur when NOT building with insure? Getting different behavior under Insure makes me nervous.


thanks,
Andrew Freese


uname -a
Linux XXXXXX 2.4.21-32.0.1 ELsmp #1 SMP Tue May 17 17:46:36 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux

g++ version 3.2.3

Comments

  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    edited December 2016
    Afreese,

    Thanks for your question.

    If it's a genuine seg fault scenario, can you suggest why it wouldn't occur when NOT building with insure?

    Sure. There are lots of reasons. In fact, some of what Insure++ does makes your program more likely to crash, because it does things such as set uninitialized values in a way that reveals latent bugs.

    Here's a ficticious example, just to illustrate:
    // In this ficticious example, p is uninitialized, but happens to always be 0 // because it falls consistently at the same stack address, which is always 0. // However, when using Insure++, p is initialized to 0xdeadbeef. void foo() { char *p; if (p) { // EXPR_UNINIT_PTR *p = 'a'; // crash, but only under Insure++ (WRITE_UNINIT_PTR) } }
    That is the general answer: Yes, Insure++ can change program behavior. It must in order to detect bugs. But don't be nervous. :-) It is what Insure++ was desiged to do, and much care is taken to only change program behavior in reasonable ways (e.g. setting "undefined" values, which by definition may be anything). In the above ficticious example, Insure++ reports a EXPR_UNINIT_PTR and WRITE_UNINIT_PTR before the crash occurs.

    When you get a SIGSEGV, it is a good idea to see if Insure++ reported anything before the crash. If Insure++ did not report anything, getting a stack trace is the next logical step.