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.

[Curculigo]

A ton of new features being added. Expect a lot of crashes, too. This is the latest nightly build for Windows. It seems something to do with the file dialog, as I'm typing a new name for untitled to save it and suddenly ecode crashed. Weird, the native file dialogs is not yet added.

Stack trace (most recent call last): #31 Object "", at 0x7ffdbcf813d2, in BaseThreadInitThunk #30 Object "", at 0x7ff632e114e6, in ?? #29 Object "", at 0x7ff632e113c4, in ?? #28 Object "", at 0x7ff6337ab943, in ?? #27 Object "", at 0x7ff632f3a184, in ?? #26 Object "", at 0x7ffd94945e53, in ZN2EE6Window6Window11runMainLoopESt8functionIFvvEEi #25 Object "", at 0x7ff632f2296b, in ?? #24 Object "", at 0x7ffd9464c578, in ZN2EE5Scene12SceneManager4drawEv #23 Object "", at 0x7ffd9464de16, in ZN2EE5Scene9SceneNode4drawEv #22 Object "", at 0x7ffd94610d52, in ZN2EE5Scene4Node12drawChildrenEv #21 Object "", at 0x7ffd94880857, in ZN2EE2UI6UINode8nodeDrawEv #20 Object "", at 0x7ffd94610d52, in ZN2EE5Scene4Node12drawChildrenEv #19 Object "", at 0x7ffd94880857, in ZN2EE2UI6UINode8nodeDrawEv #18 Object "", at 0x7ffd94610d52, in ZN2EE5Scene4Node12drawChildrenEv #17 Object "", at 0x7ffd94880857, in ZN2EE2UI6UINode8nodeDrawEv #16 Object "", at 0x7ffd94610d52, in ZN2EE5Scene4Node12drawChildrenEv #15 Object "", at 0x7ffd94880857, in ZN2EE2UI6UINode8nodeDrawEv #14 Object "", at 0x7ffd94610d52, in ZN2EE5Scene4Node12drawChildrenEv #13 Object "", at 0x7ffd94880857, in ZN2EE2UI6UINode8nodeDrawEv #12 Object "", at 0x7ffd94610d52, in ZN2EE5Scene4Node12drawChildrenEv #11 Object "", at 0x7ffd94880857, in ZN2EE2UI6UINode8nodeDrawEv #10 Object "", at 0x7ffd94610d52, in ZN2EE5Scene4Node12drawChildrenEv #9 Object "", at 0x7ffd948809c8, in ZN2EE2UI6UINode8nodeDrawEv #8 Object "", at 0x7ffd94877f11, in ZN2EE2UI6UINode10drawBorderEv #7 Object "", at 0x7ffd947dd9cb, in ZN2EE2UI16UIBorderDrawable4drawERKNS_4Math7Vector2IfEERKNS2_5tSizeIfEE #6 Object "", at 0x7ffd9493da04, in ZN2EE8Graphics15VertexBufferVBO4drawEv #5 Object "", at 0x7ffd9407961c, in DrvSetLayerPaletteEntries #4 Object "", at 0x7ffd93e67264, in DrvSetLayerPaletteEntries #3 Object "", at 0x7ffd93e464e2, in DrvSetLayerPaletteEntries #2 Object "", at 0x7ffd93e46aef, in DrvSetLayerPaletteEntries #1 Object "", at 0x7ffd93d596b6, in DrvSetLayerPaletteEntries #0 Object "", at 0x7ffd93e3d8dd, in DrvSetLayerPaletteEntries 

ecode.exe caused an Access Violation at location 00007FFD93E3D8DD in module ig75icd64.dll Reading from location 0000000000000028. AddrPC Params 00007FFD93E3D8DD 000000731686EA01 0000007300000000 0000000000000000 ig75icd64.dll!DrvSetLayerPaletteEntries+0x11ef6d 00007FFD93D596B6 000000731689A4C0 00007FFD93E668DB 0000007319BE62B8 ig75icd64.dll!DrvSetLayerPaletteEntries+0x3ad46 00007FFD93E46AEF 0000000000000000 000000731686EA00 0000007300000000 ig75icd64.dll!DrvSetLayerPaletteEntries+0x12817f 00007FFD93E464E2 000000731686EA00 0000000000000000 0000000000000005 ig75icd64.dll!DrvSetLayerPaletteEntries+0x127b72 00007FFD93E67264 000000731686EA00 0000000000000000 0000000000000005 ig75icd64.dll!DrvSetLayerPaletteEntries+0x1488f4 00007FFD9407961C 000000731110C4E8 0000007319D1FDF0 000000731110D420 ig75icd64.dll!DrvSetLayerPaletteEntries+0x35acac 00007FFD9493DA04 0000000000000000 0000000000000002 0000000000000000 eepp.dll!EE::Graphics::VertexBufferVBO::draw+0x104 00007FFD947DD9CB 0000007319BE5FD0 00007FFD94610D52 0000000000000000 eepp.dll!EE::UI::UIBorderDrawable::draw+0xcb 00007FFD94877F11 000000731110C4CC 0000007312FFC3A0 000000001110C614 eepp.dll!EE::UI::UINode::drawBorder+0xc1 00007FFD948809C8 0000000000000000 0000000000000000 0000000000000000 eepp.dll!EE::UI::UINode::nodeDraw+0x448 00007FFD94610D52 000000731110C59C 00007FFD94608672 2C054000000003CD eepp.dll!EE::Scene::Node::drawChildren+0xb2 00007FFD94880857 0000000000000000 0000000000000000 0000000000000000 eepp.dll!EE::UI::UINode::nodeDraw+0x2d7 00007FFD94610D52 000000731686EA00 00007FFD94608672 000000003F800000 eepp.dll!EE::Scene::Node::drawChildren+0xb2 00007FFD94880857 0000000000000000 0000000000000000 0000000000000000 eepp.dll!EE::UI::UINode::nodeDraw+0x2d7 00007FFD94610D52 00000000000003CD 00007FFD94608672 00007FFD951DDB28 eepp.dll!EE::Scene::Node::drawChildren+0xb2 00007FFD94880857 0000000000000000 0000000000000000 0000000000000000 eepp.dll!EE::UI::UINode::nodeDraw+0x2d7 00007FFD94610D52 000000731110C80C 00007FFD94608672 0000000000000000 eepp.dll!EE::Scene::Node::drawChildren+0xb2 00007FFD94880857 0000000000000000 0000000000000000 0000000000000000 eepp.dll!EE::UI::UINode::nodeDraw+0x2d7 00007FFD94610D52 304C1A7F78050005 00000073193A5B00 000000731110C9BC eepp.dll!EE::Scene::Node::drawChildren+0xb2 00007FFD94880857 0000000000000000 0000000000000000 0000000000000000 eepp.dll!EE::UI::UINode::nodeDraw+0x2d7 00007FFD94610D52 000000731110CA60 00007FFD94608672 0000007311336490 eepp.dll!EE::Scene::Node::drawChildren+0xb2 00007FFD94880857 0000000000000000 0000000000000000 000000000000003B eepp.dll!EE::UI::UINode::nodeDraw+0x2d7 00007FFD94610D52 0000000000000000 000003CD00000690 3FF0000000000000 eepp.dll!EE::Scene::Node::drawChildren+0xb2 00007FFD9464DE16 0000000000000690 0000000000000000 0000000000000690 eepp.dll!EE::Scene::SceneNode::draw+0x326 00007FFD9464C578 00007FFD00004500 00007FFD9464C240 00007FFD94945950 eepp.dll!EE::Scene::SceneManager::draw+0x28 00007FF632F2296B 00000073197390C0 000000731110CE90 000000731110CF20 ecode.exe!0x11296b 00007FFD94945E53 00007FFDBC693D60 00000073197B1C20 0000007312F4B4BD eepp.dll!EE::Window::Window::runMainLoop+0xc3 00007FF632F3A184 0000000000000000 0000000000000000 0000000000000000 ecode.exe!0x12a184 00007FF6337AB943 0000000000000004 0000007311207490 00007FF63229F000 ecode.exe!0x99b943 00007FF632E113C4 0000000000000000 0000000000000000 0000000000000000 ecode.exe!0x13c4 00007FF632E114E6 0000000000000000 0000000000000000 0000000000000000 ecode.exe!0x14e6 00007FFDBCF813D2 00007FFDBCF813B0 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk+0x22 00007FFDBD5E03C4 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart+0x34 

ecode is crashing the Intel integrated graphics driver on my machine?

[SpartanJ]

Hi, this is a rendering bug, I experienced the same crash last night on macOS, it was fixed in the next commit than the one you reproduced it. Oddly enough the bug is really old (years old!) but several things need to happen to trigger, it seems that casually that happened to both of us at almost the same time due to how elements arrange in the screen. I experienced the crash in completely different places than you, it has nothing to do with the file dialog and it was not introduced with any of the recent changes. Thanks for reporting it.

[Curculigo]

Thank you for fixing it so quickly. Yes, I have also experienced it on the folder search box, too.

[Curculigo]

Latest nightly. Crashed again. This time is when I want to change the monospace font.

Stack trace (most recent call last): #16 Object "", at 0x7ffa67f313d2, in BaseThreadInitThunk #15 Object "", at 0x7ff6c5ab14e6, in ?? #14 Object "", at 0x7ff6c5ab13c4, in ?? #13 Object "", at 0x7ff6c644ba8b, in ?? #12 Object "", at 0x7ff6c5bda3b4, in ?? #11 Object "", at 0x7ffa42edacb3, in ZN2EE6Window6Window11runMainLoopESt8functionIFvvEEi #10 Object "", at 0x7ff6c5bc2bde, in ?? #9 Object "", at 0x7ffa42bdc7f3, in ZN2EE5Scene12SceneManager6updateEv #8 Object "", at 0x7ffa42e31daf, in ZN2EE2UI11UISceneNode6updateERKNS_6System4TimeE #7 Object "", at 0x7ffa42be0fb0, in ZN2EE5Scene9SceneNode6updateERKNS_6System4TimeE #6 Object "", at 0x7ffa42ad5689, in ZN2EE5Scene15EventDispatcher6updateERKNS_6System4TimeE #5 Object "", at 0x7ffa42b9a2d3, in ZN2EE5Scene4Node11messagePostEPKNS0_11NodeMessageE #4 Object "", at 0x7ffa42dfdae1, in ZN2EE2UI6UIMenu9onMessageEPKNS_5Scene11NodeMessageE #3 Object "", at 0x7ffa42b9f622, in ZN2EE5Scene4Node9sendEventEPKNS0_5EventE #2 Object "", at 0x7ff6c5d6b7cc, in ?? #1 Object "", at 0x7ff6c63abde3, in ?? #0 Object "", at 0x7ff6c5bb9f18, in ?? 

ecode.exe caused an Access Violation at location 00007FF6C5BB9F18 in module ecode.exe Reading from location FFFFFFFFFFFFFFFF. AddrPC Params 00007FF6C5BB9F18 00000075E367AA90 00000075E367ADF0 00000075E181C5C0 ecode.exe!0x109f18 00007FF6C63ABDE3 00000075EA5F9EF0 00007FFA42B99AD0 00000075EA430950 ecode.exe!0x8fbde3 00007FF6C5D6B7CC 00000075E4C8CF38 00000075E181C718 00000000449CC000 ecode.exe!0x2bb7cc 00007FFA42B9F622 00007FFA42E15A60 00000075E181D1C0 00000075EA300D40 eepp.dll!EE::Scene::Node::sendEvent+0x1b2 00007FFA42DFDAE1 00000075EA300D40 0000007500000007 000001F70000044C eepp.dll!EE::UI::UIMenu::onMessage+0x251 00007FFA42B9A2D3 00000075E181D1C0 00000075E368A320 00000000000001B3 eepp.dll!EE::Scene::Node::messagePost+0x43 00007FFA42AD5689 0004E1137FFFC890 00000075E181C8C0 00007FF6C5BA9BD0 eepp.dll!EE::Scene::EventDispatcher::update+0x559 00007FFA42BE0FB0 00000000000001B3 000000751D3970D3 0004E10A00007F00 eepp.dll!EE::Scene::SceneNode::update+0x540 00007FFA42E31DAF 0000044C61010001 00007FFA000001F7 0000050100000501 eepp.dll!EE::UI::UISceneNode::update+0x7f 00007FFA42BDC7F3 00007FFA00004500 00007FFA42BDC420 00007FFA42EDA7B0 eepp.dll!EE::Scene::SceneManager::update+0x43 00007FF6C5BC2BDE 00000075E9F27DE0 00000075E181CC20 00000075E181CCB0 ecode.exe!0x112bde 00007FFA42EDACB3 00007FFA67F13D60 00000075E9EC6690 00000075E367B03D eepp.dll!EE::Window::Window::runMainLoop+0xc3 00007FF6C5BDA3B4 0000000000000000 0000000000000000 0000000000000000 ecode.exe!0x12a3b4 00007FF6C644BA8B 0000000000000002 00000075E1CBAEB0 00007FF6C523F000 ecode.exe!0x99ba8b 00007FF6C5AB13C4 0000000000000000 0000000000000000 0000000000000000 ecode.exe!0x13c4 00007FF6C5AB14E6 0000000000000000 0000000000000000 0000000000000000 ecode.exe!0x14e6 00007FFA67F313D2 00007FFA67F313B0 0000000000000000 0000000000000000 KERNEL32.DLL!BaseThreadInitThunk+0x22 00007FFA699403C4 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!RtlUserThreadStart+0x34 

[Curculigo]

It always crashes when I click on Window -> Monospace Font...

[SpartanJ]

It's the native file dialog, let me check what's going on.

[Curculigo]

Maybe related: On my system, Settings -> View -> Show Line Endings shows the line endings as square boxes.

p/s: I don't use --text-sharper. I have removed it for a while.

[Curculigo]

It's the native file dialog, let me check what's going on.

Yes. I have the native file dialog turned on.

[SpartanJ]

Thanks for reporting it, I already pushed a fix.