View Issue Details

IDProjectCategoryView StatusLast Update
0006753ardourbugspublic2020-04-19 20:17
Reportermosteo Assigned Totimbyr  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
PlatformPCOSUbuntuOS Version15.10
Fixed in Version5.X git (version in description) 
Summary0006753: Crash when ending recording in non-layered track
DescriptionI start recording normally, and when I hit the spacebard to stop the recording Ardour crashes instantly. If launched from the console I see the message "Illegal instruction".
Steps To ReproduceCreate new session
Add a track with non-layered record mode
Arm the track and the recording
Hit space to start recording, hit again to stop --> crash

Creating a track with normal mode and later switching it crashes the same.
Additional InformationOS is ubuntu with Ardour from kxstudio:

$ uname -a
Linux isila 4.2.0-25-lowlatency 0000030-Ubuntu SMP PREEMPT Mon Jan 18 13:13:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.10
Release: 15.10
Codename: wily

$ wajig policy ardour4
ardour4:
  Installed: 1:4.6.22-1kxstudio1v5
  Candidate: 1:4.6.22-1kxstudio1v5
  Version table:
 *** 1:4.6.22-1kxstudio1v5 0
        500 http://kxstudio.linuxaudio.org/repo/ gcc5/free amd64 Packages
TagsNo tags attached.

Activities

elgoun

2016-02-04 11:27

reporter   ~0017880

Last edited: 2016-02-04 11:30

I found what trigger the illegal instruction but I don't know how to properly fix that.
The bug is due to a recursive acquisition and release on the RWLock in playlist.cc

Playlist::add_region hold the RWlock, then call Playlist::partition_internal which hold the lock too. At the end of partition_internal, the lock is released a first time. A the end of region_add, the lock is released a second time => This is the trigger.

A GLib bug ?

Attached a little example that trigger the "Illegal Instruction"

With GLib's C version, same behavior.

elgoun

2016-02-04 11:28

reporter  

test-glib-wrlock.cpp (198 bytes)   
#include <glibmm/threads.h>

int main(int argc, char **argv)
{
	Glib::Threads::RWLock lock;

	Glib::Threads::RWLock::WriterLock wl(lock);
	Glib::Threads::RWLock::WriterLock wl2(lock);

	return 0;
}
test-glib-wrlock.cpp (198 bytes)   

elgoun

2016-02-05 10:02

reporter   ~0017883

Looking at pthread doc, it seems that a thread already own a rwlock can't acquire it a second time. pthread_rwlock_wrlock returns EDEADLK in that case.

Consequently, pthread_rwlock_unlock is called a first time on a owned lock, and a second time on a unowned lock which can be undefined behavior.

timbyr

2016-02-11 03:50

developer   ~0017905

I can confirm this issue with ardour master at revision 148f2ab8e5 or nightly build 4.6.298

paul

2016-12-01 23:24

administrator   ~0019099

We disagree somewhat with the glib authors about the way RWLock behaves. But this does seem like a good solution.

elgoun

2016-12-01 23:28

reporter   ~0019100

Just added a proposition as pull request (0000303) to fix this issue.

timbyr

2016-12-06 12:46

developer   ~0019128

A fix for this issue has been committed to master branch as 0356d641 and will be included in a nightly build >= 5.5.39

Please test and confirm if you can, thanks.

system

2020-04-19 20:17

developer   ~0023580

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2016-01-29 00:14 mosteo New Issue
2016-02-04 11:27 elgoun Note Added: 0017880
2016-02-04 11:28 elgoun File Added: test-glib-wrlock.cpp
2016-02-04 11:30 elgoun Note Edited: 0017880
2016-02-04 11:30 elgoun Note Edited: 0017880
2016-02-05 10:02 elgoun Note Added: 0017883
2016-02-11 03:50 timbyr Note Added: 0017905
2016-02-11 03:50 timbyr Status new => confirmed
2016-12-01 23:24 paul Note Added: 0019099
2016-12-01 23:28 elgoun Note Added: 0019100
2016-12-06 12:46 timbyr Note Added: 0019128
2016-12-06 12:47 timbyr Status confirmed => resolved
2016-12-06 12:47 timbyr Fixed in Version => 5.X git (version in description)
2016-12-06 12:47 timbyr Resolution open => fixed
2016-12-06 12:47 timbyr Assigned To => timbyr
2020-04-19 20:17 system Note Added: 0023580
2020-04-19 20:17 system Status resolved => closed