[Lmuse-developer] [ lmuse-Bugs-1223607 ] Eraser tool causes MusE to crash

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1223607, was opened at 2005-06-19 16:27
Message generated for change (Comment added) made by plixplox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=604222&aid=1223607&group_id=93414

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 0.7.x
Status: Open
Resolution: None
Priority: 5
Submitted By: plixplox (plixplox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Eraser tool causes MusE to crash

Initial Comment:
When you use the eraser tool in the piano roll editor or in  
the drum track editor while playing a part of a song looped  
(here: only one bar played looped, 4/4th time based), MuSe  
0.7.2.pre1 crashes:  

When you try to erase a note while the cursor reaches the  
same position of the note that you want to erase, MusE  
crashes.   

I noticed this behaviour in MusE 0.7.1, too.   

I have attaced a log file, covering a crash. The last line of  
the log file says: "Speicherzugriffsfehler", which means   
"memory access error", and this is the last log entry when I  
caused a MusE crash using the eraser tool.   

From the communication via the MusE mailing list it appears 
that QT is the source for this behaviour. I am using qt, 
version 3.3.3.  

My system is a "Linux from scratch" (version 6.0) / "Beyond 
Linux from Scratch" (version 6.0) installation. For 99% I kept 
to the installation instructions of both LFS and BLFS. These 
installation instructions, including the configure flags for the 
individual software packages, and their version numbers, 
can be viewed at the folllowing addresses: 

LFS: http://www.lfs-matrix.de/lfs/view/6.0/ 
BLFS: http://www.lfs-matrix.de/blfs/view/stable/ 

Note that an LFS and BLFS installation does not completely 
cover the creation of a system that can be "fully" used to do 
sound editing and sound creation. That is why I have 
installed several additional software packages "on top" of 
my LFS/BLFS installation, and I am not finished with these 
extra installations yet. 

----------------------------------------------------------------------

>Comment By: plixplox (plixplox)
Date: 2005-06-22 22:13

Message:
Logged In: YES 
user_id=1276044

Sorry, I cannot do an upload two these two files (maximum size 
reached) being packed in an tar archive. I try to upload them 
individually, the strace log file compressed with bzip2 ... 

First I will try to upload the muse_muse.log 

----------------------------------------------------------------------

Comment By: plixplox (plixplox)
Date: 2005-06-22 22:04

Message:
Logged In: YES 
user_id=1276044

Hi, I have applied the following command:  

strace -fitv -o muse_strace.log /opt/muse/bin/muse -dDmMs >  
muse_muse.log 2>&1  

This command created two log files:  

a) muse_strace.log:   

This log file hopefully covers enough information about the  
behaviour, seen from a perspective outside of MusE.  

b) muse_muse.log:   

This log file was created with the MusE-inherent debug switches  
-dDmMs. The MusE compilation to which I applied the  
above-mentioned command, was built using the --enable-debug  
switch, but also the --enable-optimize switch.*  

Both log files are packed into the file muse_log_files.tar.gz, which  
is attached to this bug report.  

---------------------  
* The --enable-debug switch "disables optimizations"  
(this is a quote from the MusE configure-script), so this switch  
should somehow neutralize the --enable-optimize switch (?!). But I  
had to apply both --enable-debug and --enable-optimize, because  
without the --enable-optimize switch MusE fails to build, by the  
way resulting in a "Speicherzugriffsfehler", if this is of any  
interest.  

----------------------------------------------------------------------

Comment By: Mathias Lundgren (lunar_shuttle)
Date: 2005-06-21 19:20

Message:
Logged In: YES 
user_id=896178

Sorry, muse's own debug-logs are unfortunately not helping
in cases like these. The "Speicherzugriffsfehler"
(segmentation fault) is written to stderr by the operating
system, that's why it doesn't show up, btw. I'd be happy if
you could run a debug-built muse in gdb (./configure
--enable-debug, I think, but I almost suspect it's built
with -g anyway, so it might work on an ordinary muse built
from source), and do a backtrace when it crashes ('bt').

----------------------------------------------------------------------

Comment By: plixplox (plixplox)
Date: 2005-06-20 20:47

Message:
Logged In: YES 
user_id=1276044

The log file is uploaded now ("File Upload: Successful").
Please note that the memory access error
("Speicherzugriffsfehler") is not logged into the log file;
the memory access error only gets reported within the
console, although I used the command " muse -DmMs > muse.log
2>&1". And I ask myself if this log file is useful enough ....

----------------------------------------------------------------------

Comment By: Mathias Lundgren (lunar_shuttle)
Date: 2005-06-20 19:05

Message:
Logged In: YES 
user_id=896178

Hmmm, SF:s interface is messy sometimes, and I'm not always
good at finding things, but I can't find that attachment.
The page says "Number of Attachments: 0" as well. Could you
give it another try (or am I blind)?

----------------------------------------------------------------------

Comment By: plixplox (plixplox)
Date: 2005-06-19 16:33

Message:
Logged In: YES 
user_id=1276044

PS: The kernel version that I currently use is 2.6. 11.7, including 
the realtime-modules, version 0.1.1. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=604222&aid=1223607&group_id=93414