ecode crashes with ctrl-v since eepp commit 3985d81 - Fix build

[artix-artist]

Since eepp 'commit 3985d81 - Fix build', ecode crashes when pasting text using ctrl-v.

The error shown is:

/usr/include/c++/14.2.1/bits/basic_string.h:1364: constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::back() const [with _CharT = char32_t; _Traits = std::char_traits<char32_t>; _Alloc = std::allocator<char32_t>; const_reference = const char32_t&]: Assertion '!empty()' failed.

[artix-artist]

The problem seems to be from an earlier commit, maybe 2a88bac. With commit 577f2e3 there seems to be no issue.
After some more testing it seems the problem only occurs when pasting multi-line text, but not 1005 sure.

[SpartanJ]

Hi, thanks for reporting it. Can you share the complete stack-trace? Since it's not crashing for me.

Edit: also if you could clarify if this happened editing an specific language (and if using an specific LSP) or whatever information you can give me that could be useful.

[1muhgcmg]

Which OS? Which arch? Using nightly builds or building locally? Almost no information!

[artix-artist]

The language used is Plain Text.
The problem occurs when pasting multi-line text using Ctrl-v, but also using the mouse and clicking menu Edit / Paste.
The problem does not reproduce 100%; sometimes it takes starting ecode again several times before it shows.
The OS is Artix Linux, an Arch derivate.
The build is from the latest github commits of eepp and ecode.

This is the stack trace:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff65ff6c0 (LWP 28496)]
[New Thread 0x7ffff5dfe6c0 (LWP 28497)]
[New Thread 0x7ffff55fd6c0 (LWP 28498)]
[New Thread 0x7ffff4dfc6c0 (LWP 28499)]
[New Thread 0x7ffff45fb6c0 (LWP 28500)]
[New Thread 0x7ffff3dfa6c0 (LWP 28501)]
[New Thread 0x7ffff35f96c0 (LWP 28502)]
[New Thread 0x7ffff2df86c0 (LWP 28503)]
[New Thread 0x7ffff1abe6c0 (LWP 28504)]
[New Thread 0x7ffff12bd6c0 (LWP 28505)]
[New Thread 0x7ffff0abc6c0 (LWP 28506)]
[New Thread 0x7fffdd5ff6c0 (LWP 28507)]
[New Thread 0x7fffcd7ff6c0 (LWP 28508)]
[New Thread 0x7fffccffe6c0 (LWP 28509)]
[New Thread 0x7fffb7fff6c0 (LWP 28510)]
[Detaching after vfork from child process 28511]
[New Thread 0x7fffb77fe6c0 (LWP 28512)]
/usr/include/c++/14.2.1/bits/basic_string.h:1364: constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::back() const [with _CharT = char32_t; _Traits = std::char_traits<char32_t>; _Alloc = std::allocator<char32_t>; const_reference = const char32_t&]: Assertion '!empty()' failed.

Thread 1 "ecode" received signal SIGABRT, Aborted.
Downloading 4.48 K source file /usr/src/debug/glibc/glibc/nptl/pthread_kill.c
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44                                              
44	    return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) cont
Continuing.
Couldn't get registers: No such process.
(gdb) [Thread 0x7fffb77fe6c0 (LWP 28512) exited]
[Thread 0x7fffb7fff6c0 (LWP 28510) exited]
[Thread 0x7fffccffe6c0 (LWP 28509) exited]
[Thread 0x7fffcd7ff6c0 (LWP 28508) exited]
[Thread 0x7fffdd5ff6c0 (LWP 28507) exited]
[Thread 0x7ffff0abc6c0 (LWP 28506) exited]
[Thread 0x7ffff12bd6c0 (LWP 28505) exited]
[Thread 0x7ffff1abe6c0 (LWP 28504) exited]
[Thread 0x7ffff2df86c0 (LWP 28503) exited]
[Thread 0x7ffff35f96c0 (LWP 28502) exited]
[Thread 0x7ffff3dfa6c0 (LWP 28501) exited]
[Thread 0x7ffff45fb6c0 (LWP 28500) exited]
[Thread 0x7ffff4dfc6c0 (LWP 28499) exited]
[Thread 0x7ffff55fd6c0 (LWP 28498) exited]
[Thread 0x7ffff5dfe6c0 (LWP 28497) exited]
[Thread 0x7ffff65ff6c0 (LWP 28496) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

I have no idea why the 'Thread 1 "ecode" received signal SIGABRT,' occurs; the only action performed is pasting using the mouse and clicking on Edit / Paste.

[1muhgcmg]

You build locally or use the nightly builds from https://github.com/SpartanJ/eepp/releases/tag/nightly?

Can you try the AppImage on https://github.com/SpartanJ/eepp/releases/tag/nightly?

[artix-artist]

I build locally from git.

The image from https://github.com/SpartanJ/eepp/releases/tag/nightly has not yet crashed so seems to work OK.
That image has been statically linked; is there a script or procedue with which you build ecode so I can try do the same?

[SpartanJ]

This is the stack trace:

Sadly, that's not the stack-trace, I need to see the calls stack to understand where it was produced. In gdb that's usually seen with the bt command.

That image has been statically linked; is there a script or procedue with which you build ecode so I can try do the same?

I recommend a few things:
eepp source is now compiled for C++20 (from C++17), since around the beginning of April. Build must be regenerated from zero, so you need to regenerate the project, clean the object files and do a complete build.
I recommend using the build script provided by the project. The build instructions are [here](https://github.com/SpartanJ/ecode/?tab=readme-ov-file #build-from-source), which is just running a script. To ensure the object files are regenerated (complete rebuild) the easiest way is to just delete obj folder at the root folder of the project (or you could just make config=release_x86_64 clean it .
Also I recommend using the parameter --with-debug-symbols for the build.app.sh script. This will add the debug symbols to the binary and if the app crashes the backtrace will be printed to stdout, visible in the terminal.

So in short let's try to:

$ user@eepp> rm -r ./obj
$ user@eepp> cd projects/linux/ecode
$ user@eepp> ./build.app.sh --with-debug-symbols

in projects/linux/ecode/ecode you'll have the uncompressed build of ecode ready to run.

[artix-artist]

Thx for the info.

I first tried a build using the script without --with-debug-symbols to see how it works. Once it had build I tested the result and to my surprise I could not reproduce the problem. I then embedded the script into a pkgbuild file and had a build system create a package from it. Again to my surpise the resulting ecode did reproduce the problem.

Both times the same code is used, so the problem must be caused, or at least triggered, by soimething our package build system.
I will try to find out what it is, but in the mean time this issue can be closed.
If I find anything that can be of use I'll let you know.

[SpartanJ]

@artix-artist That's really weird. Can you point me out where is the pkcbuild recipe? Maybe I can spot something, and also I would like to try it.

[artix-artist]

@SpartanJ A pkgbuild file can be cloned or downloaded from the Arch User Repository: https://aur.archlinux.org/packages/ecode
And then be built by the makepkg tool.

[artix-artist]

When doing some testing and checking I got this stack trace, maybe it helps:

/usr/include/c++/14.2.1/bits/basic_string.h:1364: constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::const_reference std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::back() const [with _CharT = char32_t; _Traits = std::char_traits<char32_t>; _Alloc = std::allocator<char32_t>; const_reference = const char32_t&]: Assertion '!empty()' failed.
Stack trace (most recent call last):
#20   Object "/usr/lib/ld-linux-x86-64.so.2", at 0xffffffffffffffff, in 
#19   Object "/usr/lib/ecode/ecode", at 0x5a0b7d054e64, in 
#18   Source "../csu/libc-start.c", line 360, in __libc_start_main_impl [0x77fc64a395e9]
#17   Source "../sysdeps/nptl/libc_start_call_main.h", line 58, in __libc_start_call_main [0x77fc64a3952d]
#16   Object "/usr/lib/ecode/ecode", at 0x5a0b7d04eb07, in 
#15   Object "/usr/lib/ecode/ecode", at 0x5a0b7d1a82c7, in 
#14   Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc657f223e, in EE::Window::Window::runMainLoop(std::function<void ()>, int)
#13   Object "/usr/lib/ecode/ecode", at 0x5a0b7d19a20e, in 
#12   Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc6540587e, in EE::Window::Backend::SDL2::InputSDL::update()
#11   Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc65404fea, in EE::Window::Backend::SDL2::InputSDL::sendEvent(SDL_Event const&)
#10   Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc65401ec8, in EE::Window::Input::sendEvent(EE::Window::InputEvent*)
#9    Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc656e0f17, in EE::UI::UIEventDispatcher::inputCallback(EE::Window::InputEvent*)
#8    Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc65367e02, in EE::Scene::EventDispatcher::sendKeyDown(EE::Window::Keycode const&, EE::Window::Scancode const&, unsigned int const&, unsigned int const&)
#7    Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc65680a2a, in EE::UI::UICodeEditor::onKeyDown(EE::Scene::KeyEvent const&)
#6    Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc656897d9, in EE::UI::UICodeEditor::paste()
#5    Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc655dc827, in EE::UI::Doc::TextDocument::pasteText(EE::String&&)
#4    Object "/usr/lib/ecode/libs/libeepp.so", at 0x77fc654e64b2, in EE::String::back() const
#3    Source "/usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc", line 41, in __glibcxx_assert_fail [0x77fc64cd3351]
#2    Source "/usr/src/debug/glibc/glibc/stdlib/abort.c", line 73, in abort [0x77fc64a37668]
#1    Source "../sysdeps/posix/raise.c", line 26, in raise [0x77fc64a4f4d7]
#0    Source "/usr/src/debug/glibc/glibc/nptl/pthread_kill.c", line 44, in __pthread_kill_implementation [0x77fc64aa5dec]
Aborted (Signal sent by tkill() 29122 1000)

[SpartanJ]

Awesome, that's because yesterday I enabled to print the stack-traces, I was about to tell you.

[artix-artist]

I found the factor that triggers the crash:

When ecode is built with CXXFLAGS containing -D_GLIBCXX_ASSERTIONS the resulting code will be able to reproduce the crash.

This flag/variable enables run-time bounds checking for C++ strings and containers, and this check gets triggered when pressing ctrl-v and maybe an empty clipboard.

[SpartanJ]

Yes, with the stack-trace the problem is obvious, I just pushed a fix. Basically it should crash if the paste contents are actually empty! Because it's trying to access to back() when string is empty. I don't know how to generate an empty clipboard string but I think it it's fixed now. Thank you for reporting it. I'll re-opening it because this is an older bug, I'll put it "ready for release" and add it to the changelogs. Thanks!

Fix here.

[artix-artist]

Ah, good to hear an old bug has been fixed :-)
As far as I could test now, the fix from commit 4895f48 works.
Thanks!