systemd-coredump[4294]: Process 22356 (audacity) of user 1000 dumped core [SOLVED]

Audacity Help Forum GNU/Linux
1

Audacity 2.2.2
Arch Linux (from repo)
Linux 4.20.0-arch1-1-ARCH #1 SMP PREEMPT

Audacity is randomly dumping core for me when I am recording for a long time. I have plenty of disk space (over 100GB free) and plenty of ram (64GB). I am recording while monitoring so have the software buffering on.

Here are the entries I see in the journal:

Jan 24 02:28:24 t3600 audit[20104]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=20104 comm="audacity" exe="/usr/bin/audacity" sig=6 res=1
Jan 24 02:28:24 t3600 kernel: audit: type=1701 audit(1548314904.506:363): auid=1000 uid=1000 gid=1000 ses=2 pid=20104 comm="audacity" exe="/usr/bin/audacity" sig=6 res=1
Jan 24 02:28:27 t3600 systemd-coredump[2186]: Process 20104 (audacity) of user 1000 dumped core.
                                              #4  0x00005570f8679c84 n/a (audacity)
                                              #5  0x00005570f867e1d4 n/a (audacity)
                                              #6  0x00005570f867e947 n/a (audacity)
                                              #2  0x00005570f8252370 _ZN10MidiThread5EntryEv (audacity)
                                              #24 0x00005570f81e0ba3 main (audacity)
                                              #26 0x00005570f82058fe _start (audacity)
                                              #2  0x00005570f8257c73 _ZN11AudioThread5EntryEv (audacity)
Jan 24 07:58:27 t3600 audit[22356]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 pid=22356 comm="audacity" exe="/usr/bin/audacity" sig=6 res=1
Jan 24 07:58:27 t3600 kernel: audit: type=1701 audit(1548334707.251:366): auid=1000 uid=1000 gid=1000 ses=2 pid=22356 comm="audacity" exe="/usr/bin/audacity" sig=6 res=1
Jan 24 07:58:29 t3600 systemd-coredump[4294]: Process 22356 (audacity) of user 1000 dumped core.
                                              #4  0x00005647dfedac84 n/a (audacity)
                                              #5  0x00005647dfedf1d4 n/a (audacity)
                                              #6  0x00005647dfedf947 n/a (audacity)
                                              #2  0x00005647dfab3370 _ZN10MidiThread5EntryEv (audacity)
                                              #2  0x00005647dfab8c73 _ZN11AudioThread5EntryEv (audacity)
                                              #9  0x00005647dfe01bc7 _ZN16ScrubbingOverlay7OnTimerER14wxCommandEvent (audacity)
                                              #15 0x00005647dfbe89fd _ZN10TrackPanel7OnTimerER12wxTimerEvent (audacity)
                                              #33 0x00005647dfa41ba3 main (audacity)
                                              #35 0x00005647dfa668fe _start (audacity)

How may I further debug this? It is a very annoying problem as I cannot reliably record now while unattended.

2

When recording into a project that has not yet been saved, the audio data is written to Audacity’s Temp folder.
Check where the Temp folder is located (look in “Edit menu > Preferences > Directories”) and check the amount of space available in that location.

3

/var/tmp/audacity-david
Free Space: 162.9 GB

While recording at the bottom audacity also reports:
“Disk space remaining for recording: 137 hours and 42 minutes”

This is an ext4 partition encrypted with LUKS so there is probably no free space funny business such as with btrfs.

Should I submit the core dump somewhere or attempt other debugging? I’d be happy to help get this resolved.

4

Debugging is rather limited in release builds.

Are you able to build applications from source code? If you are, then it may be worth building the current release version of Audacity (2.3.0) or the current development version (2.3.1). If the problem still occurs with a newer version, you would be able to make a debug build and run it in gdb to obtain useful debug information.

Have you checked on the Arch bug tracker to see if this is a known problem? (As far as I’m aware, this issue is not on the Audacity bug tracker).

5

steve, thanks for the replies. I should be able to handle building from source (also a former Gentoo user ; ) ). I’ll probably go ahead and build 2.3.0 and try to gather more useful information.

Also I have the thought that I might try also disabling the software buffering for the live monitoring just to see if it still occurs. To be fair usually it is getting at least several hours before crashing.

6

and to be fair, I’ve never attempted to make such a long recording, though I know that many Windows users do so regularly without problems.

7

Er forgot to mention: I didn’t see anything on the arch bugtracker.

I believe I found something of further significance though right before the core dump:

Jan 24 07:57:28 t3600 pulseaudio[852]: E: [alsa-sink-ALC269VB Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Jan 24 07:57:28 t3600 pulseaudio[852]: W: [pulseaudio] sink-input.c: Failed to create sink input: sink is suspended.

I do have Pulseaudio configured for simultaneous output to hdmi (my main sound speakers) and to some external speakers which I mainly use to plug in headphones. This allows me to simply mute the TV speakers and be able to hear on the headphones.

I theorize maybe something else is grabbing the soundcard device for playback and Audacity isn’t able to handle this gracefully? It probably should not dump core on this, no?

Any recommendations or things to try besides dropping the simultaneous playback and/or getting a separate card and/or not doing live monitoring?

8

You may be onto something here.
No, Audacity should not core dump on this, but there is a common problem of Audacity freezing with PulseAudio (https://bugzilla.audacityteam.org/show_bug.cgi?id=276) so this could be related.

The workaround that works best for me is to select the ALSA “hw” device for recording, and either the “hw” device or dmix for playback.

9

Solved in the sense that it is no longer a problem for me.

I had forgotten to install the ‘pulseaudio-alsa’ package in Arch so basically Audacity was just using straight Alsa (instead of Alsa through Pulseaudio) and trying to grab the card directly. In installing this and then setting the output and recording device to use Pulse everything seems to work perfectly. I did a test recording of 10 hours without any issues. :slight_smile:

While there must be a bug somewhere, it’s now working great for me with Pulseaudio.