How to troubleshoot a crash under Cygwin at -O3?

Jonathan Wakely
Wed Aug 12 09:22:00 GMT 2015

On 12 August 2015 at 00:03, Jeffrey Walton wrote:
> I'm experiencing a crash under Cygwin with -O3. The crash is reproducible:
> Program received signal SIGSEGV, Segmentation fault.
> DL_GroupParameters_IntegerBased::GetEncodedElementSize (this=0x11,
>     reversible=true) at gfpcrypt.h:55
> 55              unsigned int GetEncodedElementSize(bool reversible)
> const {return GetModulus().ByteCount();}
> Above, this = 0x11, and I believe its a private exponent (17). I'm
> guessing its related to the vtable generated under Cygwin at -O3.

Unlikely values of 'this' like that usually mean a null pointer
dereferences somewhere e.g.

#include <stdio.h>
struct A {
 void print() { printf("this=%p\n", this); }

struct B {
 long i, j;
 bool b;
 A a;

int main()
 B* b = 0;

So I would try valgrind.

> Note that there are no virtual methods. There is a base class that
> provides an interface, and then derived classes provide the
> implementation. In fact, there's a macro #define CRYPTOPP_NO_VTABLE
> __declspec(novtable). (Also see
> and
> *If* I force -fPIC on the command line and endure 135 or so of these:
>     $ make
>     g++ -DNDEBUG -g -O3 -fPIC -march=native -pipe -c shacal2.cpp
>     shacal2.cpp:1:0: warning: -fPIC ignored for target (all code is
> position independent)
>     // shacal2.cpp - by Kevin Springle, 2003
>     ^
> Then the program executes fine. But its a very messy compile, and its
> probably not going to be worth forcing -fPIC because we will get too
> much negative feedback.

This doesn't make any sense. If -fPIC is ignored then how does addng
it make any difference?

Have you compared the object files with and without -fPIC to see if it
does make any difference? If it does, there shouldn't be a warning
about ignoring it.

More information about the Gcc-help mailing list