Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#108 Eraser tool causes MusE to crash

0.7.x
closed-fixed
nobody
None
5
2006-01-17
2005-06-19
plixplox
No

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.

Discussion

  • plixplox
    plixplox
    2005-06-19

    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.

     
  • 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)?

     
  • plixplox
    plixplox
    2005-06-20

    Log file

     
    Attachments
  • plixplox
    plixplox
    2005-06-20

    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 ....

     
  • 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').

     
  • plixplox
    plixplox
    2005-06-22

    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.

     
  • plixplox
    plixplox
    2005-06-22

    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

     
  • plixplox
    plixplox
    2005-06-22

    MusE log file

     
    Attachments
  • plixplox
    plixplox
    2005-06-22

    Logged In: YES
    user_id=1276044

    Now I will try to upload the strace log file being bzipped, whose
    original file size is 10 MB ...

     
  • plixplox
    plixplox
    2005-06-22

     
  • Logged In: YES
    user_id=896178

    Interesting about the configure-options. That about
    --enable-optimize disabling debug, I'm not really sure
    that's true. But using --enable-optimize is a sure way to
    have strange things popping up (compiler bugs + code bugs
    only showing up under certain circumstances). It sounds bad
    that there's something segfaulting during the build-process
    if you're not using --enable-optimize, like there's a
    problem with the build environment. Do you remember what is
    causing the segfault when building without optimize?

     
  • plixplox
    plixplox
    2005-06-23

    Logged In: YES
    user_id=1276044

    I tried to reproduce the "Speicherzugriffsfehler" today that I
    noticed yesterday when I tried to build MusE 0.7.2.pre1 with the
    --enable-debug, but without the --enable-optimize switch, but this
    time the build did not result in an error, after the make command
    was done, the command "echo $?" , showed a "0" ...

     
  • Robert Jonsson
    Robert Jonsson
    2005-07-29

    Logged In: YES
    user_id=81832

    Sorry no fixes but I am atleast able to reproduce this error. I've traced deep
    down into the void, sofar I have not found a way to circumvent it.
    It may indeed be a QT bug.
    My qt version is 3.3.4

     
  • mArukqs
    mArukqs
    2005-11-29

    Logged In: YES
    user_id=1303419

    The same is on my Fedora Core 3 from Planet CCRMA.

    System is Athlon 3000+, 1GB RAM. I have tested it with a few
    2.6 kernels with and without realtime patches. My system is
    not german so when I try to erase the LAST note (the note
    which is the right most) with eraser tool in terminal I get
    message "Segfault"

    It was tried both with and without Realtime option turned on
    in jackd too.

    The problem was first reproduced on 0.7.1

    To solve this problem I tried to upgrade to muse 0.7.2.pre3.
    Then I tried to compile with and without optimizations. Then
    I tried to upgrade qt to qt-3.3.4-14_6 and recompile again.
    But the problem is still here.

    Tried to upgrade from jack 0.99 to jack 0.100 - the problem
    still remains.

    It is still possible to delete the notes in Pianoroll by
    selecting a note and hitting a Del key or from a menu
    Edit/Delete Events. If you get too entusiastic in writing a
    song and try to delete THE LAST NOTE IN A SEGMENT with an
    eraser tool - muse crashes.

    It is very annoying.

     
  • Logged In: YES
    user_id=896178

    Werner has made a fix that is related to this - seems like
    there was a race condition between the sequencer and the gui
    to me. Would be very interesting to hear if the problems are
    still around.

     
  • Robert Jonsson
    Robert Jonsson
    2005-12-28

    Logged In: YES
    user_id=81832

    Fixed unless someone says differently

     
  • Robert Jonsson
    Robert Jonsson
    2005-12-28

    • status: open --> pending-fixed
     
  • Logged In: YES
    user_id=1312539

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
    • status: pending-fixed --> closed-fixed