ecode is very crashy recently

[Curculigo]

Dr. Mingw is the easiest tool for us non-professionals to inspect what's going on, and it's easy to setup:

https://github.com/jrfonseca/drmingw

Recently, ecode crashes more frequently for me. I have no idea what's going on, and the report by Dr. MinGW is different each time.

[SpartanJ]

Please share each crash report, that's the only way I can fix them. Stability has the highest of the priorities for me. But I do not experience crashes myself, otherwise I'll always try to fix them ASAP.

[Curculigo]

I know. I'm trying to find how to reliably reproduce the crashes. They happen pretty much randomly for me.

[SpartanJ]

Thanks! But don't worry about reproduce-ability, sometimes crashes can be very random, having the stack-trace is usually very telling for me. Off course, if you know how to reproduce them the better but it's not a requirement for the report. Hopefully we can track them quickly.

[Curculigo]

After upgraded to the latest SDL2, I don't see any crashes. How can it be the case? The report by Dr. Mingw doesn't mention SDL2.

[SpartanJ]

Most probable cause is that it's just a coincidence. Wait a little longer. But if that fixed it cool.

The report by Dr. Mingw doesn't mention SDL2.

I tested Dr. Mingw reports and they are almost always incorrect, it seem to resolve incorrectly the stack-trace for some reason. But sometimes they can be useful.

[Curculigo]

I have done editing a shell script and quit ecode. It crashed:

ecode.exe caused an Unknown [0xC0000374] Exception at location 000000007709E742 in module ntdll.dll.

AddrPC           Params
000000007709E742 0000000000000002 0000000000000023 00000000000021C6  ntdll.dll!RtlReportCriticalFailure+0x62
000000007709ED16 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlpReportHeapFailure+0x26
000000007709F932 00000000003B0000 00000000003B0000 0000000000000000  ntdll.dll!RtlpHeapHandleError+0x12
00000000770A1A44 00000000003B0000 000000000042E120 000000000042E530  ntdll.dll!RtlpLogHeapFailure+0xa4
000000007700BFC9 00000000003B0000 000000000042EA01 000000000042E120  ntdll.dll!RtlpFreeHeap+0x1649
000007FEFCF010C8 000007FEDD338160 0000000009880650 0000000000421C10  msvcrt.dll!free+0x1c
000000014044F161 0000000000000000 000000000954CAE0 0000000000000000  ecode.exe!EE::System::IniFile::~IniFile+0x181
000000013FDEC47A 000000000030D310 0000000000421C10 0000000000421C10  ecode.exe!ecode::App::~App+0x111a
000000013FDECB8E 0000000000003064 0000000000000000 0000000077034010  ecode.exe!ecode::App::~App+0xe
000000014062F7AD 0000000000000001 00000000003BD910 00000001407DDEB0  ecode.exe!main+0x2bed
000000013FCF13C4 0000000000000000 0000000000000000 0000000000000000  ecode.exe!0x13c4
000000013FCF14E6 0000000000000000 0000000000000000 0000000000000000  ecode.exe!0x14e6
0000000076DD55DD 0000000000000000 0000000000000000 0000000000000000  kernel32.dll!BaseThreadInitThunk+0xd
0000000077032B1D 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x1d

[Curculigo]

The first crash generated an empty stacktrace log file (0 bytes).

[SpartanJ]

Thanks, I'll try to reproduce them. The last crash was while loading a different folder or closing ecode?

[SpartanJ]

BTW I'm working on producing the stack-traces locally to not depend on an external application which is impractical (I won't get proper reports from people without Dr. Ming which will be 99.9% of people). But it's quite challenging to produce good stack-traces from a mingw build.

[Curculigo]

Github Actions has MSVC (of course). You can add ecode-windows-msvc-nightly-x86_64.zip.

[SpartanJ]

Clarification, the last crash report is good, it's just not demangled (I need to check how to fix that), but you can demangle it easily and it will look like:

Stack trace (most recent call last):
#7    Object "", at 0x76dd55dd, in BaseThreadInitThunk
#6    Object "", at 0x13f9914e6, in  ?? 
#5    Object "", at 0x13f9913c4, in  ?? 
#4    Object "", at 0x1402cf7ad, in main
#3    Object "", at 0x13fa8cb8e, in ecode::App::~App()
#2    Object "", at 0x13fa8b5d4, in ecode::App::~App()
#1    Object "", at 0x1402262d6, in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
#0    Object "", at 0x13fc174db, in ecode::ProjectDirectoryTree::~ProjectDirectoryTree()

Which is pretty good. It's crashing during ProjectDirectoryTree destruction when app is being closed. It's not the best crash report but it's useful.

[Curculigo]

@SpartanJ The Dr. Mingw developer said you can add -fno-omit-frame-pointer to GCC/Clang to improve the quality of Dr. Mingw reports.

Please have a look: https://github.com/jrfonseca/drmingw?tab=readme-ov-file#which-options-should-i-pass-to-gccclang-when-compiling

[SpartanJ]

-fno-omit-frame-pointer can have some important performance penalty (depends on the case) but I'll take a look if it's viable, maybe only enable them in the nightlys. Or maybe it's better to have a separate build with complete debug symbols as I used to do for the Linux builds, I removed them because nobody ever used them.

[Curculigo]

Latest crash: I dragged the Win32++ directory into ecode to open as a folder and did a global search for _WIN32_WINNT. I double clicked into the search result to open wxx_setup.h and ecode crashed.

The stack-trace by ecode itself:

Stack trace (most recent call last):
#13   Object "", at 0x76e555dd, in BaseThreadInitThunk
#12   Object "", at 0x7fefd376ebd, in ftime64_s
#11   Object "", at 0x7fefd37414f, in srand
#10   Object "", at 0x7fedf46e0da, in ZN2EE6System6Thread5getIdEv
#9    Object "", at 0x7fedf46e739, in ZN2EE6System10ThreadPool10threadFuncEv
#8    Object "", at 0x13f49c238, in ZN5ecode15LSPClientServer6cancelERKNS_12PluginIDTypeE
#7    Object "", at 0x13f49b9a0, in ZN5ecode15LSPClientServer4sendEON8nlohmann16json_abi_v3_12_010basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEbxydSaNS2_14adl_serializerES5_IhSaIhEEvEERKSt8functionIFvRKNS_12PluginIDTypeERKSF_EESQ_
#6    Object "", at 0x13f49a796, in ZN5ecode15LSPClientServer5writeEON8nlohmann16json_abi_v3_12_010basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEbxydSaNS2_14adl_serializerES5_IhSaIhEEvEERKSt8functionIFvRKNS_12PluginIDTypeERKSF_EESQ_i
#5    Object "", at 0x13fa741e6, in ZNK8nlohmann16json_abi_v3_12_010basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEbxydSaNS0_14adl_serializerES3_IhSaIhEEvE4dumpEicbNS0_6detail15error_handler_tE
#4    Object "", at 0x13fa4073c, in ZN8nlohmann16json_abi_v3_12_06detail10serializerINS0_10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEbxydSaNS0_14adl_serializerES5_IhSaIhEEvEEE4dumpERKSF_bbjj
#3    Object "", at 0x13fb7bede, in ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKcy
#2    Object "", at 0x13fb7c163, in ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_mutateEyyPKcy
#1    Object "", at 0x7fefd3710c8, in free
#0    Object "", at 0x76f8a515, in RtlFreeHeap

The stack-trace by Dr. Mingw:

ecode.exe caused an Access Violation at location 0000000076F8A515 in module ntdll.dll Reading from location 00000EC0138E7908.

AddrPC           Params
0000000076F8A515 000000000000003D 0000000000000000 0000000000000000  ntdll.dll!RtlFreeHeap+0x1a5
000007FEFD3710C8 0000000000000001 000000000AF8CE00 000000013FA43540  msvcrt.dll!free+0x1c
000000013FB7C163 0000000000000080 000000000B1E2148 0000000000000000  ecode.exe!std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate+0xf3
000000013FB7BEDE 0000000000000060 0000000002000002 00000000030FF7E0  ecode.exe!std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append+0x6e
000000013FA4073C 0000000000000040 0000000000130000 000000000000002F  ecode.exe!nlohmann::json_abi_v3_12_0::detail::serializer<nlohmann::json_abi_v3_12_0::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long, unsigned long long, double, std::allocator, nlohmann::json_abi_v3_12_0::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> >, void> >::dump+0x110c
000000013FA741E6 0000000000000000 00000000030FF7B0 000007FE00000002  ecode.exe!nlohmann::json_abi_v3_12_0::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long long, unsigned long long, double, std::allocator, nlohmann::json_abi_v3_12_0::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> >, void>::dump+0x276
000000013F49A796 0000000000000100 000007FEDF60EBB8 0000000000000001  ecode.exe!ecode::LSPClientServer::write+0x346
000000013F49B9A0 00000000030FFA1C 000007FEFD3710C8 000007FEDF60F500  ecode.exe!ecode::LSPClientServer::send+0x60
000000013F49C238 0000000009888E20 0000000000000000 0000000000000000  ecode.exe!ecode::LSPClientServer::cancel+0x398
000007FEDF46E739 00000000003E3900 0000000000000001 0000000000000000  eepp.dll!EE::System::ThreadPool::threadFunc+0x49
000007FEDF46E0DA 00000000003E3900 0000000000000000 0000000000000000  eepp.dll!EE::System::Thread::getId+0x2a
000007FEFD37414F 000007FEFD401EA0 00000000003E3900 0000000000000000  msvcrt.dll!_endthreadex+0x47
000007FEFD376EBD 0000000000000000 0000000000000000 0000000000000000  msvcrt.dll!_endthreadex+0xe0
0000000076E555DD 0000000000000000 0000000000000000 0000000000000000  kernel32.dll!BaseThreadInitThunk+0xd
0000000076FB2B1D 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x1d

The most interesting thing is this only happens once. I can't reproduce it later.

[SpartanJ]

Thanks! This is a different one, it will be hard to catch but at least I have an idea of what's going on.

[Curculigo]

Dragging 4 shell scripts without file extension into ecode and it crashed:

ecode.exe caused an Unknown [0xC0000374] Exception at location 00007FFD31E41340 in module ntdll.dll.

AddrPC           Params
00007FFD31E41340 000000EF4B7CDBA0 00007FFD31E7DD50 000000EF498A0000  ntdll.dll!RtlReportCriticalFailure+0x8c
00007FFD31E44582 000000EF498A0000 0000000000000000 0000000000000000  ntdll.dll!RtlpHeapHandleError+0x12
00007FFD31E45180 000000EF497A2BB0 0000000000000000 000000EF497A2BA0  ntdll.dll!RtlpLogHeapFailure+0xa4
00007FFD31DF8C67 000000EF497A46B0 000000EF497A46B0 000000EF497A46C0  ntdll.dll!RtlFreeHeap+0x78c07
00007FFD31911CB3 0000000000000000 000000EF4B7CCA08 0000000000000000  msvcrt.dll!free+0x1c
00007FFD188C615C 000000EF4B7CD4E0 000000EF4B7CD800 000000EF4B7CDC00  eepp.dll!EE::System::Zip::addFile+0x54044c
00007FFD1814B73E 0000000000000000 0000000000000003 0000000000000030  eepp.dll!EE::UI::Doc::SyntaxDefinitionManager::add+0x6ee
00007FF7FF860435 0000000000000000 00007FFD18909BF9 0000000000000082  ecode.exe!EE::UI::Doc::Language::addShellScript+0x2255
00007FFD18149DA8 000000EF4978DFD0 000000EF52CA5C68 000000EF4B7CFA30  eepp.dll!EE::UI::Doc::SyntaxDefinitionManager::getByHeader+0x188
00007FFD181599F0 000000EF4B7CFA30 0000000000000000 000000EF4B7CFA00  eepp.dll!EE::UI::Doc::SyntaxDefinitionManager::find+0x20
00007FFD181AAADB 000000000000017C 000000EF4B7CFB00 000000EF4B7CFB20  eepp.dll!EE::UI::Doc::TextDocument::resetSyntax+0xeb
00007FFD181B47BA 000000EF4975C670 000000EF4975C698 00007FFD31DAD280  eepp.dll!EE::UI::Doc::TextDocument::loadFromFile+0xfa
00007FFD181B497B 000000EF4977EBF8 0000000000000000 0000000000000000  eepp.dll!EE::UI::Doc::TextDocument::loadFromFile+0x2bb
00007FFD181EEAF9 000000EF4975BA80 0000000000000000 0000000000000000  eepp.dll!EE::System::ThreadPool::threadFunc+0x49
00007FFD181EE49A 00007FFD319A28C0 0000000000000000 0000000000000000  eepp.dll!EE::System::Thread::getId+0x2a
00007FFD31920B13 000000EF4975BA80 000000EF4975BA80 0000000000000000  msvcrt.dll!_callthreadstartex+0x2b
00007FFD31920BCD 0000000000000000 0000000000000000 0000000000000000  msvcrt.dll!_threadstartex+0x7c
00007FFD2F9813D2 00007FFD2F9813B0 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk+0x22
00007FFD31DC03C4 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x34

Still Windows 8.1 64 bit.

[Curculigo]

Yeah, this crash also happened just once like the previous crash. I can't reproduce it later.

[Curculigo]

Oh, it seems to happen randomly. I have just reproduced the crash.

Dr. Mingw:

ecode.exe caused an Unknown [0x20474343] Exception at location 00007FF8677A8B9C in module KERNELBASE.dll.

AddrPC           Params
00007FF8677A8B9C 00007FF84190D630 0000000000000000 0000000000000000  KERNELBASE.dll!RaiseException+0x68
00007FF841743A31 00000055BF0F3FF0 0000000000000000 000000000000000B  eepp.dll!EE::System::Zip::addFile+0x3add21
00007FF84191A54B 00000055C0754790 0000000000000000 0000000000000001  eepp.dll!non-virtual thunk to EE::UI::UITextInput::onDocumentDirtyOnFileSystem(EE::UI::Doc::TextDocument*)+0x254b
00007FF841919C40 0000000000000000 0000000000000000 00000055B93CF660  eepp.dll!non-virtual thunk to EE::UI::UITextInput::onDocumentDirtyOnFileSystem(EE::UI::Doc::TextDocument*)+0x1c40
00007FF8411BA264 00000055B93CF630 0000000000000000 00000055B93CF600  eepp.dll!EE::UI::Doc::TextDocument::fromBase64+0x9b4
00007FF8411BAB0B 000000000000017C 00000055B93CF700 00000055B93CF720  eepp.dll!EE::UI::Doc::TextDocument::resetSyntax+0x11b
00007FF8411C47BA 00000055B71AC0B0 00000055B71AC0D8 00007FF86A34D280  eepp.dll!EE::UI::Doc::TextDocument::loadFromFile+0xfa
00007FF8411C497B 00000055BF0E23A0 00000055B71B10A0 0000000000000000  eepp.dll!EE::UI::Doc::TextDocument::loadFromFile+0x2bb
00007FF8411FEAF9 00000055B71ABD60 0000000000000000 0000000000000000  eepp.dll!EE::System::ThreadPool::threadFunc+0x49
00007FF8411FE49A 00007FF869BB28C0 0000000000000000 0000000000000000  eepp.dll!EE::System::Thread::getId+0x2a
00007FF869B30B13 00000055B71ABD60 00000055B71ABD60 0000000000000000  msvcrt.dll!_callthreadstartex+0x2b
00007FF869B30BCD 0000000000000000 0000000000000000 0000000000000000  msvcrt.dll!_threadstartex+0x7c
00007FF869BD13D2 00007FF869BD13B0 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk+0x22
00007FF86A3603C4 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x34

ecode's own stack-trace:

Stack trace (most recent call last):
#12   Object "", at 0x7ff869bd13d2, in BaseThreadInitThunk
#11   Object "", at 0x7ff869b30bcd, in endthreadex
#10   Object "", at 0x7ff869b30b13, in strupr
#9    Object "", at 0x7ff8411fe49a, in ZN2EE6System6Thread5getIdEv
#8    Object "", at 0x7ff8411feaf9, in ZN2EE6System10ThreadPool10threadFuncEv
#7    Object "", at 0x7ff8411c497b, in ZN2EE2UI3Doc12TextDocument12loadFromFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
#6    Object "", at 0x7ff8411c47ba, in ZN2EE2UI3Doc12TextDocument12loadFromFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
#5    Object "", at 0x7ff8411bab0b, in ZN2EE2UI3Doc12TextDocument11resetSyntaxEv
#4    Object "", at 0x7ff8411ba264, in ZN2EE2UI3Doc12TextDocument10fromBase64Ev
#3    Object "", at 0x7ff841919c40, in ZThn1344_N2EE2UI11UITextInput27onDocumentDirtyOnFileSystemEPNS0_3Doc12TextDocumentE
#2    Object "", at 0x7ff84191a54b, in ZThn1344_N2EE2UI11UITextInput27onDocumentDirtyOnFileSystemEPNS0_3Doc12TextDocumentE
#1    Object "", at 0x7ff841743a31, in ZN2EE6System3Zip7addFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_
#0    Object "", at 0x7ff8677a8b9c, in RaiseException

[Curculigo]

EE::System::Zip::addFile again. I have no idea why it's there.

[Curculigo]

BTW, I have the latest nightly. It seems you have never fixed it to also demangle the names in the stack-trace. You can see that the names are still mangled.

[SpartanJ]

Dragging 4 shell scripts without file extension into ecode and it crashed:

I cannot reproduce it even on Windows 8.1 but I can see where is the problem. I tried to fix it in the latest commit, I'm making a lot of changes so it might even more unstable.

BTW, this is not the first time I see EE::System::Zip in the stack-trace. I always wonder why it is there.

It's simply that the stack-trace does not have the right information to be precise, all the stack-traces are generating trash steps. I was only able to fix it by building with -g, which I don't consider it an option for now and -fno-omit-frame-pointer doesn't help at all.

Oh, it seems to happen randomly. I have just reproduced the crash.

It should be possible to trigger it by loading many different syntax languages at the same time. Although I wasn't able to reproduce it. I don't why you can so easily. But there was a bug there for sure.

BTW, I have the latest nightly. It seems you have never fixed it to also demangle the names in the stack-trace. You can see that the names are still mangled.

The demangling isn't important if the stack-trace is bad as it is right now (I can demangle it manually in a few seconds, so I don't mind). I'm using backward-cpp, and it's the library job to do it, I might switch to cpptrace later which seems much more maintained but I'm currently focused on debugging using the address sanitizer and fixing as many inconsistencies I find.

[Curculigo]

What do you think about upgrading the code base to C++23 and use std::stacktrace?

I modified premake5.lua and switch the CppDialect to C++23 and the code compiled fine with both GCC and Clang.

I only got some warnings on the third party subprocess.h and tabulate.

[SpartanJ]

I might give it a try but std::stacktrace support is quite limited even in 2025, it will depend on the compiler version and the platform.

This is a summary from grok:

• GCC:

  • Support for std::backtrace (part of the <stacktrace> header) is available starting with GCC 12.1.
  • To use it, you must compile with the -std=c++23 flag and link against the libstdc++_libbacktrace library using the -lstdc++_libbacktrace option. For GCC 13 and later, you can alternatively use -lstdc++exp, which consolidates experimental features, including std::backtrace.
  • Note that there were issues with GCC 13 builds on some platforms (e.g., Godbolt), where std::backtrace was not recognized due to missing configuration flags like _GLIBCXX_HAVE_STACKTRACE or the absence of libstdc++_libbacktrace.a. These were resolved in later builds (e.g., by February 2024).
  • GCC 14 and later integrate std::backtrace symbols into libstdc++exp.a, providing a smoother transition for users.
  • Debug information (e.g., compiled with -g) can affect the accuracy of stack trace symbol names, with differences observed between debug and non-debug builds.

• Clang:

  • Clang's support for std::backtrace is less consistent and lags behind GCC. As of Clang 17, std::backtrace is not fully supported out of the box in some environments, such as Godbolt, where it failed to compile due to missing library support.
  • There are indications that Clang had a partial implementation at some point, but it was reverted for unspecified reasons, possibly political or technical.
  • For platforms like Linux and macOS, Clang can leverage libunwind (part of its environment on macOS or available via libunwind on Linux) for stack unwinding, which could support std::backtrace if properly configured. However, there’s no clear evidence of full std::backtrace support in recent Clang versions.
  • To use std::backtrace with Clang, you may need to ensure debug information is enabled (e.g., with -g) and link against appropriate libraries, but specific flags or libraries are not well-documented for Clang.

• MSVC:

  • MSVC has experimental support for std::backtrace in C++23 mode, but it is not fully standardized or guaranteed to be complete. There’s limited public documentation on its implementation details.
  • Posts on X suggest that MSVC performs well in certain optimization scenarios related to stack traces, potentially outperforming GCC and Clang in specific cases. However, this is not specific to std::backtrace and may relate to general stack trace handling.
  • Unlike GCC, MSVC does not require additional linking flags like -lstdc++_libbacktrace, as its runtime environment typically includes necessary support for stack traces. However, the exact status of std::backtrace support in recent MSVC versions (e.g., Visual Studio 2022) is unclear from available sources, and it may still be considered experimental.

Summary

• GCC: Best support, available since 12.1 with -std=c++23 and -lstdc++_libbacktrace (or -lstdc++exp in GCC 13+). Fully functional with proper configuration, though debug info handling may vary.
• Clang: Limited and inconsistent support as of Clang 17. Partial implementations may exist, but issues like missing library support or reverted features hinder usability.
• MSVC: Experimental support, likely functional in recent versions, but lacks detailed documentation. May perform well in specific scenarios.

For the most reliable use of std::backtrace, GCC 12.1 or later is recommended. For Clang and MSVC, check the latest compiler documentation or test experimentally, as support may improve with newer releases. Always compile with debug symbols (-g) for better stack trace details across all compilers.

[SpartanJ]

BTW stack-traces are always excellent in Linux and macOS, Windows is always the problematic OS.