View Issue Details
|ID||Category||Date Submitted||Last Update|
|0008655||bugs||2021-04-06 08:00||2021-04-22 00:04|
|Fixed in Version|
|Summary||0008655: Consistent "buffer overflow detected" when starting recording (probably FD_SET)|
first of all, I should clarify I'm using Ardour 6.5.0, as that's the only one available on Fedora 33 (6.6 is not there yet).
A project I was working on starting becoming unusable, since any time I tried to start recording a track, it would crash with a "buffer overflow detected" error. Starting playback and then hitting the global recording button works: enabling recording before playback causes it to crash. I collected a gdb trace which you can find attached.
Something interesting in the trace is that if I navigate to what causes the issue:
#6 0x00007ffff72c3698 in PBD::SystemExec::output_interposer (
this=0x7fffffffd2a0) at ../libs/pbd/system_exec.cc:841
841 FD_SET (rfd, &rfds);
(gdb) p rfd
$1 = 1048
you can see that the file descriptor is higher than what FD_SET supports (1023). Not sure why FD_SET is used there and not something like poll, but that's very likely what's causing the crash.
I can consistently replicate the same issue another way as well, that is adding a new MIDI track and using Yoshimi as a plugin. This results in the plugin using fltk to add a new file descriptor too (Fl::add_fd), which is also higher than 1023, and since that library uses FD_CLR and related helpers it crashes Ardour for the same reason:
#6 0x00007ffef33fb16c in Fl::remove_fd (n=n@entry=1046, events=events@entry=1)
186 if (events & POLLIN) FD_CLR(n, &fdsets);
(gdb) p n
$1 = 1046
Since I don't know when an update with a fix will be available, what can cause so many sockets/file descriptors to be in use in Ardour? I'm not using that many tracks in this project, and I've definitely used many more in the past, so it's not sure what I did to cause the problem to appear: I haven't even started adding plugins to tracks either (e.g., reverb, compression, etc.). Any tip on where to be more conservative here would be of great help.
|Steps To Reproduce||I'm not sure how this can replicated. I ended up in a session where this can be replicated consistently, but how I got there I don't know (and would gladly take the steps needed to before it happened).|
ardour6-crash_recording.log (70,574 bytes)
Quick update: apparently, cleaning up the session from unused files fixed this. I always do a lot of takes for each part (what can I say, I'm a clumsy player!), and it turns out every single attempt I then discarded to try again was still there, possibly acting as part of a very long undo. In the case of this project, 1.8G out of 2.5G were removed, and for some reason this was enough not to have Ardour crash anymore.
Not sure what unused files and/or undo have to do with file descriptors (if they were the cause), but the problem is indeed there. Please let me know if there's anything else I can provide to help fix the issue.
||PS: maybe each of those files was opened at session startup and not closed for the duration of the project, in case it could be needed later on?|
The file descriptor count will rise by 1 for each distinct audio file (this is one of the reason that ardour prints the system file open limit to stdout during startup (it varies quite dramatically). The files get opened on demand, and are generally not closed. At one time, we had an LRU cache for file descriptors, but ultimately dropped it because it was complex and generally unnecessary on a modern system.
However, the FD_SET issue that you've raised here is different (hard-coded limit to the API), and so needs a different approach.
|2021-04-06 08:00||lminiero||New Issue|
|2021-04-06 08:00||lminiero||Tag Attached: 6.5|
|2021-04-06 08:00||lminiero||File Added: ardour6-crash_recording.log|
|2021-04-07 14:14||lminiero||Note Added: 0025679|
|2021-04-07 14:16||lminiero||Note Added: 0025680|
|2021-04-22 00:04||paul||Note Added: 0025729|