mirror of
https://github.com/ocornut/imgui.git
synced 2026-11-10 19:03:30 +00:00
Assertion/crash in InputTextMultiline when pressing down-arrow on single empty line following text #6783
Labels
No labels
accidentally closed
android
backends
bug
building
clipper
coloredit
color spaces
cplusplus
data types
demo
disabled
doc
docking
dpi
drag drop
drawing/drawlist
dropped
dx12
enhancement
focus
font/text
gallery
help wanted
idle/power saving
ime
in progress
inputs
inputtext
internals
label/id and id stack
language bindings
layout
linux/bsd
menus
multi-contexts
multi-threading
multi-viewports
nav
news/info
opengl
optimization
osx/ios
overlap
plot/graph
popups
question
scrolling
selection
settings
sliders/drags
style
tables/columns
tabs
test wanted
tools
tooltips
tree
tricks & tips
useful widgets
vulkan
web
window pos/depth
window sizing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ocornut/imgui#6783
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Version/Branch of Dear ImGui:
My Issue/Question:
Pressing down-arrow within an
InputTextMultiline()on a final, single, empty line following some text causes an assertion.It seems to be triggered by an out-of-range index on line 883 of
imstb_textedit.h.Video:
inputtextmultiline-assert.webm
Stacktrace:
Standalone, minimal, complete and verifiable example:
Confirmed like a bug related to some our of changes in InputText logic. Reproducible with raw
const char*version.Regression added by commit
57a5b73a4cfor #6000Pushed fix
d8ef864+ more regression testsocornut/imgui_test_engine@f0f74be707It seems the issue was in the last two lines changed in
57a5b73a4c, to be able to test assertions and see where this was exercised I simply put a breakpoint in there and ran the test suite, then tried to understand why the test seemed like they worked.I'm honestly surprisingly this wasn't noticed earlier, but essentially it wouldn't happen if the underlying buffer was big enough to contains the overflow. Added a better assert in
STB_TEXTEDIT_GETCHAR().