Yuk... In a vacuum and absent of a memory smash, a bad "this" pointer is usually caused by C++ static initialization order problems. On other OS'es it usually surfaces as a null this pointer.
I have spent countless hours trying to wring-out the problems. We mostly have them solved on Windows and Linux. Solaris and MacPorts are the hold outs because they don't respond to init_seg(lib) or init_priority. Also see https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco. How are you building the library? Are {cryptlib.o, cpu.o, integer.o} the first three objects fed to the linker? The remaining *.o files are "don't care's". However, if you have a file-scope static, then the object file needs to be after {cryptlib.o, cpu.o, integer.o}. {cryptlib.o, cpu.o, integer.o} must be initialized first: // As an example: $CXX $CXXFLAGS cryptlib.o, cpu.o, integer.o my_main.o -o prog.exe Something else that kind of sucks when trying to diagnose a C++ static initialization order problems: we don't have tools to audit for it. I've been looking for them for years. Also see http://stackoverflow.com/q/34144185. Another workaround could be: (1) don't use libcryptopp.a, and (2) use libcryptopp.so. I believe the module boundary ensures the C++ static objects are initialized properly. I could be completely wrong. I've also seen problems with the initialized data segment on OS X. That's why we added CRYPTOPP_SECTION_INIT. I wonder if Solaris is experiencing a similar issue. Does -fno-common help the problem? On early .Net 2002 and 2003 I saw some odd vtable problems. But I'm pretty sure it was do to CRYPTOPP_NO_VTABLE on MS platforms. On Unix'es the macro is defined to nothing so it should not be contributing to the issue you are experiencing. Can you get me remote access to that machine? Jeff > I have spent some more time in the debugger and have some more information > on this problem. Unfortunately I have no resolution at the moment. > > The Integer copy ctor (integer.cpp:2903) is being given a bad integer to > copy. The m_ptr is null, the m_size is 144. This integer is returned from > RSAFunction::PreimageBound. The "this" pointer at this juncture seems to be > bad. It turns out the pointer value is actually a pointer to char* rather > than the object expected. The string is the value returned from > GetThisObject. Single stepping in dbx I get to RSAFunction::AssignFrom. At > this point the "this" ptr is ok. I step into RSAFunction::GetThisObject > which calls GetValue which calls GetVoidValue. This is where it calls > RSAFunction::PreboundImage with m_n equal to that empty, troublesome > Integer. But there is no way that the function should even have been called. > GetVoidValue is a pure virtual on the base class (NameValuePairs) so it > should have done a virtual function dispatch to the relevant GetVoidValue > function. It didn't . On landing in RSAFunction::PreboundImage the "this" > pointer is equal to the name value in GetVoidValue, a string pointing to > "ThisObject:CryptoPP::RSAFunction". What could be causing the vptr dispatch > to go wrong? I note that the base class, NameValuePairs, is decorated with > the macro CRYPTOPP_NO_VTABLE. It seems quite a coincidence that I am having > vptr trouble and there is this macro with a name like that. The macro is a > no-op though unles the Microsoft compiler is being used (I am on solaris 11 > sparc with the sunstudio 12.4 compiler). Can someone please explain what > that macro is about? > > So this kind of explains why the integer is bad but nothing can detect it > and nothing assigns it this bad value. But what to do from here? I am stuck. -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
