View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006753 | ardour | bugs | public | 2016-01-29 00:14 | 2020-04-19 20:17 |
Reporter | mosteo | Assigned To | timbyr | ||
Priority | normal | Severity | crash | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | PC | OS | Ubuntu | OS Version | 15.10 |
Fixed in Version | 5.X git (version in description) | ||||
Summary | 0006753: Crash when ending recording in non-layered track | ||||
Description | I 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 Reproduce | Create 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 Information | OS 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 | ||||
Tags | No tags attached. | ||||
|
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. |
|
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; } |
|
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. |
|
I can confirm this issue with ardour master at revision 148f2ab8e5 or nightly build 4.6.298 |
|
We disagree somewhat with the glib authors about the way RWLock behaves. But this does seem like a good solution. |
|
Just added a proposition as pull request (0000303) to fix this issue. |
|
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 has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
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 |