cgal the demo Polyhedron, the debugger Crashes in qscopedpointer.h - cgal

I haven't make any change in this demo, and it works fine firstly. But after lunch, I ran it again, the debugger crashed, and I got an error(below), the debugger reached this line in qscopedpointer.h:
inline T *data() const
{
return d;
}
error:
Unhandled exception at 0x00007FFDE604516A (Qt5Guid.dll) in Polyhedron_3.exe: 0xC000041D: Access violation reading location 0x00000004: an unhandled exception was encountered during a user callback.
stack trace like this:
Qt5Guid.dll!QScopedPointer >::data() Line 135 C++
Qt5Guid.dll!qGetPtrHelper >>(const QScopedPointer > & p) Line 983 C++
Qt5Guid.dll!QScreen::d_func() Line 59 C++
Qt5Guid.dll!QScreen::geometry() Line 302 C++
qwindowsd.dll!QWindowsWindow::isFullScreen_sys() Line 1630 C++
qwindowsd.dll!QWindowsWindow::handleResized(int wParam) Line 1394 C++
qwindowsd.dll!QWindowsContext::windowsProc(HWND__ * hwnd, unsigned int message,
QtWindows::WindowsEventType et, unsigned __int64 wParam, __int64 lParam, __int64 * result) Line 1011 C++
qwindowsd.dll!qWindowsWndProc(HWND__ * hwnd, unsigned int message, unsigned __int64
wParam, __int64 lParam) Line 1271 C++
qwindowsd.dll!qWindowsWndProc(HWND__ * hwnd, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 1280 C++
qwindowsd.dll!WindowCreationData::initialize(const QWindow * w, HWND__ * hwnd, bool frameChange, double opacityLevel) Line 707 C++
qwindowsd.dll!QWindowsWindow::setWindowFlags_sys(QFlags wt,
unsigned int flags) Line 1571 C++
qwindowsd.dll!QWindowsWindow::setParent_sys(const QPlatformWindow * parent) Line 1294 C++
qwindowsd.dll!QWindowsWindow::setParent(const QPlatformWindow * newParent) Line 1260 C++
Qt5Guid.dll!QWindow::setParent(QWindow * parent) Line 614 C++
Qt5Widgetsd.dll!q_createNativeChildrenAndSetParent(const QWidget * parentWidget) Line 1377 C++
Qt5Widgetsd.dll!q_createNativeChildrenAndSetParent(const QWidget * parentWidget) Line 1382 C++
Qt5Widgetsd.dll!QWidgetPrivate::create_sys(unsigned __int64 window, bool initializeWindow, bool destroyOldWindow) Line 1481 C++
Qt5Widgetsd.dll!QWidget::create(unsigned __int64 window, bool initializeWindow, bool destroyOldWindow) Line 1321 C++
Qt5Widgetsd.dll!QWidget::setVisible(bool visible) Line 8060 C++
Qt5Widgetsd.dll!QWidget::show() Line 7671 C++
Polyhedron_3.exe!main(int argc, char * * argv) Line 51 C++
Polyhedron_3.exe!__tmainCRTStartup() Line 626 C
Polyhedron_3.exe!mainCRTStartup() Line 466 C
===============================
I have no idea what the issue is. I appreciate if anyone could give me some advise to solve this.
Thanks.

Related

TLS 1.3 handshake Failure - Client reports "Header Too Long"

I'm in process of updating the client to support TLS 1.3. When trying to connect to TLS 1.3 server, client is reporting "Internal error". Wireshark traces showing that server responded with Verify Certificate, Finished message. But client fails to generate the keys with following call stack -
libcrypto-1_1.dll!ASN1_get_object(const unsigned char * * pp, long * plength, int * ptag, int * pclass, long omax) Line 101
libcrypto-1_1.dll!asn1_item_embed_d2i(ASN1_VALUE_st * * pval, const unsigned char * * in, long len, const ASN1_ITEM_st * it, int tag, int aclass, char opt, ASN1_TLC_st * ctx, int depth) Line 287
[Inline Frame] libcrypto-1_1.dll!ASN1_item_ex_d2i(ASN1_VALUE_st * *) Line 124
libcrypto-1_1.dll!ASN1_item_d2i(ASN1_VALUE_st * * pval, const unsigned char * * in, long len, const ASN1_ITEM_st * it) Line 114
libcrypto-1_1.dll!d2i_X509_SIG(X509_sig_st * * a, const unsigned char * * in, long len) Line 21
MyCode.dll!PrivateKeyOperationCallback(ssl_st * pSSL, unsigned int type, unsigned int rsakeysize, const unsigned char * hash, unsigned int hashlen, unsigned char * sig, unsigned int sigmaxlen, unsigned int * siglen)
[Inline Frame] MyCode.dll!My_RSA_private_encrypt1(ssl_st *)
MyCode.dll!My_RSA_private_encrypt(int flen, const unsigned char * from, unsigned char * to, rsa_st * rsa, int padding)
libcrypto-1_1.dll!pkey_rsa_sign(evp_pkey_ctx_st * ctx, unsigned char * sig, unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen) Line 185
libcrypto-1_1.dll!EVP_PKEY_sign(evp_pkey_ctx_st * ctx, unsigned char * sig, unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen) Line 66
libcrypto-1_1.dll!EVP_DigestSignFinal(evp_md_ctx_st * ctx, unsigned char * sigret, unsigned int * siglen) Line 148
libcrypto-1_1.dll!EVP_DigestSign(evp_md_ctx_st * ctx, unsigned char * sigret, unsigned int * siglen, const unsigned char * tbs, unsigned int tbslen) Line 170
libssl-1_1.dll!tls_construct_cert_verify(ssl_st * s, wpacket_st * pkt) Line 307
libssl-1_1.dll!write_state_machine(ssl_st * s) Line 843
libssl-1_1.dll!state_machine(ssl_st * s, int server) Line 443
libssl-1_1.dll!ossl_statem_connect(ssl_st * s) Line 250
libssl-1_1.dll!SSL_do_handshake(ssl_st * s) Line 3661
libssl-1_1.dll!SSL_connect(ssl_st * s) Line 1662
ASN1_get_object returns "Header Too Long". Same client is able to connect to same server with TLS 1.2 and even able to connect to same server from browser with TLS 1.3.
Issue is specifically with mTLS (not with TLS).
That code path is not unique to TLS 1.3, and has been present in OpenSSL / libcrypto for quite a long time.
The error is occurring because an ASN.1 object encoded in the certificate has a definite length that exceeds the length of the data provided. Either the certificate data is corrupt, or the server is not sending the correct data.
If you're implementing the TLS 1.3 client yourself it is possible that your code is not properly handling certificate encryption, leading to garbled data being sent into the ASN.1 parsing code paths. Without further information (Wireshark dumps and the certificate itself) it is impossible to know what the specific error is.

Native localtime() segfaults

I seem to be doing something wrong in this attempt to expose the localtime functionality in Perl 6:
use NativeCall;
my class TimeStruct is repr<CStruct> {
has int32 $!tm_sec;
has int32 $!tm_min;
has int32 $!tm_hour;
has int32 $!tm_mday;
has int32 $!tm_mon;
has int32 $!tm_year;
has int32 $!tm_wday;
has int32 $!tm_yday;
has int32 $!tm_isdst;
has Str $!tm_zone;
has long $!tm_gmtoff;
}
sub localtime(uint32 $epoch --> TimeStruct) is native {*}
dd localtime(time); # segfault
Running under perl6-lldb-m, I get:
Process 82758 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x5ae5dda1)
frame #0: 0x00007fffe852efb4 libsystem_c.dylib`_st_localsub + 13
libsystem_c.dylib`_st_localsub:
-> 0x7fffe852efb4 <+13>: movq (%rdi), %rax
0x7fffe852efb7 <+16>: movq %rax, -0x20(%rbp)
0x7fffe852efbb <+20>: movq 0x8e71d3e(%rip), %rbx ; lclptr
0x7fffe852efc2 <+27>: testq %rbx, %rbx
Target 0: (moar) stopped.
Any obvious things I'm doing wrong here?
UPDATE: the final working solution:
class TimeStruct is repr<CStruct> {
has int32 $.tm_sec; # *must* be public attributes
has int32 $.tm_min;
has int32 $.tm_hour;
has int32 $.tm_mday;
has int32 $.tm_mon;
has int32 $.tm_year;
has int32 $.tm_wday;
has int32 $.tm_yday;
has int32 $.tm_isdst;
has long $.tm_gmtoff; # these two were
has Str $.time_zone; # in the wrong order
}
sub localtime(int64 $epoch is rw --> TimeStruct) is native {*}
my int64 $epoch = time; # needs a separate definition somehow
dd localtime($epoch);
localtime() expects a pointer of type time_t* as argument. Assuming time_t and uint32_t are compatible types on your particular platform,
sub localtime(uint32 $epoch is rw --> TimeStruct) is native {*}
my uint32 $t = time;
dd localtime($t);
should do it (though you won't get to see anything unless you make your attributes public).
I'm a bit surprised that your time_t isn't a 64-bit type, and having just googled apple time.h, I also suspect the last two attributes in your struct declaration are in the wrong order...

Weird memory issue with ostringstream / ostream using valgrind

I get this memory issue with valgrind that I cannot make any sense out of. Just adding a line which access the ostream seems to get rid of the memory issue, but that is obviously not the way I want to go. Any ideas what could be wrong? Input to the printBuffer method is a std::ostringstream.
#define FORMATSTRWBUF(pos, buf, len, ...) pos += snprintf(buf + pos, len - pos, __VA_ARGS__)
void printBuffer(std::ostream& os, const char* buffer_name, const unsigned char* buffer, int length) const {
os << buffer_name;
os << "{length ";
os << length;
os << ", contents 0x";
// If this line is here, there is no memory issues, but...
fprintf(stdout, "\n%s %s\n", buffer_name, static_cast<std::ostringstream&>(os).str().c_str());
// fprintf(stdout, "\n%s\n", buffer_name); // having this line only has no effect
int pos = 0;
const int len = 1024;
char buf[len];
for (int32_t i = 0; i < length; ++i) {
FORMATSTRWBUF(pos, buf, len, "%02X", buffer[i]);
}
//... if it is not there is a "Conditional jump or move depends on uninitialised value(s)" memory issue here:
os << buf;
os << "}";
}
==43066== Conditional jump or move depends on uninitialised value(s)
==43066== at 0x4C2C129: strlen (vg_replace_strmem.c:454)
==43066== by 0x5687378: length (char_traits.h:263)
==43066== by 0x5687378: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (ostream:562)
==43066== by 0x44D462: printBuffer(std::ostream&, char const*, unsigned char const*, int) const (message.h:102)
Why do you always seem to find the answer as soon as you have asked a question..
I forgot to initialize buf:
char buf[len] = {0};
did the trick.

log4cplus- helpers::towstring() and PropertyConfigurator::doConfigure scramble string parameter in C++/CLI running in non-CLR mode for x64

I'm using log4cplus as a logger for both CLR and non-CLR C++/CLI code and C# code so for that reason I'm using the Unicode x64 build of log4cplus, log4cplusU.lib/dll.
If I run the following code in a non-CLR C++/CLI x64 console application, I get a memory access exception.
int _tmain(int argc, _TCHAR* argv[])
{
std::string LogFileName = "log4cplus.log";
auto db = log4cplus::helpers::towstring(LogFileName);
Exception:
Unhandled exception at 0x00007FF8E4A1CDA1 (msvcr120.dll) in ConsoleApplication1.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
What's up?
I'm using Visual Studio 2013. My call stack at the exception looks like:
> log4cplusU.dll!std::vector<wchar_t,std::allocator<wchar_t> >::vector<wchar_t,std::allocator<wchar_t> >(unsigned __int64 _Count) Line 691 C++
log4cplusU.dll!log4cplus::helpers::towstring_internal(std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & outstr, const char * src, unsigned __int64 size, const std::locale & loc) Line 70 C++
log4cplusU.dll!log4cplus::helpers::towstring(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & src) Line 124 C++
ConsoleApplication1.exe!wmain(int argc, wchar_t * * argv) Line 24 C++
ConsoleApplication1.exe!__tmainCRTStartup() Line 623 C
At the point where the exception fires in std::vector(size_type), _Count is a crazy number.
_Count 14757396612626683276 unsigned __int64
The reason appears to be that the string parameter gets scrambled or misinterpreted.
The same problem manifests itself on non-Unicode DEBUG MODE builds of log4cplus in unmanaged code on VS but not in release mode builds.
For example:
#include <string>
#include "stdafx.h"
#include <iostream>
#include <log4cplus/loggingmacros.h>
#include <log4cplus/configurator.h>
int _tmain(int argc, _TCHAR* argv[])
{
std::string LogConfigFileName = "WhenLoggingCppManagedCode.properties";
try
{
log4cplus::tstring cfn = LogConfigFileName;
log4cplus::PropertyConfigurator::doConfigure(cfn);
std::cout << "Good Deadpool." << std::endl;
}
catch (...)
{
std::cout << "BAD Deadpool." << std::endl;
}
std::cin.get();
return 0;
}

Exception when creating ADO Command object at end of Application

I'm now moving a big software from OWL to MFC, most of the mission has been done, but I face alot of problems like this one when the application is closing this exception arises
When I clicked break the debuger lead me to this
that was the call stack
msdart.dll!_UMSEnterCSWraper() Unknown
msado15.dll!ATL::AtlModuleGetClassObject(struct ATL::_ATL_MODULE *,struct _GUID const &,struct _GUID const &,void * *) Unknown
msado15.dll!ATL::CComModule::GetClassObject(struct _GUID const &,struct _GUID const &,void * *) Unknown
msado15.dll!_DllGetClassObject#12() Unknown
ole32.dll!CClassCache::CDllPathEntry::DllGetClassObject(const _GUID & rclsid, const _GUID & riid, IUnknown * * ppUnk, int fMakeValid) Line 3317 C++
ole32.dll!CClassCache::CDllFnPtrMoniker::BindToObject(const _GUID & riid, void * * ppvResult) C++
ole32.dll!CClassCache::SearchForLoadedClass(const ACTIVATION_PROPERTIES & ap, CClassCache::CDllClassEntry * * ppDCE) C++
ole32.dll!ICoCreateInstanceEx(const _GUID & Clsid, IUnknown * punkOuter, unsigned long dwClsCtx, _COSERVERINFO * pServerInfo, unsigned long dwCount, unsigned long dwActvFlags, tagMULTI_QI * pResults, ActivationPropertiesIn * pActIn) Line 1163 C++
ole32.dll!CComActivator::DoCreateInstance(const _GUID & Clsid, IUnknown * punkOuter, unsigned long dwClsCtx, _COSERVERINFO * pServerInfo, unsigned long dwCount, tagMULTI_QI * pResults, ActivationPropertiesIn * pActIn) Line 332 C++
ole32.dll!CoCreateInstanceEx(const _GUID & Clsid, IUnknown * punkOuter, unsigned long dwClsCtx, _COSERVERINFO * pServerInfo, unsigned long dwCount, tagMULTI_QI * pResults) Line 157 C++
ole32.dll!CoCreateInstance(const _GUID & rclsid, IUnknown * pUnkOuter, unsigned long dwContext, const _GUID & riid, void * * ppv) Line 110 C++
> DBCore.dll!_com_ptr_t<_com_IIID<ADODB::_Command,&_GUID_b08400bd_f9d1_4d02_b856_71d5dba123e9> >::CreateInstance(const _GUID & rclsid, IUnknown * pOuter, unsigned long dwClsContext) Line 586 C++
DBCore.dll!TADOCommand::Init(TADOConnection * connection) Line 32 C++
DBCore.dll!TADOCommand::TADOCommand(TADOConnection * connection) Line 8 C++
AmnDbase.dll!TQuery::Init() Line 335 C++
AmnDbase.dll!TQuery::TQuery(const TDatabase * db, TTable * Tbl) Line 304 C++
AmnDbase.dll!TDirectQuery::TDirectQuery(const TDatabase * db) Line 932 C++
AmnDbase.dll!CommitUnsavedTransactions(TDatabase * db) Line 674 C++
AmnDbase.dll!TDatabase::Disconnect() Line 427 C++
AmnDbase.dll!TDatabase::CloseDb() Line 455 C++
AmnDbase.dll!TDatabase::Close() Line 417 C++
AmnLib2.dll!TStoreFile::Close() Line 3275 C++
AmnLib2.dll!TStoreFile::~TStoreFile() Line 1040 C++
AmnLib2.dll!`GetStoreFile'::`2'::`dynamic atexit destructor for 'StoreFile''() C++
AmnLib2.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 415 C
AmnLib2.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 526 C
AmnLib2.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 476 C
this is the code that called the CreateInstance
/// Init the command instance.
void TADOCommand::Init( TADOConnection* connection)
{
m_CmdText = "";
m_nRecordsAffected = 0;
m_Command = NULL;
m_ResultSet = NULL;
m_CmdConnection = NULL;
m_CmdRecordset = NULL;
if( connection->IsNull())
return;
m_Command.CreateInstance( __uuidof( Command));
SetConnection( connection);
SetCommandTimeOut( connection->GetCommandTimeout());
}
I want the code to stay working without changing any code especialy in the database layer is this due to call of couninitialize from MFC?? how can I detect that or solve this issue?
and the m_Command was defined as
_CommandPtr m_Command;
and it is com interface first it is set to null then call CreateInstance it works fine each time unless the last time it fails with this exception
The code seams to be executed when your DLL is unloaded or loaded, as far as I can see in the callstack.
When this is "loading code" the question arrises: Why is the LDL loaded again.
But using COM in DllMain is no good at all. See here
COM should never be used inside a DllMain code.
I suppose that your DLL is unloaded after the MFC already called CoUninitialize. Or your DLL is reloaded by some code, that shouldn't be executed in the shut down of your application.