#24 Fade {Intro,Leadout} loop infinitely

reproducible
closed
9
2013-11-13
2006-12-28
No

Fade Intro and Fade Leadout often loop infinitely. If I try to quit kwave meanwhile, I get TopWidget::closeFile() - currently not possible, a plugin is running :-(

I can reproduce this on 2 Etch boxes on various wav files, at least half of the time. I have tried to reproduce lots of time, but haven't been able to determine a condition that allows reproducing everytime. I suggest you try reproducing about 10 times before concluding that you can't reproduce.

For example, $ kwave foo.wav
Ctrl+Shift+O
Alt+F4

should output if it works at the first try:

$ kwave ahdn_trim.wav

This is Kwave 0.7.7 (using KDE 3.5.5)
Benchmarking memcpy methods (smaller is better):
libc memcpy() : 467461819
linux kernel memcpy() : 468470527
MMX optimized memcpy() : 423963600
MMXEXT optimized memcpy() : 269640608
using -> 'MMXEXT optimized memcpy()'

   newsignal   2.0 written by Thomas Eschenbacher

codec_audiofile 2.0 written by Thomas Eschenbacher
fileinfo 2.0 written by Thomas Eschenbacher
record 2.0 written by Thomas Eschenbacher
playback 2.0 written by Thomas Eschenbacher
decoder_mp3 2.0 written by Thomas Eschenbacher
MCOP StartupManager: adding a StartupClass after Dispatcher init will not work.
pitch_shift 2.0 written by Thomas Eschenbacher
notch_filter 2.0 written by Dave Flogeras
noise 2.0 written by Thomas Eschenbacher
amplifyfree 2.0 written by Thomas Eschenbacher
codec_wav 2.0 written by Thomas Eschenbacher
zero 2.0 written by Thomas Eschenbacher
codec_flac 2.0 written by Thomas Eschenbacher
memory 2.0 written by Thomas Eschenbacher
lowpass 2.0 written by Thomas Eschenbacher
codec_ogg 2.0 written by Thomas Eschenbacher
sonagram 2.0 written by Thomas Eschenbacher
selectrange 2.0 written by Thomas Eschenbacher
volume 2.0 written by Thomas Eschenbacher
about 2.0 written by Ralf Waspe & Gilles Caulier


found 20 plugins

SignalManager::loadFile(file:///home/chealer/Desktop/ahdn_trim.wav) - [audio/x-wav]
RIFFParser::parse(offset=0x00000000, length=0x001AEB0C)
new chunk, name='RIFF', len=0x001AEB04, ofs=0x00000000, phys_len=0x001AEB04 (next=0x001AEB0C)
parse loop end: offset=0x001AEB0C, length=0x00000000
scanning for chunks in '/RIFF' (format='WAVE'), offset=0x0000000C, length=0x001AEB00
RIFFParser::parse(offset=0x0000000C, length=0x001AEB00)
new chunk, name='fmt ', len=0x00000010, ofs=0x0000000C, phys_len=0x00000010 (next=0x00000024)
parse loop end: offset=0x00000024, length=0x001AEAE8
RIFFParser::parse(offset=0x00000024, length=0x001AEAE8)
new chunk, name='data', len=0x001AEAA0, ofs=0x00000024, phys_len=0x001AEAA0 (next=0x001AEACC)
parse loop end: offset=0x001AEACC, length=0x00000040
RIFFParser::parse(offset=0x001AEACC, length=0x00000040)
new chunk, name='LIST', len=0x00000038, ofs=0x001AEACC, phys_len=0x00000038 (next=0x001AEB0C)
parse loop end: offset=0x001AEB0C, length=0x00000000
scanning for chunks in '/RIFF/LIST' (format='INFO'), offset=0x001AEAD8, length=0x00000034
RIFFParser::parse(offset=0x001AEAD8, length=0x00000034)
new chunk, name='ICRD', len=0x0000000A, ofs=0x001AEAD8, phys_len=0x0000000A (next=0x001AEAEA)
parse loop end: offset=0x001AEAEA, length=0x00000022
RIFFParser::parse(offset=0x001AEAEA, length=0x00000022)
new chunk, name='ISFT', len=0x0000001A, ofs=0x001AEAEA, phys_len=0x0000001A (next=0x001AEB0C)
parse loop end: offset=0x001AEB0C, length=0x00000000
--- RIFF file structure after first pass ---
[0x00000000-0x001AEB0B] ( 1764108/ 1764108) ROOT, ''
[0x00000000-0x001AEB0B] ( 1764100/ 1764100) MAIN, '/RIFF (WAVE)'
[0x0000000C-0x00000023] ( 16/ 16) SUB, '/RIFF/fmt '
[0x00000024-0x001AEACB] ( 1764000/ 1764000) SUB, '/RIFF/data'
[0x001AEACC-0x001AEB0B] ( 56/ 56) MAIN, '/RIFF/LIST (INFO)'
[0x001AEAD8-0x001AEAE9] ( 10/ 10) SUB, '/RIFF/LIST/ICRD'
[0x001AEAEA-0x001AEB0B] ( 26/ 26) SUB, '/RIFF/LIST/ISFT'
fmt chunk starts at 0x00000014
data chunk at 0x0000002C (1764000 byte)
-------------------------
wav header:
mode = 0x0001, ( Microsoft PCM format )
channels = 2
rate = 44100
bytes/s = 176400
block align = 4
bits/sample = 16
-------------------------
Track::appendStripe(441000)
Track::appendStripe(441000)
--- dump of file info ---
default properties:
length = 441000 samples
rate = 44100.0 Hz
bits = 16
tracks = 2
other properties:
'Compression' = '0'
'Date' = '2006-12-27'
'Filename' = '/home/chealer/Desktop/ahdn_trim.wav'
'File Size' = '1764108'
'Mime Type' = 'audio/x-wav'
'Sample Format' = '401'
'Software' = 'Kwave-0.7.7 pour KDE 3.5.5'
-------------------------
--- dump of file info ---
default properties:
length = 441000 samples
rate = 44100.0 Hz
bits = 16
tracks = 2
other properties:
'Compression' = '0'
'Date' = '2006-12-27'
'Filename' = '/home/chealer/Desktop/ahdn_trim.wav'
'File Size' = '1764108'
'Mime Type' = 'audio/x-wav'
'Sample Format' = '401'
'Software' = 'Kwave-0.7.7 pour KDE 3.5.5'
-------------------------
chealer@localhost:~/Desktop$ --- InterpolationMap::fill() ---
TopWidget::closeFile() - currently not possible, a plugin is running :-(

chealer@localhost:~/Desktop$

Discussion

  • Logged In: YES
    user_id=37622
    Originator: NO

    Thanks for the report, it is reproducible here too. I will take a look on it...

     
  • Logged In: YES
    user_id=37622
    Originator: NO

    After some analysis I found out that the situation is even worse.

    The mt/ThreadsafeX11Guard class produces a deadlock when it calls qApp->lock(). Apparently qApp->lock() itself produces a deadlock, even when called in a proper environment. Seems to be some brain-dead change of behaviour in Qt...

    Turning back the complete "mt" directory to svn revision 1428 makes things working again.

    I increased the priority of this bug to maximum as it also affects a lot of other important base functionality. I will delay the release of v0.7.8 until after this has been fixed...

     
  • Logged In: YES
    user_id=37622
    Originator: NO

    should work now, since v0.7.8

     
  • Logged In: YES
    user_id=738765
    Originator: YES

    And thanks for the fix, Thomas. Plus the release :)

    I noticed that you increased the severity of this bug to highest, which makes me wonder if I understand the reason well. My distributor is close to a release and contains for now an unpatched 0.7.7. Supposing that it wouldn't be possible to get a kwave version with this bug fixed in a distribution, should the distributor avoid shipping an unpatched Kwave 0.7.7, or is 0.7.7 better than nothing? IOW, does this bug only causes CPU load and Kwave freezes, or is it also a security risk or a bug that could harm other applications?

     
  • Logged In: YES
    user_id=37622
    Originator: NO

    It will cause "only" CPU load / Kwave freezes and should not affect any other applications. Therefore I consider it to be a "show stopper" which has to be fixed before releasing. The severity of this bug report system currently does not correspond to any other scheme of severity levels, so if you think that it would make sense to refer to an existing numbering / rating scheme -> give me a hint ;-)