Unable to load session

[Douglas Regehr]

Hi, I'm trying to load a session in non-session-manager that used to load
just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
backtrace:

#0 0x00007f1b0d78483d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at ../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0 "/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at ../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290

Here's my interpretation: It seems that the Track destructor is getting
called twice on the same object. The second time it tries to delete the
underlying disk stream there is no thread to destroy, and so it continues
waiting for the thread to terminate forever. I have no idea why the Track
destructor is getting called twice for the same object.

I have problems loading sessions a couple times a week on average, though
this is the first time I've ever bothered to attach gdb and get a trace.
Usually what I do is revert to a backup (I use a cron job to nightly backup
my sessions to an external drive) or open up the history file with a text
editor and delete lines from the bottom of the file until the session
finally loads. Today I found a new way to work-around the problem: "cp
snapshot history" -- not an ideal solution in the least, but the best I
could do for now. In general I find loading sessions to be unreliable. I
feel I have no way to guarantee a session will open again after I've done
some work on it. It is quite scary. Problems seem to occur mostly when I
am adding/removing a lot of tracks and/or takes in short succession.

Note I'm using the latest code from git...

One more thing: As part of my nightly backup I run a script to replace all
the symlinks in the sources directory with copies of the actual files. I
can't imagine this would cause non-daw to have trouble loading sessions,
but I'm mentioning it just in case. There is a script included in non-daw
called import-external-sources but I do not think it works anymore, so I
have written my own...

Regards,

Doug

[J. Liles]

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used to load
just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at ../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at ../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is getting
called twice on the same object. The second time it tries to delete the
underlying disk stream there is no thread to destroy, and so it continues
waiting for the thread to terminate forever. I have no idea why the Track
destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average, though
this is the first time I've ever bothered to attach gdb and get a trace.
Usually what I do is revert to a backup (I use a cron job to nightly backup
my sessions to an external drive) or open up the history file with a text
editor and delete lines from the bottom of the file until the session
finally loads. Today I found a new way to work-around the problem: "cp
snapshot history" -- not an ideal solution in the least, but the best I
could do for now. In general I find loading sessions to be unreliable. I
feel I have no way to guarantee a session will open again after I've done
some work on it. It is quite scary. Problems seem to occur mostly when I
am adding/removing a lot of tracks and/or takes in short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to replace all
the symlinks in the sources directory with copies of the actual files. I
can't imagine this would cause non-daw to have trouble loading sessions,
but I'm mentioning it just in case. There is a script included in non-daw
called import-external-sources but I do not think it works anymore, so I
have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.

Converting the files from symlinks to files shouldn't make any difference.
I am curious why you have so many external sources and why you need them
copied in, though.

If import-external-sources doesn't work, then why didn't you just fix it?
Are you planning to share the script you have written so that the rest of
us can benefit?

I think this may be related to another bug I'm working on fixing, but it's
hard to say without being able to reproduce it.

[Douglas Regehr]

Post by J. Liles

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used to load
just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at ../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is getting
called twice on the same object. The second time it tries to delete the
underlying disk stream there is no thread to destroy, and so it continues
waiting for the thread to terminate forever. I have no idea why the Track
destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average, though
this is the first time I've ever bothered to attach gdb and get a trace.
Usually what I do is revert to a backup (I use a cron job to nightly backup
my sessions to an external drive) or open up the history file with a text
editor and delete lines from the bottom of the file until the session
finally loads. Today I found a new way to work-around the problem: "cp
snapshot history" -- not an ideal solution in the least, but the best I
could do for now. In general I find loading sessions to be unreliable. I
feel I have no way to guarantee a session will open again after I've done
some work on it. It is quite scary. Problems seem to occur mostly when I
am adding/removing a lot of tracks and/or takes in short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to replace
all the symlinks in the sources directory with copies of the actual files.
I can't imagine this would cause non-daw to have trouble loading sessions,
but I'm mentioning it just in case. There is a script included in non-daw
called import-external-sources but I do not think it works anymore, so I
have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the bottom

of the file. This is just like undo-ing a bunch of stuff, right? I've
attached it to this message...

Post by J. Liles
Converting the files from symlinks to files shouldn't make any difference.
I am curious why you have so many external sources and why you need them
copied in, though.
I work with other musicians long-distance. They send me .wav or .mid

files of their performances which I need to add to my mix. (For .mid files
I usually use jack render to convert them to .wav files and then import
them in.) I like stuff copied in so I can back it up easily -- all I have
to do is back up the NSM Sessions directory. Also, I have two computers
running non-daw. Copying stuff in makes it way easier to sync between the
two machines.

Post by J. Liles
If import-external-sources doesn't work, then why didn't you just fix it?
Are you planning to share the script you have written so that the rest of
us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a copy.
See attachment. I run it like this:

find ~/NSM\ Sessions -type l -print0 | xargs -0 unln

Is import-external-sources still supposed to work? It doesn't seem to be
looking for symbolic links at all...has non-daw always used symlinks for
external sources? I thought that was a recent change...

I think this may be related to another bug I'm working on fixing, but it's

Post by J. Liles
hard to say without being able to reproduce it.

[J. Liles]

Post by Douglas Regehr

Post by J. Liles

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used to
load just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at ../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at ../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is getting
called twice on the same object. The second time it tries to delete the
underlying disk stream there is no thread to destroy, and so it continues
waiting for the thread to terminate forever. I have no idea why the Track
destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average,
though this is the first time I've ever bothered to attach gdb and get a
trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to replace
all the symlinks in the sources directory with copies of the actual files.
I can't imagine this would cause non-daw to have trouble loading sessions,
but I'm mentioning it just in case. There is a script included in non-daw
called import-external-sources but I do not think it works anymore, so I
have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the bottom

of the file. This is just like undo-ing a bunch of stuff, right? I've
attached it to this message...

Post by J. Liles
Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or .mid

files of their performances which I need to add to my mix. (For .mid files
I usually use jack render to convert them to .wav files and then import
them in.) I like stuff copied in so I can back it up easily -- all I have
to do is back up the NSM Sessions directory. Also, I have two computers
running non-daw. Copying stuff in makes it way easier to sync between the
two machines.

Post by J. Liles
If import-external-sources doesn't work, then why didn't you just fix it?
Are you planning to share the script you have written so that the rest of
us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem to be
looking for symbolic links at all...has non-daw always used symlinks for
external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing, but it's

Post by J. Liles
hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session loads
fine 100% of the time.
2. Perhaps the error is in your 'snapshot' file and not the 'history' file?
Can I have a copy of 'snapshot' too?
3. In the meantime, I have some lock ordering fixes (maybe) on the lockfix
branch in git (tuxfamily). Can you build that and tell me if it makes any
difference?

[Douglas Regehr]

Post by J. Liles

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used to
load just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is getting
called twice on the same object. The second time it tries to delete the
underlying disk stream there is no thread to destroy, and so it continues
waiting for the thread to terminate forever. I have no idea why the Track
destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average,
though this is the first time I've ever bothered to attach gdb and get a
trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to replace
all the symlinks in the sources directory with copies of the actual files.
I can't imagine this would cause non-daw to have trouble loading sessions,
but I'm mentioning it just in case. There is a script included in non-daw
called import-external-sources but I do not think it works anymore, so I
have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the bottom

of the file. This is just like undo-ing a bunch of stuff, right? I've
attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or .mid

files of their performances which I need to add to my mix. (For .mid files
I usually use jack render to convert them to .wav files and then import
them in.) I like stuff copied in so I can back it up easily -- all I have
to do is back up the NSM Sessions directory. Also, I have two computers
running non-daw. Copying stuff in makes it way easier to sync between the
two machines.

If import-external-sources doesn't work, then why didn't you just fix
it? Are you planning to share the script you have written so that the rest
of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem to be
looking for symbolic links at all...has non-daw always used symlinks for
external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing, but

it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session loads
fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed something up
on my end...

Post by J. Liles
2. Perhaps the error is in your 'snapshot' file and not the 'history'
file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one has
been created since I encountered this problem. However, I doubt there was
a problem with the snapshot file, because I was able to get my session to
load by doing "cp snapshot history", and everything has worked wonderfully
since then...

Post by J. Liles
3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

[Douglas Regehr]

I encountered this problem again. Non-daw gets stuck at 90% while trying
to load my session. I tried building and installing the lockfix branch,
but this didn't make any difference. I'm attaching my history and snapshot
files, though I don't think the snapshot file is being read because it is
older than the history file. I was able to work around the problem by
deleting the last three lines of the history file, which look like this:

Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset 499660 <<
:length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain 9.931859
:fade-in-type 1 :fade-in-duration 256 :fade-out-type 1 :fade-out-duration
256 :color 248 :length 1810380 :start 10723020 :sequence 0x1E7C :selected 0
:offset 499660 :loop 0

I think this is pretty typical -- I tend to see the problem when I delete a
take, or delete a lot of takes in a short period of time. Today I was
recording some vocal takes and since I'm a fairly crappy singer I had to do
several takes and ended up deleting one of them because it was unusually
heinous. I got a backtrace from gdb showing what is happening when non-daw
is trying to load my session, but it is the same as the one I previously
sent so I won't bother sending it again...

Is there any other information that would be useful?

Post by Douglas Regehr

Post by J. Liles

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used to
load just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average,
though this is the first time I've ever bothered to attach gdb and get a
trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to replace
all the symlinks in the sources directory with copies of the actual files.
I can't imagine this would cause non-daw to have trouble loading sessions,
but I'm mentioning it just in case. There is a script included in non-daw
called import-external-sources but I do not think it works anymore, so I
have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the

bottom of the file. This is just like undo-ing a bunch of stuff, right?
I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or .mid

files of their performances which I need to add to my mix. (For .mid files
I usually use jack render to convert them to .wav files and then import
them in.) I like stuff copied in so I can back it up easily -- all I have
to do is back up the NSM Sessions directory. Also, I have two computers
running non-daw. Copying stuff in makes it way easier to sync between the
two machines.

If import-external-sources doesn't work, then why didn't you just fix
it? Are you planning to share the script you have written so that the rest
of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem to
be looking for symbolic links at all...has non-daw always used symlinks for
external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing, but

it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session loads
fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed something up
on my end...

Post by J. Liles
2. Perhaps the error is in your 'snapshot' file and not the 'history'
file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one has
been created since I encountered this problem. However, I doubt there was
a problem with the snapshot file, because I was able to get my session to
load by doing "cp snapshot history", and everything has worked wonderfully
since then...

Post by J. Liles
3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

[Douglas Regehr]

I just tried opening my modified history again and it didn't work. Though
I am now questioning my own sanity, I'm pretty certain that I was able to
open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while trying
to load my session. I tried building and installing the lockfix branch,
but this didn't make any difference. I'm attaching my history and snapshot
files, though I don't think the snapshot file is being read because it is
older than the history file. I was able to work around the problem by
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset 499660 <<
:length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain 9.931859
:fade-in-type 1 :fade-in-duration 256 :fade-out-type 1 :fade-out-duration
256 :color 248 :length 1810380 :start 10723020 :sequence 0x1E7C :selected 0
:offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I delete
a take, or delete a lot of takes in a short period of time. Today I was
recording some vocal takes and since I'm a fairly crappy singer I had to do
several takes and ended up deleting one of them because it was unusually
heinous. I got a backtrace from gdb showing what is happening when non-daw
is trying to load my session, but it is the same as the one I previously
sent so I won't bother sending it again...
Is there any other information that would be useful?

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used to
load just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average,
though this is the first time I've ever bothered to attach gdb and get a
trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the

bottom of the file. This is just like undo-ing a bunch of stuff, right?
I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or .mid

files of their performances which I need to add to my mix. (For .mid files
I usually use jack render to convert them to .wav files and then import
them in.) I like stuff copied in so I can back it up easily -- all I have
to do is back up the NSM Sessions directory. Also, I have two computers
running non-daw. Copying stuff in makes it way easier to sync between the
two machines.

If import-external-sources doesn't work, then why didn't you just fix
it? Are you planning to share the script you have written so that the rest
of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem to
be looking for symbolic links at all...has non-daw always used symlinks for
external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing, but

it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session loads
fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed something
up on my end...

2. Perhaps the error is in your 'snapshot' file and not the 'history'
file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one has
been created since I encountered this problem. However, I doubt there was
a problem with the snapshot file, because I was able to get my session to
load by doing "cp snapshot history", and everything has worked wonderfully
since then...

3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

[J. Liles]

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work. Though
I am now questioning my own sanity, I'm pretty certain that I was able to
open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while trying
to load my session. I tried building and installing the lockfix branch,
but this didn't make any difference. I'm attaching my history and snapshot
files, though I don't think the snapshot file is being read because it is
older than the history file. I was able to work around the problem by
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset 499660 <<
:length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I delete
a take, or delete a lot of takes in a short period of time. Today I was
recording some vocal takes and since I'm a fairly crappy singer I had to do
several takes and ended up deleting one of them because it was unusually
heinous. I got a backtrace from gdb showing what is happening when non-daw
is trying to load my session, but it is the same as the one I previously
sent so I won't bother sending it again...
Is there any other information that would be useful?

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used to
load just fine a couple days ago. However, when I tried to load it today
non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS (this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at ../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average,
though this is the first time I've ever bothered to attach gdb and get a
trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the

bottom of the file. This is just like undo-ing a bunch of stuff, right?
I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or .mid

files of their performances which I need to add to my mix. (For .mid files
I usually use jack render to convert them to .wav files and then import
them in.) I like stuff copied in so I can back it up easily -- all I have
to do is back up the NSM Sessions directory. Also, I have two computers
running non-daw. Copying stuff in makes it way easier to sync between the
two machines.

If import-external-sources doesn't work, then why didn't you just fix
it? Are you planning to share the script you have written so that the rest
of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem to
be looking for symbolic links at all...has non-daw always used symlinks for
external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing, but

it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session loads
fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed something
up on my end...

2. Perhaps the error is in your 'snapshot' file and not the 'history'
file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one has
been created since I encountered this problem. However, I doubt there was
a problem with the snapshot file, because I was able to get my session to
load by doing "cp snapshot history", and everything has worked wonderfully
since then...

3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that anyway.
I believe it's a failure of a playback diskthread to shutdown. There should
be some new console output regarding that on the logfix branch (assuming
you have built for debugging.

[J. Liles]

Post by J. Liles

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset 499660
<< :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used
to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs (this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from /usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average,
though this is the first time I've ever bothered to attach gdb and get a
trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw project's
history file in the way you describe? If not, then could you send me a copy
of it (I don't need the sources) so I can try and reproduce the issue? If
you have fiddled with it, well then all bets are off as you may have
created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the

bottom of the file. This is just like undo-ing a bunch of stuff, right?
I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or

.mid files of their performances which I need to add to my mix. (For .mid
files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you just
fix it? Are you planning to share the script you have written so that the
rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem
to be looking for symbolic links at all...has non-daw always used symlinks
for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing, but

it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed something
up on my end...

2. Perhaps the error is in your 'snapshot' file and not the 'history'
file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one has
been created since I encountered this problem. However, I doubt there was
a problem with the snapshot file, because I was able to get my session to
load by doing "cp snapshot history", and everything has worked wonderfully
since then...

3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that anyway.
I believe it's a failure of a playback diskthread to shutdown. There should
be some new console output regarding that on the logfix branch (assuming
you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

[Douglas Regehr]

Post by J. Liles

Post by J. Liles

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset 499660
<< :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used
to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare crack\"
:sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0 "/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on average,
though this is the first time I've ever bothered to attach gdb and get a
trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the

bottom of the file. This is just like undo-ing a bunch of stuff, right?
I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or

.mid files of their performances which I need to add to my mix. (For .mid
files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you just
fix it? Are you planning to share the script you have written so that the
rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem
to be looking for symbolic links at all...has non-daw always used symlinks
for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing,

but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the 'history'
file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one
has been created since I encountered this problem. However, I doubt there
was a problem with the snapshot file, because I was able to get my session
to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

I've attached the console output from nsm. I think line 2103 is relevant:

[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158 shutdown():
Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

[J. Liles]

It's not a 100% fix, but try pulling again (from master this time).

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset 499660
<< :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that used
to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load (this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the

bottom of the file. This is just like undo-ing a bunch of stuff, right?
I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or

.mid files of their performances which I need to add to my mix. (For .mid
files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you just
fix it? Are you planning to share the script you have written so that the
rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't seem
to be looking for symbolic links at all...has non-daw always used symlinks
for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing,

but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one
has been created since I encountered this problem. However, I doubt there
was a problem with the snapshot file, because I was able to get my session
to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

[Douglas Regehr]

Finally got a chance to try this. Non-DAW seems to load the session (the
progress meter gets to 100%) and then promptly crash. See attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that
used to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from the

bottom of the file. This is just like undo-ing a bunch of stuff, right?
I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or

.mid files of their performances which I need to add to my mix. (For .mid
files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you just
fix it? Are you planning to share the script you have written so that the
rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink to
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't
seem to be looking for symbolic links at all...has non-daw always used
symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing,

but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one
has been created since I encountered this problem. However, I doubt there
was a problem with the snapshot file, because I was able to get my session
to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on the
lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

[Douglas Regehr]

Also, non-mixer isn't working quite right with the latest code. The
channels seem to be all stacked on top of each other, with the right-most
on top. Everything is still connected properly in jack, and playback works
fine, I just can't manipulate any of the channels except the master. See
attached screenshot and mixer snapshot file...

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session (the
progress meter gets to 100%) and then promptly crash. See attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that
used to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a
"history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from

the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or

.mid files of their performances which I need to add to my mix. (For .mid
files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you
just fix it? Are you planning to share the script you have written so that
the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't
seem to be looking for symbolic links at all...has non-daw always used
symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing,

but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one
has been created since I encountered this problem. However, I doubt there
was a problem with the snapshot file, because I was able to get my session
to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on
the lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

[J. Liles]

Post by Douglas Regehr
Also, non-mixer isn't working quite right with the latest code. The
channels seem to be all stacked on top of each other, with the right-most
on top. Everything is still connected properly in jack, and playback works
fine, I just can't manipulate any of the channels except the master. See
attached screenshot and mixer snapshot file...

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session (the
progress meter gets to 100%) and then promptly crash. See attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that
used to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a
"history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor
is getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from

the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav

or .mid files of their performances which I need to add to my mix. (For
.mid files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you
just fix it? Are you planning to share the script you have written so that
the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't
seem to be looking for symbolic links at all...has non-daw always used
symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new
one has been created since I encountered this problem. However, I doubt
there was a problem with the snapshot file, because I was able to get my
session to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on
the lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

Ah. Well, that's due to 85e22581. You can revert it--it'll just mess up the
layout of the punch/loop/new take buttons in Non-DAW.

[J. Liles]

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session (the
progress meter gets to 100%) and then promptly crash. See attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that
used to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown (this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a
"history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor is
getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from

the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav or

.mid files of their performances which I need to add to my mix. (For .mid
files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you
just fix it? Are you planning to share the script you have written so that
the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't
seem to be looking for symbolic links at all...has non-daw always used
symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on fixing,

but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new one
has been created since I encountered this problem. However, I doubt there
was a problem with the snapshot file, because I was able to get my session
to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on
the lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

Can you pull from master and try again?

[Douglas Regehr]

Post by J. Liles

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session (the
progress meter gets to 100%) and then promptly crash. See attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that
used to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a
"history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor
is getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script to
replace all the symlinks in the sources directory with copies of the actual
files. I can't imagine this would cause non-daw to have trouble loading
sessions, but I'm mentioning it just in case. There is a script included
in non-daw called import-external-sources but I do not think it works
anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from

the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav

or .mid files of their performances which I need to add to my mix. (For
.mid files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you
just fix it? Are you planning to share the script you have written so that
the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't
seem to be looking for symbolic links at all...has non-daw always used
symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The session
loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new
one has been created since I encountered this problem. However, I doubt
there was a problem with the snapshot file, because I was able to get my
session to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on
the lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!

Unfortunately, when I try to abort the session in nsm, non-daw does not
close and needs to be killed violently. Before killing it I did an strace
and got just one line:

futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL

...then I attached gdb and did a backtrace and got:

#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284

I often have problems like this when closing or aborting sessions, so I
don't know if this is related to your most recent fixes or not...

Also, when I try to scroll down in the timeline, it freezes...I've also
seen this ocassionally in other versions so I don't know if it's related to
your changes...

[J. Liles]

Post by Douglas Regehr

Post by J. Liles

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session
(the progress meter gets to 100%) and then promptly crash. See attached
log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't work.
Though I am now questioning my own sanity, I'm pretty certain that I was
able to open the modified history file once. Assuming that I'm not totally
crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90% while
trying to load my session. I tried building and installing the lockfix
branch, but this didn't make any difference. I'm attaching my history and
snapshot files, though I don't think the snapshot file is being read
because it is older than the history file. I was able to work around the
problem by deleting the last three lines of the history file, which look
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when I
delete a take, or delete a lot of takes in a short period of time. Today I
was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that
used to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a
"history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3, msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550,
timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor
is getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script
to replace all the symlinks in the sources directory with copies of the
actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from

the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make any
difference. I am curious why you have so many external sources and why you
need them copied in, though.
I work with other musicians long-distance. They send me .wav

or .mid files of their performances which I need to add to my mix. (For
.mid files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you
just fix it? Are you planning to share the script you have written so that
the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a symlink
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't
seem to be looking for symbolic links at all...has non-daw always used
symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new
one has been created since I encountered this problem. However, I doubt
there was a problem with the snapshot file, because I was able to get my
session to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on
the lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots only
create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does not
close and needs to be killed violently. Before killing it I did an strace
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions, so I
don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've also
seen this ocassionally in other versions so I don't know if it's related to
your changes...

Define 'freezes'... Does resizing the window bring it back to life?

[Douglas Regehr]

Post by J. Liles

Post by Douglas Regehr

Post by J. Liles

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session
(the progress meter gets to 100%) and then promptly crash. See attached
log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't
work. Though I am now questioning my own sanity, I'm pretty certain that I
was able to open the modified history file once. Assuming that I'm not
totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90%
while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav" :gain
9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when
I delete a take, or delete a lot of takes in a short period of time. Today
I was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager that
used to load just fine a couple days ago. However, when I tried to load it
today non-daw got stuck when it was 58% done loading my session. I tried
aborting in non-session-manager but non-daw remained open. I eventually
had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at ../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a
"history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source", client_id=0x1fb57dc
"Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550,
timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track destructor
is getting called twice on the same object. The second time it tries to
delete the underlying disk stream there is no thread to destroy, and so it
continues waiting for the thread to terminate forever. I have no idea why
the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script
to replace all the symlinks in the sources directory with copies of the
actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things from

the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make
any difference. I am curious why you have so many external sources and why
you need them copied in, though.
I work with other musicians long-distance. They send me .wav

or .mid files of their performances which I need to add to my mix. (For
.mid files I usually use jack render to convert them to .wav files and then
import them in.) I like stuff copied in so I can back it up easily -- all
I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you
just fix it? Are you planning to share the script you have written so that
the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It doesn't
seem to be looking for symbolic links at all...has non-daw always used
symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new
one has been created since I encountered this problem. However, I doubt
there was a problem with the snapshot file, because I was able to get my
session to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe) on
the lockfix branch in git (tuxfamily). Can you build that and tell me if it
makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots
only create objects (tracks with diskthreads), and never destroy them.

Disk_Stream thread has taken longer than 110ms to respond to terminate
signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does not
close and needs to be killed violently. Before killing it I did an strace
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions, so I
don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've also
seen this ocassionally in other versions so I don't know if it's related to
your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key presses.

When I try to resize, maximize or minimize the canvas does not update, and
the app stays frozen.

[J. Liles]

Post by J. Liles

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session
(the progress meter gets to 100%) and then promptly crash. See attached
log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't
work. Though I am now questioning my own sanity, I'm pretty certain that I
was able to open the modified history file once. Assuming that I'm not
totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90%
while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav"
:gain 9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem when
I delete a take, or delete a lot of takes in a short period of time. Today
I was recording some vocal takes and since I'm a fairly crappy singer I had
to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager
that used to load just fine a couple days ago. However, when I tried to
load it today non-daw got stuck when it was 58% done loading my session. I
tried aborting in non-session-manager but non-daw remained open. I
eventually had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open (filename=0x45cc4a
"history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550,
timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1, argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a script
to replace all the symlinks in the sources directory with copies of the
actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things

from the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make
any difference. I am curious why you have so many external sources and why
you need them copied in, though.
I work with other musicians long-distance. They send me

.wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't you
just fix it? Are you planning to share the script you have written so that
the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a new
one has been created since I encountered this problem. However, I doubt
there was a problem with the snapshot file, because I was able to get my
session to load by doing "cp snapshot history", and everything has worked
wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe)
on the lockfix branch in git (tuxfamily). Can you build that and tell me if
it makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like that
anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots
only create objects (tracks with diskthreads), and never destroy them.

[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does not
close and needs to be killed violently. Before killing it I did an strace
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions, so I
don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've also
seen this ocassionally in other versions so I don't know if it's related to
your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.

[Douglas Regehr]

Post by J. Liles

Post by J. Liles

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session
(the progress meter gets to 100%) and then promptly crash. See attached
log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't
work. Though I am now questioning my own sanity, I'm pretty certain that I
was able to open the modified history file once. Assuming that I'm not
totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90%
while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020 :offset
499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav"
:gain 9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem
when I delete a take, or delete a lot of takes in a short period of time.
Today I was recording some vocal takes and since I'm a fairly crappy singer
I had to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 2:00 PM, J. Liles <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager
that used to load just fine a couple days ago. However, when I tried to
load it today non-daw got stuck when it was 58% done loading my session. I
tried aborting in non-session-manager but non-daw remained open. I
eventually had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name \"snare
crack\" :sequence 0x0 :selected 0 :color 2118157429", reverse=false) at
../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open
(filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550,
timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1,
argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a
script to replace all the symlinks in the sources directory with copies of
the actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things

from the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make
any difference. I am curious why you have so many external sources and why
you need them copied in, though.
I work with other musicians long-distance. They send me

.wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't
you just fix it? Are you planning to share the script you have written so
that the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a
new one has been created since I encountered this problem. However, I
doubt there was a problem with the snapshot file, because I was able to get
my session to load by doing "cp snapshot history", and everything has
worked wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe)
on the lockfix branch in git (tuxfamily). Can you build that and tell me if
it makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like
that anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots
only create objects (tracks with diskthreads), and never destroy them.

[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does not
close and needs to be killed violently. Before killing it I did an strace
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions, so I
don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've also
seen this ocassionally in other versions so I don't know if it's related to
your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.
Transport is not rolling. I just open the session and start scrolling

around. After a short time the timeline freezes. I've attached the gdb
output...

[J. Liles]

Post by Douglas Regehr

Post by J. Liles

On Mon, Feb 25, 2013 at 2:25 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the session
(the progress meter gets to 100%) and then promptly crash. See attached
log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't
work. Though I am now questioning my own sanity, I'm pretty certain that I
was able to open the modified history file once. Assuming that I'm not
totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90%
while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020
:offset 499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav"
:gain 9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem
when I delete a take, or delete a lot of takes in a short period of time.
Today I was recording some vocal takes and since I'm a fairly crappy singer
I had to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 2:00 PM, J. Liles <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager
that used to load just fine a couple days ago. However, when I tried to
load it today non-daw got stuck when it was 58% done loading my session. I
tried aborting in non-session-manager but non-daw remained open. I
eventually had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name
\"snare crack\" :sequence 0x0 :selected 0 :color 2118157429",
reverse=false) at ../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open
(filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at /home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data () from
/usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550,
timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait (nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20)
at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1,
argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week on
average, though this is the first time I've ever bothered to attach gdb and
get a trace. Usually what I do is revert to a backup (I use a cron job to
nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a
script to replace all the symlinks in the sources directory with copies of
the actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this* non-daw
project's history file in the way you describe? If not, then could you send
me a copy of it (I don't need the sources) so I can try and reproduce the
issue? If you have fiddled with it, well then all bets are off as you may
have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things

from the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't make
any difference. I am curious why you have so many external sources and why
you need them copied in, though.
I work with other musicians long-distance. They send me

.wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't
you just fix it? Are you planning to share the script you have written so
that the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I screwed
something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a
new one has been created since I encountered this problem. However, I
doubt there was a problem with the snapshot file, because I was able to get
my session to load by doing "cp snapshot history", and everything has
worked wonderfully since then...

3. In the meantime, I have some lock ordering fixes (maybe)
on the lockfix branch in git (tuxfamily). Can you build that and tell me if
it makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like
that anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots
only create objects (tracks with diskthreads), and never destroy them.

[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does
not close and needs to be killed violently. Before killing it I did an
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions, so
I don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've
also seen this ocassionally in other versions so I don't know if it's
related to your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.
Transport is not rolling. I just open the session and start scrolling

around. After a short time the timeline freezes. I've attached the gdb
output...

How are you scrolling? This backtrace indicates that input is being
directed to one of the sequneces. Are you dragging a region around? Are you
scrolling with the panzoomer at the bottom of the timeline? Or using the
mousewheel?

[Douglas Regehr]

Post by J. Liles

Post by Douglas Regehr

Post by J. Liles

On Mon, Feb 25, 2013 at 2:25 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the
session (the progress meter gets to 100%) and then promptly crash. See
attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't
work. Though I am now questioning my own sanity, I'm pretty certain that I
was able to open the modified history file once. Assuming that I'm not
totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90%
while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020
:offset 499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav"
:gain 9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem
when I delete a take, or delete a lot of takes in a short period of time.
Today I was recording some vocal takes and since I'm a fairly crappy singer
I had to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 2:00 PM, J. Liles <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager
that used to load just fine a couple days ago. However, when I tried to
load it today non-daw got stuck when it was 58% done loading my session. I
tried aborting in non-session-manager but non-daw remained open. I
eventually had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track (this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name
\"snare crack\" :sequence 0x0 :selected 0 :color 2118157429",
reverse=false) at ../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay (fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open
(filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at
/home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data ()
from /usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait (nsm=0x1eb7550,
timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait
(nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20)
at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at ../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1,
argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week
on average, though this is the first time I've ever bothered to attach gdb
and get a trace. Usually what I do is revert to a backup (I use a cron job
to nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a
script to replace all the symlinks in the sources directory with copies of
the actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this*
non-daw project's history file in the way you describe? If not, then could
you send me a copy of it (I don't need the sources) so I can try and
reproduce the issue? If you have fiddled with it, well then all bets are
off as you may have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things

from the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't
make any difference. I am curious why you have so many external sources and
why you need them copied in, though.
I work with other musicians long-distance. They send me

.wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't
you just fix it? Are you planning to share the script you have written so
that the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I
screwed something up on my end...

2. Perhaps the error is in your 'snapshot' file and not the
'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a
new one has been created since I encountered this problem. However, I
doubt there was a problem with the snapshot file, because I was able to get
my session to load by doing "cp snapshot history", and everything has
worked wonderfully since then...

3. In the meantime, I have some lock ordering fixes
(maybe) on the lockfix branch in git (tuxfamily). Can you build that and
tell me if it makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like
that anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because snapshots
only create objects (tracks with diskthreads), and never destroy them.

I've attached the console output from nsm. I think line 2103 is
[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does
not close and needs to be killed violently. Before killing it I did an
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions, so
I don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've
also seen this ocassionally in other versions so I don't know if it's
related to your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.
Transport is not rolling. I just open the session and start scrolling

around. After a short time the timeline freezes. I've attached the gdb
output...

How are you scrolling? This backtrace indicates that input is being
directed to one of the sequneces. Are you dragging a region around? Are you
scrolling with the panzoomer at the bottom of the timeline? Or using the
mousewheel?

The mousewheel. I'm not dragging any regions or anything like that. The
session opened up with a track solo'd so I'm just scrolling down to un-solo
the track so I can hear my mix. But I've not been able to actually scroll
far enough to click the solo button...

[J. Liles]

Post by Douglas Regehr

Post by J. Liles

Post by Douglas Regehr

On Wed, Feb 27, 2013 at 1:41 PM, Douglas Regehr <

On Mon, Feb 25, 2013 at 2:25 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the
session (the progress meter gets to 100%) and then promptly crash. See
attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't
work. Though I am now questioning my own sanity, I'm pretty certain that I
was able to open the modified history file once. Assuming that I'm not
totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at 90%
while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020
:offset 499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav"
:gain 9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem
when I delete a take, or delete a lot of takes in a short period of time.
Today I was recording some vocal takes and since I'm a fairly crappy singer
I had to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

On Sat, Feb 9, 2013 at 9:25 PM, J. Liles <

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 2:00 PM, J. Liles <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in non-session-manager
that used to load just fine a couple days ago. However, when I tried to
load it today non-daw got stuck when it was 58% done loading my session. I
tried aborting in non-session-manager but non-daw remained open. I
eventually had to kill it violently from the command line. The problem is
repeatable. I attached a debugger to see what was going on and here is the
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name
\"snare crack\" :sequence 0x0 :selected 0 :color 2118157429",
reverse=false) at ../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay
(fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open
(filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open (path=0x1ebe8c0
"/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at
/home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from /usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data ()
from /usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait
(nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait
(nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait (time_to_wait=1e+20)
at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at
../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1,
argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week
on average, though this is the first time I've ever bothered to attach gdb
and get a trace. Usually what I do is revert to a backup (I use a cron job
to nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a
script to replace all the symlinks in the sources directory with copies of
the actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this*
non-daw project's history file in the way you describe? If not, then could
you send me a copy of it (I don't need the sources) so I can try and
reproduce the issue? If you have fiddled with it, well then all bets are
off as you may have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting things

from the bottom of the file. This is just like undo-ing a bunch of stuff,
right? I've attached it to this message...

Converting the files from symlinks to files shouldn't
make any difference. I am curious why you have so many external sources and
why you need them copied in, though.
I work with other musicians long-distance. They send me

.wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why didn't
you just fix it? Are you planning to share the script you have written so
that the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working on

fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I
screwed something up on my end...

2. Perhaps the error is in your 'snapshot' file and not
the 'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is, a
new one has been created since I encountered this problem. However, I
doubt there was a problem with the snapshot file, because I was able to get
my session to load by doing "cp snapshot history", and everything has
worked wonderfully since then...

3. In the meantime, I have some lock ordering fixes
(maybe) on the lockfix branch in git (tuxfamily). Can you build that and
tell me if it makes any difference?

If I see this problem again I will try building the branch...

Yes, I do think it's a race condition... well, something like
that anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because
snapshots only create objects (tracks with diskthreads), and never destroy
them.

I've attached the console output from nsm. I think line 2103 is
[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does
not close and needs to be killed violently. Before killing it I did an
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions,
so I don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've
also seen this ocassionally in other versions so I don't know if it's
related to your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.
Transport is not rolling. I just open the session and start scrolling

around. After a short time the timeline freezes. I've attached the gdb
output...

How are you scrolling? This backtrace indicates that input is being
directed to one of the sequneces. Are you dragging a region around? Are you
scrolling with the panzoomer at the bottom of the timeline? Or using the
mousewheel?

The mousewheel. I'm not dragging any regions or anything like that. The
session opened up with a track solo'd so I'm just scrolling down to un-solo
the track so I can hear my mix. But I've not been able to actually scroll
far enough to click the solo button...

Ok. Well, I'll have to look into it later. In the meantime, if you scroll
using the panzoomer, or even just use the mousewheel, but put the cursor
somewhere else (over the track headers or over the panzoomer should do) you
can work around this.

If you get that hang on close/abort again, It'd be nice to have the 'thread
apply all bt' backtrace for that.

[Douglas Regehr]

Post by J. Liles

Post by Douglas Regehr

Post by J. Liles

Post by Douglas Regehr

On Wed, Feb 27, 2013 at 1:41 PM, Douglas Regehr <

On Mon, Feb 25, 2013 at 2:25 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the
session (the progress meter gets to 100%) and then promptly crash. See
attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it didn't
work. Though I am now questioning my own sanity, I'm pretty certain that I
was able to open the modified history file once. Assuming that I'm not
totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at
90% while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020
:offset 499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source "bgv-1360857158.wav"
:gain 9.931859 :fade-in-type 1 :fade-in-duration 256 :fade-out-type 1
:fade-out-duration 256 :color 248 :length 1810380 :start 10723020 :sequence
0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the problem
when I delete a take, or delete a lot of takes in a short period of time.
Today I was recording some vocal takes and since I'm a fairly crappy singer
I had to do several takes and ended up deleting one of them because it was
unusually heinous. I got a backtrace from gdb showing what is happening
when non-daw is trying to load my session, but it is the same as the one I
previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

On Sat, Feb 9, 2013 at 9:25 PM, J. Liles <

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 2:00 PM, J. Liles <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in
non-session-manager that used to load just fine a couple days ago.
However, when I tried to load it today non-daw got stuck when it was 58%
done loading my session. I tried aborting in non-session-manager but
non-daw remained open. I eventually had to kill it violently from the
command line. The problem is repeatable. I attached a debugger to see
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name
\"snare crack\" :sequence 0x0 :selected 0 :color 2118157429",
reverse=false) at ../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay
(fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open
(filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open
(path=0x1ebe8c0 "/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at
/home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from
/usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data ()
from /usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait
(nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait
(nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait
(time_to_wait=1e+20) at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at
../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1,
argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a week
on average, though this is the first time I've ever bothered to attach gdb
and get a trace. Usually what I do is revert to a backup (I use a cron job
to nightly backup my sessions to an external drive) or open up the history
file with a text editor and delete lines from the bottom of the file until
the session finally loads. Today I found a new way to work-around the
problem: "cp snapshot history" -- not an ideal solution in the least, but
the best I could do for now. In general I find loading sessions to be
unreliable. I feel I have no way to guarantee a session will open again
after I've done some work on it. It is quite scary. Problems seem to
occur mostly when I am adding/removing a lot of tracks and/or takes in
short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a
script to replace all the symlinks in the sources directory with copies of
the actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this*
non-daw project's history file in the way you describe? If not, then could
you send me a copy of it (I don't need the sources) so I can try and
reproduce the issue? If you have fiddled with it, well then all bets are
off as you may have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting

things from the bottom of the file. This is just like undo-ing a bunch of
stuff, right? I've attached it to this message...

Converting the files from symlinks to files shouldn't
make any difference. I am curious why you have so many external sources and
why you need them copied in, though.
I work with other musicians long-distance. They send

me .wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why
didn't you just fix it? Are you planning to share the script you have
written so that the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working

on fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git. The
session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I
screwed something up on my end...

2. Perhaps the error is in your 'snapshot' file and not
the 'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is,
a new one has been created since I encountered this problem. However, I
doubt there was a problem with the snapshot file, because I was able to get
my session to load by doing "cp snapshot history", and everything has
worked wonderfully since then...

3. In the meantime, I have some lock ordering fixes
(maybe) on the lockfix branch in git (tuxfamily). Can you build that and
tell me if it makes any difference?

If I see this problem again I will try building the
branch...

Yes, I do think it's a race condition... well, something like
that anyway. I believe it's a failure of a playback diskthread to shutdown.
There should be some new console output regarding that on the logfix branch
(assuming you have built for debugging.

Oh, and it follows that snapshots always work--because
snapshots only create objects (tracks with diskthreads), and never destroy
them.

I've attached the console output from nsm. I think line 2103
[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw does
not close and needs to be killed violently. Before killing it I did an
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at ../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at ../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions,
so I don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've
also seen this ocassionally in other versions so I don't know if it's
related to your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.
Transport is not rolling. I just open the session and start scrolling

around. After a short time the timeline freezes. I've attached the gdb
output...

How are you scrolling? This backtrace indicates that input is being
directed to one of the sequneces. Are you dragging a region around? Are you
scrolling with the panzoomer at the bottom of the timeline? Or using the
mousewheel?

The mousewheel. I'm not dragging any regions or anything like that. The
session opened up with a track solo'd so I'm just scrolling down to un-solo
the track so I can hear my mix. But I've not been able to actually scroll
far enough to click the solo button...

Ok. Well, I'll have to look into it later. In the meantime, if you scroll
using the panzoomer, or even just use the mousewheel, but put the cursor
somewhere else (over the track headers or over the panzoomer should do) you
can work around this.
If you get that hang on close/abort again, It'd be nice to have the
'thread apply all bt' backtrace for that.
Here's a bt from the abort. It is quite repeatable...

[J. Liles]

Post by J. Liles

Post by Douglas Regehr

On Wed, Feb 27, 2013 at 1:54 PM, Douglas Regehr <

On Wed, Feb 27, 2013 at 1:41 PM, Douglas Regehr <

On Mon, Feb 25, 2013 at 2:25 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the
session (the progress meter gets to 100%) and then promptly crash. See
attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

Post by J. Liles

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it
didn't work. Though I am now questioning my own sanity, I'm pretty certain
that I was able to open the modified history file once. Assuming that I'm
not totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at
90% while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020
:offset 499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source
"bgv-1360857158.wav" :gain 9.931859 :fade-in-type 1 :fade-in-duration 256
:fade-out-type 1 :fade-out-duration 256 :color 248 :length 1810380 :start
10723020 :sequence 0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the
problem when I delete a take, or delete a lot of takes in a short period of
time. Today I was recording some vocal takes and since I'm a fairly crappy
singer I had to do several takes and ended up deleting one of them because
it was unusually heinous. I got a backtrace from gdb showing what is
happening when non-daw is trying to load my session, but it is the same as
the one I previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

On Sat, Feb 9, 2013 at 9:25 PM, J. Liles <

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 2:00 PM, J. Liles <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in
non-session-manager that used to load just fine a couple days ago.
However, when I tried to load it today non-daw got stuck when it was 58%
done loading my session. I tried aborting in non-session-manager but
non-daw remained open. I eventually had to kill it violently from the
command line. The problem is repeatable. I attached a debugger to see
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name
\"snare crack\" :sequence 0x0 :selected 0 :color 2118157429",
reverse=false) at ../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay
(fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open
(filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open
(path=0x1ebe8c0 "/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at
/home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from
/usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data ()
from /usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait
(nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait
(nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait
(time_to_wait=1e+20) at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at
../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1,
argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a
week on average, though this is the first time I've ever bothered to attach
gdb and get a trace. Usually what I do is revert to a backup (I use a cron
job to nightly backup my sessions to an external drive) or open up the
history file with a text editor and delete lines from the bottom of the
file until the session finally loads. Today I found a new way to
work-around the problem: "cp snapshot history" -- not an ideal solution in
the least, but the best I could do for now. In general I find loading
sessions to be unreliable. I feel I have no way to guarantee a session
will open again after I've done some work on it. It is quite scary.
Problems seem to occur mostly when I am adding/removing a lot of tracks
and/or takes in short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a
script to replace all the symlinks in the sources directory with copies of
the actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this*
non-daw project's history file in the way you describe? If not, then could
you send me a copy of it (I don't need the sources) so I can try and
reproduce the issue? If you have fiddled with it, well then all bets are
off as you may have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting

things from the bottom of the file. This is just like undo-ing a bunch of
stuff, right? I've attached it to this message...

Converting the files from symlinks to files shouldn't
make any difference. I am curious why you have so many external sources and
why you need them copied in, though.
I work with other musicians long-distance. They send

me .wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why
didn't you just fix it? Are you planning to share the script you have
written so that the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts a
find ~/NSM\ Sessions -type l -print0 | xargs -0 unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working

on fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git.
The session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I
screwed something up on my end...

2. Perhaps the error is in your 'snapshot' file and not
the 'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That is,
a new one has been created since I encountered this problem. However, I
doubt there was a problem with the snapshot file, because I was able to get
my session to load by doing "cp snapshot history", and everything has
worked wonderfully since then...

3. In the meantime, I have some lock ordering fixes
(maybe) on the lockfix branch in git (tuxfamily). Can you build that and
tell me if it makes any difference?

If I see this problem again I will try building the
branch...

Yes, I do think it's a race condition... well, something
like that anyway. I believe it's a failure of a playback diskthread to
shutdown. There should be some new console output regarding that on the
logfix branch (assuming you have built for debugging.

Oh, and it follows that snapshots always work--because
snapshots only create objects (tracks with diskthreads), and never destroy
them.

I've attached the console output from nsm. I think line 2103
[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw
does not close and needs to be killed violently. Before killing it I did
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at
../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting sessions,
so I don't know if this is related to your most recent fixes or not...
Also, when I try to scroll down in the timeline, it freezes...I've
also seen this ocassionally in other versions so I don't know if it's
related to your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.
Transport is not rolling. I just open the session and start

scrolling around. After a short time the timeline freezes. I've attached
the gdb output...

How are you scrolling? This backtrace indicates that input is being
directed to one of the sequneces. Are you dragging a region around? Are you
scrolling with the panzoomer at the bottom of the timeline? Or using the
mousewheel?

The mousewheel. I'm not dragging any regions or anything like that.
The session opened up with a track solo'd so I'm just scrolling down to
un-solo the track so I can hear my mix. But I've not been able to actually
scroll far enough to click the solo button...

Ok. Well, I'll have to look into it later. In the meantime, if you scroll
using the panzoomer, or even just use the mousewheel, but put the cursor
somewhere else (over the track headers or over the panzoomer should do) you
can work around this.
If you get that hang on close/abort again, It'd be nice to have the
'thread apply all bt' backtrace for that.
Here's a bt from the abort. It is quite repeatable...

Well, that isn't much help after all because it gives me no clue where the
lock was acquired. I still can't reproduce this, but I've pushed some
things to the 'lockfix' branch on tuxfamily. Can you confirm that it fixes
the hang on scrolling and confirm that it still hangs on close?

[Douglas Regehr]

Post by J. Liles

Post by J. Liles

Post by Douglas Regehr

On Wed, Feb 27, 2013 at 1:54 PM, Douglas Regehr <

On Wed, Feb 27, 2013 at 1:41 PM, Douglas Regehr <

On Mon, Feb 25, 2013 at 2:25 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Feb 21, 2013 at 1:09 PM, Douglas Regehr <

Post by Douglas Regehr
Finally got a chance to try this. Non-DAW seems to load the
session (the progress meter gets to 100%) and then promptly crash. See
attached log...

Post by J. Liles
It's not a 100% fix, but try pulling again (from master this time).
On Thu, Feb 14, 2013 at 1:47 PM, Douglas Regehr <

Post by Douglas Regehr

On Thu, Feb 14, 2013 at 1:09 PM, J. Liles <

On Thu, Feb 14, 2013 at 12:38 PM, Douglas Regehr <

Post by Douglas Regehr
I just tried opening my modified history again and it
didn't work. Though I am now questioning my own sanity, I'm pretty certain
that I was able to open the modified history file once. Assuming that I'm
not totally crazy...this implies some sort of race condition...
On Thu, Feb 14, 2013 at 3:10 PM, Douglas Regehr <

Post by Douglas Regehr
I encountered this problem again. Non-daw gets stuck at
90% while trying to load my session. I tried building and installing the
lockfix branch, but this didn't make any difference. I'm attaching my
history and snapshot files, though I don't think the snapshot file is being
read because it is older than the history file. I was able to work around
the problem by deleting the last three lines of the history file, which
Audio_Region 0x1E7D set :length 1810380 :start 10723020
:offset 499660 << :length 2309784 :start 10223616 :offset 256
Audio_Region 0x1E83 set :length 1114080 << :length 1506408
Audio_Region 0x1E7D destroy << :source
"bgv-1360857158.wav" :gain 9.931859 :fade-in-type 1 :fade-in-duration 256
:fade-out-type 1 :fade-out-duration 256 :color 248 :length 1810380 :start
10723020 :sequence 0x1E7C :selected 0 :offset 499660 :loop 0
I think this is pretty typical -- I tend to see the
problem when I delete a take, or delete a lot of takes in a short period of
time. Today I was recording some vocal takes and since I'm a fairly crappy
singer I had to do several takes and ended up deleting one of them because
it was unusually heinous. I got a backtrace from gdb showing what is
happening when non-daw is trying to load my session, but it is the same as
the one I previously sent so I won't bother sending it again...
Is there any other information that would be useful?
On Mon, Feb 11, 2013 at 1:18 PM, Douglas Regehr <

On Sat, Feb 9, 2013 at 9:25 PM, J. Liles <

On Thu, Jan 31, 2013 at 11:52 AM, Douglas Regehr <

On Thu, Jan 31, 2013 at 2:00 PM, J. Liles <

On Thu, Jan 31, 2013 at 10:40 AM, Douglas Regehr <

Post by Douglas Regehr
Hi, I'm trying to load a session in
non-session-manager that used to load just fine a couple days ago.
However, when I tried to load it today non-daw got stuck when it was 58%
done loading my session. I tried aborting in non-session-manager but
non-daw remained open. I eventually had to kill it violently from the
command line. The problem is repeatable. I attached a debugger to see
#0 0x00007f1b0d78483d in nanosleep () from
/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f1b0d7b2774 in usleep () from
/lib/x86_64-linux-gnu/libc.so.6
#2 0x000000000041a534 in Disk_Stream::shutdown
(this=0x213ae70)
at ../timeline/src/Engine/Disk_Stream.C:151
#3 0x000000000041a257 in Disk_Stream::~Disk_Stream
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Disk_Stream.C:78
#4 0x000000000041f5e1 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#5 0x000000000041f614 in Playback_DS::~Playback_DS
(this=0x213ae70,
__in_chrg=<optimized out>) at
../timeline/src/Engine/Playback_DS.H:22
#6 0x0000000000420e21 in Track::configure_outputs
(this=0x213bb20, n=0)
at ../timeline/src/Engine/Track.C:82
#7 0x0000000000437473 in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:119
#8 0x000000000043758e in Track::~Track
(this=0x213bb20,
__in_chrg=<optimized out>) at
../timeline/src/Track.C:127
#9 0x000000000044e02f in Loggable::do_this (
s=0x7fff7bc28af0 "Track 0x94A destroy << :name
\"snare crack\" :sequence 0x0 :selected 0 :color 2118157429",
reverse=false) at ../nonlib/Loggable.C:415
#10 0x000000000044d7f0 in Loggable::replay
(fp=0x2007ce0)
at ../nonlib/Loggable.C:215
#11 0x000000000044d54f in Loggable::open
(filename=0x45cc4a "history")
at ../nonlib/Loggable.C:138
#12 0x000000000042438d in Project::open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS")
at ../timeline/src/Project.C:317
#13 0x000000000043462a in Timeline::command_load
(this=0x1e98730,
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source") at
../timeline/src/Timeline.C:1999
#14 0x000000000042377d in command_open (
name=0x1fb57a0 "/home/oem/NSM Sessions/The
Source/Non-DAW.nAICS",
display_name=0x1fb57d0 "The Source",
client_id=0x1fb57dc "Non-DAW.nAICS",
out_msg=0x7fff7bc2aca8, userdata=0x0) at
../timeline/src/NSM.C:64
#15 0x000000000043d1c4 in _nsm_osc_open
(path=0x1ebe8c0 "/nsm/client/open",
types=0x1eea491 "sss", argv=0x1fb3a80, argc=3,
msg=0x1fb3a30,
user_data=0x1eb7550) at
/home/oem/non/nonlib/nsm.h:369
#16 0x00007f1b0ecb1a28 in ?? () from
/usr/lib/liblo.so.7
#17 0x00007f1b0ecb2262 in lo_server_dispatch_data ()
from /usr/lib/liblo.so.7
#18 0x00007f1b0ecb2835 in lo_server_recv () from
/usr/lib/liblo.so.7
#19 0x000000000043cf80 in nsm_check_wait
(nsm=0x1eb7550, timeout=0)
at /home/oem/non/nonlib/nsm.h:252
#20 0x000000000043cfa8 in nsm_check_nowait
(nsm=0x1eb7550)
at /home/oem/non/nonlib/nsm.h:259
#21 0x000000000043daf3 in check_nsm (v=0x0) at
../timeline/src/main.C:124
#22 0x00007f1b0e502a8c in Fl::wait
(time_to_wait=1e+20) at ../src/Fl.cxx:499
#23 0x00007f1b0e502bad in Fl::run () at
../src/Fl.cxx:542
#24 0x000000000043e09f in main (argc=1,
argv=0x7fff7bc2b478)
at ../timeline/src/main.C:290
Here's my interpretation: It seems that the Track
destructor is getting called twice on the same object. The second time it
tries to delete the underlying disk stream there is no thread to destroy,
and so it continues waiting for the thread to terminate forever. I have no
idea why the Track destructor is getting called twice for the same object.
I have problems loading sessions a couple times a
week on average, though this is the first time I've ever bothered to attach
gdb and get a trace. Usually what I do is revert to a backup (I use a cron
job to nightly backup my sessions to an external drive) or open up the
history file with a text editor and delete lines from the bottom of the
file until the session finally loads. Today I found a new way to
work-around the problem: "cp snapshot history" -- not an ideal solution in
the least, but the best I could do for now. In general I find loading
sessions to be unreliable. I feel I have no way to guarantee a session
will open again after I've done some work on it. It is quite scary.
Problems seem to occur mostly when I am adding/removing a lot of tracks
and/or takes in short succession.
Note I'm using the latest code from git...
One more thing: As part of my nightly backup I run a
script to replace all the symlinks in the sources directory with copies of
the actual files. I can't imagine this would cause non-daw to have trouble
loading sessions, but I'm mentioning it just in case. There is a script
included in non-daw called import-external-sources but I do not think it
works anymore, so I have written my own...
Regards,
Doug

A couple of things... Have you fiddled with *this*
non-daw project's history file in the way you describe? If not, then could
you send me a copy of it (I don't need the sources) so I can try and
reproduce the issue? If you have fiddled with it, well then all bets are
off as you may have created an inconsistent history.
Yes, I have fiddled with it, but only by deleting

things from the bottom of the file. This is just like undo-ing a bunch of
stuff, right? I've attached it to this message...

Converting the files from symlinks to files shouldn't
make any difference. I am curious why you have so many external sources and
why you need them copied in, though.
I work with other musicians long-distance. They send

me .wav or .mid files of their performances which I need to add to my mix.
(For .mid files I usually use jack render to convert them to .wav files and
then import them in.) I like stuff copied in so I can back it up easily --
all I have to do is back up the NSM Sessions directory. Also, I have two
computers running non-daw. Copying stuff in makes it way easier to sync
between the two machines.

If import-external-sources doesn't work, then why
didn't you just fix it? Are you planning to share the script you have
written so that the rest of us can benefit?
I created a utility called "unln" (based on

http://arctic.org/~dean/scripts/unln) which converts
find ~/NSM\ Sessions -type l -print0 | xargs -0
unln
Is import-external-sources still supposed to work? It
doesn't seem to be looking for symbolic links at all...has non-daw always
used symlinks for external sources? I thought that was a recent change...
I think this may be related to another bug I'm working

on fixing, but it's hard to say without being able to reproduce it.

1. I cannot reproduce this error with the latest git.
The session loads fine 100% of the time.

D'oh! Well, thanks for looking into this. Perhaps I
screwed something up on my end...

2. Perhaps the error is in your 'snapshot' file and not
the 'history' file? Can I have a copy of 'snapshot' too?

Unfortunately I did not keep the snapshot file. That
is, a new one has been created since I encountered this problem. However,
I doubt there was a problem with the snapshot file, because I was able to
get my session to load by doing "cp snapshot history", and everything has
worked wonderfully since then...

3. In the meantime, I have some lock ordering fixes
(maybe) on the lockfix branch in git (tuxfamily). Can you build that and
tell me if it makes any difference?

If I see this problem again I will try building the
branch...

Yes, I do think it's a race condition... well, something
like that anyway. I believe it's a failure of a playback diskthread to
shutdown. There should be some new console output regarding that on the
logfix branch (assuming you have built for debugging.

Oh, and it follows that snapshots always work--because
snapshots only create objects (tracks with diskthreads), and never destroy
them.

I've attached the console output from nsm. I think line 2103
[non-daw:engine] ../timeline/src/Engine/Disk_Stream.C:158
shutdown(): Disk_Stream thread has taken longer than 110ms to respond to
terminate signal.

Can you pull from master and try again?

Yes that works! Thank-you very much!
Unfortunately, when I try to abort the session in nsm, non-daw
does not close and needs to be killed violently. Before killing it I did
futex(0x8428854, FUTEX_WAIT_PRIVATE, 0, NULL
#0 0xb76f9424 in __kernel_vsyscall ()
#1 0xb766b16a in pthread_rwlock_wrlock ()
from /lib/i386-linux-gnu/libpthread.so.0
#2 0x08058688 in RWLock::wrlock (this=0x8428844)
at ../timeline/src/RWLock.H:52
#3 0x0806681b in Project::close () at
../timeline/src/Project.C:206
#4 0x0807568d in Timeline::command_quit (this=0x84287d8)
at ../timeline/src/Timeline.C:1998
#5 0x0807e484 in check_sigterm () at ../timeline/src/main.C:140
#6 0xb74d2163 in run_checks () at ../src/Fl.cxx:440
#7 0xb74d223a in Fl::wait (time_to_wait=1e+20) at
../src/Fl.cxx:504
#8 0xb74d2328 in Fl::run () at ../src/Fl.cxx:542
#9 0x0807ea4a in main (argc=1, argv=0xbfe5a134) at
../timeline/src/main.C:284
I often have problems like this when closing or aborting
sessions, so I don't know if this is related to your most recent fixes or
not...
Also, when I try to scroll down in the timeline, it
freezes...I've also seen this ocassionally in other versions so I don't
know if it's related to your changes...

Define 'freezes'... Does resizing the window bring it back to life?
'freezes' means it no longer responds to any mouse clicks or key

presses. When I try to resize, maximize or minimize the canvas does not
update, and the app stays frozen.

Well, that's pretty weird. I'm going to have to assume it's just the
deadlock issue and has little/nothing to do with scrolling. I am unable to
reproduce a hang when closing/aborting or otherwise exiting. Could you
provide some more context? I.e. is the transport rolling at the time or
anythign else? Also, if you can reproduce it, attach gdb and give the
output of 'thread apply all bt', that would be helpful.
Transport is not rolling. I just open the session and start

scrolling around. After a short time the timeline freezes. I've attached
the gdb output...

How are you scrolling? This backtrace indicates that input is being
directed to one of the sequneces. Are you dragging a region around? Are you
scrolling with the panzoomer at the bottom of the timeline? Or using the
mousewheel?

The mousewheel. I'm not dragging any regions or anything like that.
The session opened up with a track solo'd so I'm just scrolling down to
un-solo the track so I can hear my mix. But I've not been able to actually
scroll far enough to click the solo button...

Ok. Well, I'll have to look into it later. In the meantime, if you
scroll using the panzoomer, or even just use the mousewheel, but put the
cursor somewhere else (over the track headers or over the panzoomer should
do) you can work around this.
If you get that hang on close/abort again, It'd be nice to have the
'thread apply all bt' backtrace for that.
Here's a bt from the abort. It is quite repeatable...

Well, that isn't much help after all because it gives me no clue where the
lock was acquired. I still can't reproduce this, but I've pushed some
things to the 'lockfix' branch on tuxfamily. Can you confirm that it fixes
the hang on scrolling and confirm that it still hangs on close?

It fixes both problems! I tried opening, vigorously scrolling and
closing/aborting ~10 times and can't make it hang. I did get nsm to freeze
once, but I can't repeat it...

[J. Liles]

[huge snip]

It fixes both problems! I tried opening, vigorously scrolling and

Post by Douglas Regehr
closing/aborting ~10 times and can't make it hang. I did get nsm to freeze
once, but I can't repeat it...

OK. I've put these fixes and changes to restore peak mipmapping on
'master'.