View Issue Details

IDCategoryLast Update
0008655bugs2021-05-07 14:22
ReporterlminieroAssigned Topaul 
Reproducibilityalways 
Status assignedResolutionopen 
PlatformGNUOSLinuxOS Version(any)
Product Version6.6 
Fixed in Version 
Summary0008655: Consistent "buffer overflow detected" when starting recording (probably FD_SET)
DescriptionHi,

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)
    at /usr/src/debug/fltk-1.3.5-8.fc33.x86_64/src/Fl_x.cxx:186
186 if (events & POLLIN) FD_CLR(n, &fdsets[0]);
(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.

Thanks!
Steps To ReproduceI'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).
Tags6.5

Activities

lminiero

2021-04-06 08:00

reporter  

ardour6-crash_recording.log (70,574 bytes)

lminiero

2021-04-07 14:14

reporter   ~0025679

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.

lminiero

2021-04-07 14:16

reporter   ~0025680

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?

paul

2021-04-22 00:04

administrator   ~0025729

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.

paul

2021-05-06 20:45

administrator   ~0025792

Commit 3a7ea6b217 should fix this.

If possible, please check the nightly build from nightly.ardour.org (there's a free demo version, and it can be installed in parallel with the fedora one), after May 6th at about 11:00 UTC.

lminiero

2021-05-07 14:22

reporter   ~0025795

Thanks for the update, Paul! I'll try using one of the Nightly builds, even though that session doesn't have that many files anymore, as I cleaned unused files since. I'll try to replicate the scenario I was in with a new session, to see if it's not crashing anymore.

Issue History

Date Modified Username Field Change
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
2021-05-06 20:45 paul Assigned To => paul
2021-05-06 20:45 paul Status new => feedback
2021-05-06 20:45 paul Note Added: 0025792
2021-05-07 14:22 lminiero Note Added: 0025795
2021-05-07 14:22 lminiero Status feedback => assigned