Crash on Linux on export to PDF when selecting an existing and sufficiently complicated file on trying to preview it
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S1 - Blocker
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
With a new file I made with one treble stave (others too), I can reproduce a crash by trying to export a pdf. When the file selector has opened, I click on a pdf-file, that exists - musescore probably tries to preview it: I see "Initializing staves / systems ... 75%", then the program crashes.
Comments
That "Initializing staves / systems ... 75%", should only show up then you try to import a PDF, not on export?
You're on Linux, right? May make a difference because it uses the Qt file selector, not the native OS one like on Mac and Windows.
I can't reproduce any crash using export on Linux, and indeed that message sounds like an attempt to import. But I can't reproduce that either. We'd need more precise steps.
My mistake - I tested on Windows; my Linux machine is elsewhere right now. Still, the description seems unclear.
... I cannot reproduce it on my other computer (same Linux, same Qt, same musescore version, but here Intel-based; the other is AMD-based).
But also here there is a sort of preview in the fileselector box, but no crash.
1. I click on export, pdf is preset, the fileselector pops up
![FileselectorMusescoreLinux.png]( "FileselectorMusescoreLinux.png")
2. it sets to "filename".pdf
3. Then I click on an existing pdf
4. Then there seems to be made a preview version (this is, where musescore on my other computer crashes), although this not at all a real preview right beside the filenames.
5. Then a dialogue pops up, saying "do you want to replace the file"
Ok, I can reproduce it also here, at least if the musescore-pdf is more complicated - as is my table of baroque lute ornaments. If I click on this pdf to choose that name the "preview" crashes the program.
Hopefully a better title?
Can't confirm a crash with OpenSuse Leap so far (same nightly version).
That means, I can confirm the behavior in the export window that the export takes a while for initialization and show as preview a score with empty measures, but the pdf export doesn't produce a crash. Maybe because I don't have so complicated scores.
(and yes the initialization procedure for a preview happens in the export window when you click on an existing pdf to overwrite)
Maybe you can attache one of the special files, which produce the crash.
Further: Is there no error message/output if you're starting MuseScore from terminal?
(btw: the last appimage is seven days ago, is this correct?)
I believe it is the score from https://musescore.org/en/node/139851
Can confirm the crash with "Baroque_Lute.pdf" on OpenSuse.
1. Open a own file
2. File-Export...
3. click on "Baroque_Lute.pdf"
--> Crash.
output in the terminal:
readPdf: 1 pages
*** no staff lines found
/tmp/.mount_8AIQpH/AppRun: Zeile 18: 15184 Speicherzugriffsfehler "${APPDIR}/bin/mscore-portable-nightly" "$@"
When I create the pdf file new from the mscz-file (and the steps as described):
readPdf: 1 pages
/tmp/.mount_kudKrp/AppRun: Zeile 18: 15282 Speicherzugriffsfehler "${APPDIR}/bin/mscore-portable-nightly" "$@"
(without the line: "*** no staff lines found")
Indeed it was that file, that caused the program to crash; but on my other computer it even crashed with a very simple file. If I will have the opportunity tommorow, I will also try to start it within a terminal ...
When I remove the horizontal frames, save and export the file, than steps as described, this doesn't produce a crash on my system.
Further investigation:
I've reentered the horizontal frames step by step.
The crash occurs after creating the second horizontal frame in the last line/system of the score.
See attached files:
BaroqueLute_Ornaments5.mscz -> no crash with the described steps to reproduce
BaroqueLute_Ornaments6.mscz -> crash with the described steps to reproduce
The child of #271331: [EPIC] Positioning, symbols, notation related issues
probably related to "native file dialogs", see also #154426: crash when switching dir while opening file
and indeed if I switch useNativeDialogs to false (needed on Windows, default on Linux) and then in the file dialog (either open or export as PDF) select (single click) an existing PDF, MuseScore crashes right away.
Actually it crashes on an assertion failure:
Fatal: ASSERT: "!isEmpty()" in file C:/Qt/5.12.0/mingw73_64/include/QtCore/qlist.h, line 351 (C:/Qt/5.12.0/mingw73_64/include/QtCore/qlist.h:351, )
Maybe a duplicate of #9720: Loading a PDF causes crash
The fix might be a different one though, the thumbnail for the file selector should not be generated by trying to import the PDF.
and the workaround is to set useNativeDialogs to true
Fixed in branch master, commit 7e3f03b709
fix #140296
The crash happens when mscore tries to create a preview image of an score in
the open file browser (not native file dialog set) and the score happens to be an
pdf. This fix makes sure that previews are only created for *.mscx and *.mscz files.
Automatically closed -- issue fixed for 2 weeks with no activity.