View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006753ardourbugspublic2016-01-28 16:142016-12-06 04:47
Assigned Totimbyr 
PlatformPCOSUbuntuOS Version15.10
Product Version 
Target VersionFixed 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 #30-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
  Installed: 1:4.6.22-1kxstudio1v5
  Candidate: 1:4.6.22-1kxstudio1v5
  Version table:
 *** 1:4.6.22-1kxstudio1v5 0
        500 [^] gcc5/free amd64 Packages
TagsNo tags attached.
Attached Filescpp file icon test-glib-wrlock.cpp [^] (198 bytes) 2016-02-04 03:28

- Relationships

-  Notes
elgoun (reporter)
2016-02-04 03:27
edited on: 2016-02-04 03: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::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 (reporter)
2016-02-05 02:02

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 (developer)
2016-02-10 19:50

I can confirm this issue with ardour master at revision 148f2ab8e5 or nightly build 4.6.298
paul (administrator)
2016-12-01 15:24

We disagree somewhat with the glib authors about the way RWLock behaves. But this does seem like a good solution.
elgoun (reporter)
2016-12-01 15:28

Just added a proposition as pull request (#303) to fix this issue.
timbyr (developer)
2016-12-06 04:46

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.

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

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker