On Tue, Mar 12, 2013 at 2:03 PM, Douglas Regehr <[email protected]>wrote:
> > [snip] > This was from attempting to load the crashed session later. I attached > gdb before attempting to load the session. Then, when the progress bar in > non-daw reached 78% gdb caught a SIGABRT and I did the backtrace. > I'm sure you won't be surprised to hear that I am unable to reproduce the problem. Your session loads fine and I attempted to perform a similar task, placing 100s of overlapping regions on a track, dragging them around, selecting 100s of them and dragging the selection around etc. No problems. However, in searching for the problem I did find and fix a few issues. The only one I can imagine being related had to do with multi-region selection resulting in a leakage of timers, which might have been the thing using up your CPU after a while. Do you recall if the disk buffer meters showed an underrun at the time? Anyway, you should pull the new code. Also, in the future, you might be able to get a better trace when it happens by adding a little button to you WM panel that invokes the following command: xterm -e gdb `which non-daw` `pidof non-daw` That way, even if the system is running slow, you should be able to click on that, interrupt the process and get a backtrace of what it's up to.
