Crash when exiting text edit mode
Steps:
1- open My_first_Score;
2- double-click on title text "Title" to enter text edit mode;
3- click outside the text to exit text edit mode -> crash
Windows 8.1 and Linux Mint 17.1, commit 140a510
Attached gdb backtrace
Attachment | Size |
---|---|
text_edit_crash.txt | 4.54 KB |
Comments
I'm not seeing this on my custom build (not debug) under Windows 8.1u1 64bit (5d49b86), Qt 5.4.0
double post
Yes! I'm fight this all day now! How did you get the stack trace?
I only got
Fatal: ASSERT failure in QVector::operator[]: "index out of range", file C:/Qt/5.4/mingw491_32/include/QtCore/qvector.h, line 396 (:0, )
And an exit, no stack
It is happing every time you use a click somewhere to exit any edit mode (almost any? not on chord symbols apparently)
The top stack frame still in MuseScore code is:
qreal a = grip[0].width() * 1.0;
And there is a recent change, 16764d4, related to that
(and your 140a510 is a few commit younger)
So, I'm betting there are no grips, so grip[0] is bogus. If so, and if it's OK that text elements have no grip (I guess that is something that changed with a recent commit), then surrounding this passage with "if (grips)" would solve the problem. But if the text element is suppsoed to have a grip, then I don't know where / how to make that change.
Before the change to the grip code, "grips" was 0 also, so I think it's fine that text elements have no grip. it's just that previously, "grip" was a static array of size MAX_GRIPS, and now it is dynamically allocated. So indeed, that looks like the fix - just protect that whole section of code with "if (grips)".
See https://github.com/musescore/MuseScore/pull/1654
Fixed in 36de96e0ce
Thanks for the quick fix!
@Jojo-Schmitz:
I obtained the stack trace with a "trick" :-)
I run mscore in gdb under Linux, because in cases like this one (qAssert) gdb doesn't give the full stack trace under Windows (probably the application has already exited at the qAssert).
I think that under Windows a full backtrace can be obtained by putting a breakpoint at qFatal or qAssert. See also http://www.qtcentre.org/threads/8306-Back-tracing-asserts-with-gdb
Automatically closed -- issue fixed for 2 weeks with no activity.