1. Create new score (Guitar or Bass Tab)
2. Attempt to enter note.
3. Application stops responding.
Linux Mint 12, 64bit
[ I recorded/saved a screencast of the process (it really *is* as simple as 1-2-3, exactly as outlined above), but none of the allowed file extensions here include any sort of video format. (tab_crash.mp4 1.6M)]
briand, we do not question that you are experiencing a crash. However this bug still needs more information until others can reproduce the crash consistently.
I recognize that it can be frustrating when you can reproduce a crash consistently, but others can't.
Being as specific as possible can help. What method of note entry are you using? (computer keyboard, MIDI, mouse) Are you building your own version or using a nightly? Does the nightly work for you? Does your build have any modifications from the main trunk? etc.
"make version" at the terminal prompt reports: 2.0b5478M
I build the application from SVN source. There are no modifications made to the source other than those downloaded via subversion (ie: I'm not editing the source code, adding or deleting modules, or anything of the sort. I download the source, it compiles without error, and I run the application.
Method of note entry does not seem to play into the problem. Mouse-clicking or computer keyboard entry of a note on the TAB staff cause the issue. I do not have any of my MIDI equipment attached to this computer at this time.
My computer is an i5-2500K quad-core CPU, with 8GB of RAM, built-in HD3000 intel graphics (SandyBridge chipset), and 1.25TB of drive space. OS is Linux Mint 12, 64bit, desktop environment is Gnome 3.2.
[Linux helix 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux]
I can consistently reproduce this problem, with or without any other user applications running on the system. At the time that the application stops responding (crashes), the mscore process typically has one core of the CPU throttled up to 100% utilization. I have waited up to an hour for it to finish doing whatever it though it was doing, but it doesn't seem to recover. Since I'm launching the application from a terminal prompt, I can terminate the mscore process by typing Ctrl-C in the terminal (and can see any/all messages sent to the terminal screen by the application while it is running [incidentally, "akkumulated" is actually spelled "accumulated" ;)]) at which point all four CPU cores return to their 'normal' 2-3% utilization.
If you have a server that will accept a 1-2M mp4 file, I will gladly submit a screencast of the entire process, so you can watch it occur from the moment of program invocation until the program stops responding.
1) Does the program work correctly with 'regular' staff (non-TAB) note entry?
2) Can you run and test a pre-built nightly binary? (just in case there is something non-standard in your dev environment)
Lastly, you may ZIP the screen-cast: ZIP is an accepted extension for file attachments. Or you may upload to some on-line storage site and post the link, if you prefer.
1) yes, as far as I can tell, the program works fine with 'regular' stuff. I've created normal (treble & bass) staves, etc, and was able to add, delete, edit notes, etc. with no issues.
2) I originally tried to run a pre-built binary, before I installed the development tools, Qt development stuff, etc. The linux 'file' command indicated it was an "ELF Binary", but beyond that, I have no clue what I was supposed to do with it; I made the file executable and attempted to run it, but nothing happened -- again, this was before I had any of the Qt stuff installed, so maybe that's why it didn't work? :shrug: anyway, yes, I'll download another one and try it, if you think it'll help. Where do I find the 64 bit Linux nightly build file? (and, optionally, what exactly am I expected to do with the file once downloaded?)
I'll record a new screencast and attach it to this ticket.
I have two screencasts to show you, as the first crash recorded was significantly different that what I "typically" see. The second one shows the typical "lockup" crash that I see. (as an aside, I was able to enter 2 notes without a problem, but the program locked up when i hit "E" to enter the third note; usually it locks up upon entering the first note)
Great you have made two screencasts briand. We should all use this more. But to make it even more easy, try using http://screenr.com This way we don't have to hassle with uploading screencasts, downloading them, unzipping etc. Instead, it's just a link. Easy.
okay... thanks for the links, but I'll stick with the option built into my operating system that doesn't require a connection to the internet. meanwhile, this is a bug tracker, not a forum for discussing the merits of various screencast mechanisms.
Could you give the exact steps for the second crash? (Which keys did you press for the first notes? Does this sequence of notes consistently crash at the same place?)
more clues, from the video: questions that might be asked -- should note entry on a tablature staff be placing some symbol a dozen ledger lines above the staff? (hint: there are no ledger lines in TAB notation) in other words, there might be something larger amiss, behind the scenes in 64bit linux builds. as an aside, where I note above that note entry on a 'regular' staff works fine, i should point out that the first note I enter on a score ('C', entered by typing the 'C' on my computer keyboard) also shows up several ledger lines above the top of whatever staff I'm using.
I can reproduce the issue running with "mscore -s". The terminal output, crashing, etc are identical to what is seen in the video screencast. There is, however, no sound emitted at the time of the crash, when using the "-s" parameter; occasionally, previous crashes would emit a note (presumably a C, but I don't have perfect pitch, so I can't be sure) at the time of note entry, before the program has finished crashing.
I have no issues with sound recording or sound reproduction on this machine. A screen capture of the Preferences->I/O dialog is attached, per your request.
Qt version here is the latest available in the linux mint (ubuntu) repositories. (Version: 4:4.7.4-0ubuntu8.1)
I hear you (and everybody else) saying that you are unable to recreate the issue. Again, I reiterate that I am running on a 64-bit Linux system, and again ask if anybody running *that* architecture has tried and failed to reproduce this issue.
Comments
Add "trunk" to title
fixed in r3662
Automatically closed -- issue fixed for 2 weeks with no activity.
Can this be "automatically re-opened" ?
I am experiencing this exact behavior in [trunk] 5470.
It is not crashing for me when I follow the exact steps listed in the original bug report.
(tested using r. 5471 nightly, Windows 7)
Working ok for me in R5471 when following original crash instructions.
Wndows XP Pro SP3
Still not working for me in R5478.
1. Create new score (Guitar or Bass Tab)
2. Attempt to enter note.
3. Application stops responding.
Linux Mint 12, 64bit
[ I recorded/saved a screencast of the process (it really *is* as simple as 1-2-3, exactly as outlined above), but none of the allowed file extensions here include any sort of video format. (tab_crash.mp4 1.6M)]
changed status back to active.
briand, we do not question that you are experiencing a crash. However this bug still needs more information until others can reproduce the crash consistently.
I recognize that it can be frustrating when you can reproduce a crash consistently, but others can't.
Being as specific as possible can help. What method of note entry are you using? (computer keyboard, MIDI, mouse) Are you building your own version or using a nightly? Does the nightly work for you? Does your build have any modifications from the main trunk? etc.
I'm downloading R5471 for Linux
I will try it on my Linux box which is running Mint 11 Katya and report back
David -
"make version" at the terminal prompt reports: 2.0b5478M
I build the application from SVN source. There are no modifications made to the source other than those downloaded via subversion (ie: I'm not editing the source code, adding or deleting modules, or anything of the sort. I download the source, it compiles without error, and I run the application.
Method of note entry does not seem to play into the problem. Mouse-clicking or computer keyboard entry of a note on the TAB staff cause the issue. I do not have any of my MIDI equipment attached to this computer at this time.
My computer is an i5-2500K quad-core CPU, with 8GB of RAM, built-in HD3000 intel graphics (SandyBridge chipset), and 1.25TB of drive space. OS is Linux Mint 12, 64bit, desktop environment is Gnome 3.2.
[Linux helix 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux]
I can consistently reproduce this problem, with or without any other user applications running on the system. At the time that the application stops responding (crashes), the mscore process typically has one core of the CPU throttled up to 100% utilization. I have waited up to an hour for it to finish doing whatever it though it was doing, but it doesn't seem to recover. Since I'm launching the application from a terminal prompt, I can terminate the mscore process by typing Ctrl-C in the terminal (and can see any/all messages sent to the terminal screen by the application while it is running [incidentally, "akkumulated" is actually spelled "accumulated" ;)]) at which point all four CPU cores return to their 'normal' 2-3% utilization.
If you have a server that will accept a 1-2M mp4 file, I will gladly submit a screencast of the entire process, so you can watch it occur from the moment of program invocation until the program stops responding.
Hi briand,
Just to be extra-sure:
1) Does the program work correctly with 'regular' staff (non-TAB) note entry?
2) Can you run and test a pre-built nightly binary? (just in case there is something non-standard in your dev environment)
Lastly, you may ZIP the screen-cast: ZIP is an accepted extension for file attachments. Or you may upload to some on-line storage site and post the link, if you prefer.
Thanks,
M.
M. --
1) yes, as far as I can tell, the program works fine with 'regular' stuff. I've created normal (treble & bass) staves, etc, and was able to add, delete, edit notes, etc. with no issues.
2) I originally tried to run a pre-built binary, before I installed the development tools, Qt development stuff, etc. The linux 'file' command indicated it was an "ELF Binary", but beyond that, I have no clue what I was supposed to do with it; I made the file executable and attempted to run it, but nothing happened -- again, this was before I had any of the Qt stuff installed, so maybe that's why it didn't work? :shrug: anyway, yes, I'll download another one and try it, if you think it'll help. Where do I find the 64 bit Linux nightly build file? (and, optionally, what exactly am I expected to do with the file once downloaded?)
I'll record a new screencast and attach it to this ticket.
I have two screencasts to show you, as the first crash recorded was significantly different that what I "typically" see. The second one shows the typical "lockup" crash that I see. (as an aside, I was able to enter 2 notes without a problem, but the program locked up when i hit "E" to enter the third note; usually it locks up upon entering the first note)
1) mscore_crash.zip
2) mscore_lockup.zip
Great you have made two screencasts briand. We should all use this more. But to make it even more easy, try using http://screenr.com This way we don't have to hassle with uploading screencasts, downloading them, unzipping etc. Instead, it's just a link. Easy.
Alternatively, there is Screencast-O-Matic .
okay... thanks for the links, but I'll stick with the option built into my operating system that doesn't require a connection to the internet. meanwhile, this is a bug tracker, not a forum for discussing the merits of various screencast mechanisms.
Could you give the exact steps for the second crash? (Which keys did you press for the first notes? Does this sequence of notes consistently crash at the same place?)
Have you tried Revert to factory settings ?
Works OK on my Linux Box
R5471 downloaded from Linux Nightlies running Mint 11 Katya on 32 bit AMD processor
This begs the question - could it be a 64 bit Linux issue?
David --
Once the new score appears on the screen, the keys pressed are:
crash 1) 'C'
crash 2) 'C' 'D' 'E' (although, usually it crashes on the 'C', but in the same manner)
Yes, I have tried reverting to factory settings -- no change.
no update on this in two weeks?
still crashing.
more clues, from the video: questions that might be asked -- should note entry on a tablature staff be placing some symbol a dozen ledger lines above the staff? (hint: there are no ledger lines in TAB notation) in other words, there might be something larger amiss, behind the scenes in 64bit linux builds. as an aside, where I note above that note entry on a 'regular' staff works fine, i should point out that the first note I enter on a score ('C', entered by typing the 'C' on my computer keyboard) also shows up several ledger lines above the top of whatever staff I'm using.
Since nobody can reproduce the crash, (I just tried on windows with ) let's try to see why it happens on your computer.
What's your version of Qt ?
It could be linked with the sound. Can you make a screen capture of Preferences -> I/O ? Can you try to reproduce by running
mscore -s?I can reproduce the issue running with "mscore -s". The terminal output, crashing, etc are identical to what is seen in the video screencast. There is, however, no sound emitted at the time of the crash, when using the "-s" parameter; occasionally, previous crashes would emit a note (presumably a C, but I don't have perfect pitch, so I can't be sure) at the time of note entry, before the program has finished crashing.
I have no issues with sound recording or sound reproduction on this machine. A screen capture of the Preferences->I/O dialog is attached, per your request.
Qt version here is the latest available in the linux mint (ubuntu) repositories. (Version: 4:4.7.4-0ubuntu8.1)
I hear you (and everybody else) saying that you are unable to recreate the issue. Again, I reiterate that I am running on a 64-bit Linux system, and again ask if anybody running *that* architecture has tried and failed to reproduce this issue.
Here is the log contributed by briand on IRC : http://pastebin.com/kZGhXPQf
Has anyone else with a 64bit Linux system tried to reproduce this?
Changed subject as my 32bit Linux system will not reproduce this - see #21 above for details.
i am working on a 64bit linux (kubuntu) system and cannot reproduce this
In that case should we close this?????
Hi briand
Are you still having problems?
I still can't reproduce. briand's log from #26 was mentioning a lot of errors with X11. Maybe this is solved with the move to Qt5? Briand?
As there has been no response, I close this.
Please open another issue if there is still problems.