[Bug] SIGABRT in `TextEditor::MoveHome`
Operating System
Linux
What's the issue you encountered?
I'm seeing a crash while editing patterns in ImHex's built-in editor.
Backtrace
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=0x6, no_tid=no_tid@entry=0x0)
at pthread_kill.c:44
#1 0x00007ffff6ca56d3 in __pthread_kill_internal (threadid=<optimized out>, signo=0x6) at pthread_kill.c:89
#2 0x00007ffff6c4bba0 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff6c33582 in __GI_abort () at abort.c:73
#4 0x00007ffff6ed3f70 in std::__glibcxx_assert_fail (
file=file@entry=0x7ffff7b78108 "/usr/include/c++/14.2.1/bits/stl_vector.h", line=line@entry=0x46a,
function=function@entry=0x7ffff7baa588 "constexpr std::vector< <template-parameter-1-1>, <template-parameter-1-2> >::reference std::vector< <template-parameter-1-1>, <template-parameter-1-2> >::operator[](size_type) [with _Tp = TextEditor::Glyph; _Alloc = std::allocator<TextEditor::Glyph>; reference = TextEditor::Glyph&; size_type = long unsigned int]", condition=condition@entry=0x7ffff7b66079 "__n < this->size()")
at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41
#5 0x00007ffff7aa1510 in std::vector<TextEditor::Glyph, std::allocator<TextEditor::Glyph> >::operator[] (
this=<optimized out>, __n=<optimized out>) at /usr/include/c++/14.2.1/bits/stl_vector.h:1130
#6 TextEditor::MoveHome (this=0x7fffdc4313d8, aSelect=0x1)
at /usr/src/debug/imhex/ImHex/lib/third_party/imgui/ColorTextEditor/source/TextEditor.cpp:1875
#7 0x00007ffff73eb042 in std::function<void()>::operator() (this=0x7fffdc431370)
at /usr/include/c++/14.2.1/bits/std_function.h:591
#8 hex::processShortcut (shortcut=..., shortcuts=std::map with 49 elements = {...})
at /usr/src/debug/imhex/ImHex/lib/libimhex/source/api/shortcut_manager.cpp:337
#9 0x00007ffff73ebeba in hex::ShortcutManager::runShortcut (shortcut=..., view=view@entry=0x7fffdc4312a0)
at /usr/include/c++/14.2.1/bits/stl_tree.h:708
#10 0x00007ffff73ec229 in hex::ShortcutManager::process (currentView=0x7fffdc4312a0, ctrl=<optimized out>, alt=0x0,
shift=<optimized out>, super=<optimized out>, focused=focused@entry=0x1, keyCode=0x10c)
at /usr/src/debug/imhex/ImHex/lib/libimhex/source/api/shortcut_manager.cpp:362
#11 0x00005555555930d1 in hex::Window::frame (this=this@entry=0x7fffffffd420)
at /usr/include/c++/14.2.1/bits/unique_ptr.h:193
#12 0x0000555555593c20 in hex::Window::fullFrame (this=0x7fffffffd420)
at /usr/src/debug/imhex/ImHex/main/gui/source/window/window.cpp:238
#13 0x0000555555593dbb in hex::Window::loop (this=0x7fffffffd420)
at /usr/src/debug/imhex/ImHex/main/gui/source/window/window.cpp:293
#14 0x00005555555c11fd in hex::init::runImHex () at /usr/src/debug/imhex/ImHex/main/gui/source/init/run/native.cpp:43
#15 0x00007ffff6c35488 in __libc_start_call_main (main=main@entry=0x555555578f40 <main(int, char**)>,
argc=argc@entry=0x4, argv=argv@entry=0x7fffffffd958) at ../sysdeps/nptl/libc_start_call_main.h:58
#16 0x00007ffff6c3554c in __libc_start_main_impl (main=0x555555578f40 <main(int, char**)>, argc=0x4,
argv=0x7fffffffd958, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffd948) at ../csu/libc-start.c:360
#17 0x000055555557c385 in _start ()
Looking at the source, this happens on lines that only contains spaces:
auto home=0;
while (isspace(line[home].mChar))
home++;
We're going out-of-bounds in the crashing call trying to find the first non-space character:
gef➤ p mLines[mState.mCursorPosition.mLine]
$5 = std::vector of length 4, capacity 4 = {{
mChar = 0x20, [...]
}, {
mChar = 0x20, [...]
}, {
mChar = 0x20, [...]
}, {
mChar = 0x20, [...]
}}
How can the issue be reproduced?
Press Home key on an empty line
ImHex Version
1.37.4
ImHex Build Type
- [ ] Nightly or built from sources
Installation type
Arch AUR
Additional context?
No response
Yes, good catch. Bug was introduced when it was requested that home should go to first non-space character in the line. I completely missed checking if line was empty first. I'll patch it and post a PR. will let you know when it gets merged so you can check it. Thanks for taking the time to provide an extended analysis.
This bug was fixed in a recently merged PR (#2193). You can download a nightly build from GitHub actions to confirm that the bug no longer occurs so that this issue can be closed as resolved.
Looks good. Thanks!