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;
b->a.print();
}
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
> http://www.cryptopp.com/docs/ref/gfpcrypt_8h_source.html and
> http://www.cryptopp.com/docs/ref/gfpcrypt_8cpp_source.html).
>
> *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.
