Hello,
I'm currently developing on Windows using MinGW64 as my toolchain to compile this library.
During testing, I encountered a thread-related crash when executing SQL parsing in a background thread. Here's what I observed:
✅ If I parse SQL on the main thread, everything works fine. like :
int main() { for(int i =0;i<100;i++ ) { const char * sql ="INSERT INTO altable (name) values ('1') ; "; hsql::SQLParserResult result; hsql::SQLParser::parser(sql,&result); } return 0; }
❌However, if I perform SQL parsing off the main thread, I occasionally experience unpredictable errors. like :
int main() { std::thread _t ([=](){ for(int i =0;i<100;i++ ) { const char * sql ="INSERT INTO altable (name) values ('1') ; "; hsql::SQLParserResult result; hsql::SQLParser::parser(sql,&result); } return 0; }}); _t.join(); }
If I perform the parsing off the main thread, I encounter random crashes, most commonly:
0xc0000374: Heap corruption Stack trace usually points to libstdc++6.dll, particularly in malloc or free
Sometimes, the crash is:
0xc0000005: Access violation
🔍 Further Investigation
I also noticed that the crash only happens with certain SQL statements— specifically when string values are included in the SQL. For example:
✅ This does not crash:
INSERT INTO table1 (id) VALUES (1);
❌ This will likely crash (off main thread):
INSERT INTO table1 (name) VALUES ('111');
It seems the crash is triggered when the parser tries to handle string fields(e.g., '111' as a name), whereas numeric values like integers or doubles do not cause issues.
✅ Tested with MSVC
When I switch from MinGW64 to MSVC as the compiler:
The issue completely disappears, even under the same test scenarios (multi-threaded SQL parsing with string values).
❓Question
Do you have any insight into why this behavior occurs?
Could it be a compatibility issue between MinGW’s libstdc++ and the memory allocation used during string parsing?
Or perhaps an issue with thread-safety or exception handling in MinGW’s C++ runtime?
Any help or advice would be greatly appreciated!
Thank you in advance 🙏
Hello,
I'm currently developing on Windows using MinGW64 as my toolchain to compile this library.
During testing, I encountered a thread-related crash when executing SQL parsing in a background thread. Here's what I observed:
✅ If I parse SQL on the main thread, everything works fine. like :
int main() { for(int i =0;i<100;i++ ) { const char * sql ="INSERT INTO altable (name) values ('1') ; "; hsql::SQLParserResult result; hsql::SQLParser::parser(sql,&result); } return 0; }❌However, if I perform SQL parsing off the main thread, I occasionally experience unpredictable errors. like :
int main() { std::thread _t ([=](){ for(int i =0;i<100;i++ ) { const char * sql ="INSERT INTO altable (name) values ('1') ; "; hsql::SQLParserResult result; hsql::SQLParser::parser(sql,&result); } return 0; }}); _t.join(); }If I perform the parsing off the main thread, I encounter random crashes, most commonly:
0xc0000374: Heap corruption Stack trace usually points to libstdc++6.dll, particularly in malloc or freeSometimes, the crash is:
0xc0000005: Access violation🔍 Further Investigation
I also noticed that the crash only happens with certain SQL statements— specifically when string values are included in the SQL. For example:
✅ This does not crash:
INSERT INTO table1 (id) VALUES (1);❌ This will likely crash (off main thread):
INSERT INTO table1 (name) VALUES ('111');It seems the crash is triggered when the parser tries to handle string fields(e.g., '111' as a name), whereas numeric values like integers or doubles do not cause issues.
✅ Tested with MSVC
When I switch from MinGW64 to MSVC as the compiler:
The issue completely disappears, even under the same test scenarios (multi-threaded SQL parsing with string values).
❓Question
Do you have any insight into why this behavior occurs?
Could it be a compatibility issue between MinGW’s libstdc++ and the memory allocation used during string parsing?
Or perhaps an issue with thread-safety or exception handling in MinGW’s C++ runtime?
Any help or advice would be greatly appreciated!
Thank you in advance 🙏