[ardour-dev] 2 bugs w/ latest nightly

[Paul Winkler]

Howdy folks, can't seem to join mantis currently, so I don't
know if either of these issues are known...
2 bugs, one a segfault, the other a barely-reproducible
weirdness with swh's sc1 plugin.

version info:
Ardour/GTK 0.454.0 running with libardour 0.729.0

I built with enable-optimize so I'm not sure if I can get
any more info from the segfault.
I've uploaded to my server a 16 MB tarball of a session that 
reliably segfaults for me *when looping play is enabled*.  
Playback starts at the loop start and segfaults 
when it reaches the end. If the loop end is a bit later, 
no segfault.  Here's the output:

--------------------------------------------
jackd 0.94.0
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

loading driver ..
apparent rate = 48000
creating alsa driver ... Delta66|Delta66|1024|3|48000|0|0|nomon|swmeter|rt|32bit
configuring for 48000Hz, period = 1024 frames, buffer = 3 periods
Ardour/GTK 0.454.0 running with libardour 0.729.0
Loading UI configuration file /usr/local/etc/ardour/ardour_ui.rc
Loading system configuration file /usr/local/etc/ardour/ardour_system.rc
Loading user configuration file /home/pw/.ardour/ardour.rc
MIDI: MTC on port trident MMC on port trident
ardour: [ERROR]: KeyboardTarget: unknown action "set-mouse-mode-pan"
ardour: [ERROR]: KeyboardTarget: unknown action "set-mouse-mode-automation"
Loading session /home/pw/tape1/buggy/ using snapshot buggy
transport starts with TF = 3793920
/home/pw/sh/ardour.sh: line 9: 21281 Segmentation fault      sudo ardour
jack main caught signal 15
subgraph starting at ardour timed out (subgraph_wait_fd=11, status = 0, state = Running)
client ardour error: awake_at = 31058459144 state = 2 timed_out = 2
---------------------------------


If anyone wants a crack at this session it's here:
http://www.slinkp.com/~paul/buggy-session.tgz

The second bug is reproducible with the same session.
If I add sc1 to the "audio 2" track and turn it on,
the output of the plugin goes silent somewhere
in the looped section.  (If I play from the
beginning without looping, the same thing happens
when playback reaches approximately the middle of that area.)

I've been trying to reproduce either of these problems
with a much smaller session containing only an export
of the evil region in question. No luck so far :-(
But it's 100% repeatable when I use the whole soundfile.
Why always in the same place?? If it's triggered by the
audio data, why doesn't it happen when using a new file
extracted from that part of the original?
(I used ecasound for that, and used sndfile-info to
verify that I preserved the same format exactly).

I have been unable to spot anything unusual about the audio
data... it's pretty quiet but that's it.

-- 

Paul Winkler
http://www.slinkp.com