[SoX-devel] spectrogram segfault

Discussion:

Jan Stary

2015-01-01 20:23:36 UTC

A new release candidate has been released

There seems to be a bug in the spectrogram effect,
also present in earlier releases.

$ sox -c 1 -b 16 -r 1000 -n file.wav synth 1 sin 440 gain -3
$ sox file.wav -n spectrogram
$ sox file.wav -n spectrogram -x 1000
$ sox file.wav -n spectrogram -x 1001
Segmentation fault (core dumped)
$ sox file.wav -n spectrogram -X 1000
$ sox file.wav -n spectrogram -X 1001
Segmentation fault (core dumped)

It seems that if the -x size of the spectrogram is bigger
than the number of actual samples (1000 in the example),
or samples/second, SoX segfaults instead of rejecting that option
(say, limiting the number to the number of samples available).

This is surely done in the start() function of spectrogram.c
but instead of trying to decipher it, I will leave to the devs.

Below please see the output of sox -V on the good and bad case,
here is an illustrative diff of the two:

--- /tmp/good Thu Jan 1 21:18:41 2015
+++ /tmp/bad Thu Jan 1 21:18:36 2015
@@ -33,15 +33,13 @@ Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors

sox DBUG effects: sox_add_effect: extending effects table, new size = 8
-sox DBUG spectrogram: duration=1 x_size=1000 pixels_per_sec=1000 dft_size=1024
+sox DBUG spectrogram: duration=1 x_size=1001 pixels_per_sec=1001 dft_size=1024
sox DBUG spectrogram: window_density=0.5
-sox DBUG spectrogram: step_size=1 block_steps=1
+sox INFO spectrogram: actual pixels/s = -inf
+sox DBUG spectrogram: step_size=-2147483648 block_steps=0
sox INFO sox: effects chain: input 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox INFO sox: effects chain: spectrogram 1000Hz 1 channels 16 bits 00:00:01.00
sox INFO sox: effects chain: output 1000Hz 1 channels (multi) 16 bits 00:00:01.00
-sox DBUG sox: start-up time = 0.002191
-sox DBUG spectrogram: cols=489 left=0 end=24
-sox INFO spectrogram: PNG truncated at 1 seconds
-sox INFO spectrogram: PNG truncated at 1 seconds
-sox DBUG spectrogram: flushed cols=1000 left=1 end=-512
-sox DBUG spectrogram: signal-max=-4.11314
+sox DBUG sox: start-up time = 0.005625
+sox DBUG spectrogram: cols=0 left=1073741312 end=1024
+Segmentation fault (core dumped)

I am running this on OpanBSD/amd64
but that doesn't seem to be relevant.

Jan

GOOD:

sox: SoX v14.4.2
time: Jan 1 2015 20:51:29
uname: OpenBSD lenovo.stare.cz 5.6 GENERIC.MP#735 amd64
compiler: gcc 4.2.1 20070719
arch: 1288 48 88 L
sox INFO formats: detected file format type `wav'
sox DBUG wav: Searching for 66 6d 74 20
sox DBUG wav: WAV Chunk fmt
sox DBUG wav: Searching for 64 61 74 61
sox DBUG wav: WAV Chunk data
sox DBUG wav: Reading Wave file: Microsoft PCM format, 1 channel, 1000 samp/sec
sox DBUG wav: 2000 byte/sec, 2 block align, 16 bits/samp, 2000 data bytes
sox DBUG wav: 1000 Samps/chans
sox DBUG wav: Searching for 4c 49 53 54

Input File : 'file.wav'
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors
File Size : 2.04k
Bit Rate : 16.4k
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no

Output File : '' (null)
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors

sox DBUG effects: sox_add_effect: extending effects table, new size = 8
sox DBUG spectrogram: duration=1 x_size=1000 pixels_per_sec=1000 dft_size=1024
sox DBUG spectrogram: window_density=0.5
sox DBUG spectrogram: step_size=1 block_steps=1
sox INFO sox: effects chain: input 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox INFO sox: effects chain: spectrogram 1000Hz 1 channels 16 bits 00:00:01.00
sox INFO sox: effects chain: output 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox DBUG sox: start-up time = 0.002191
sox DBUG spectrogram: cols=489 left=0 end=24
sox INFO spectrogram: PNG truncated at 1 seconds
sox INFO spectrogram: PNG truncated at 1 seconds
sox DBUG spectrogram: flushed cols=1000 left=1 end=-512
sox DBUG spectrogram: signal-max=-4.11314

BAD:

sox: SoX v14.4.2
time: Jan 1 2015 20:51:29
uname: OpenBSD lenovo.stare.cz 5.6 GENERIC.MP#735 amd64
compiler: gcc 4.2.1 20070719
arch: 1288 48 88 L
sox INFO formats: detected file format type `wav'
sox DBUG wav: Searching for 66 6d 74 20
sox DBUG wav: WAV Chunk fmt
sox DBUG wav: Searching for 64 61 74 61
sox DBUG wav: WAV Chunk data
sox DBUG wav: Reading Wave file: Microsoft PCM format, 1 channel, 1000 samp/sec
sox DBUG wav: 2000 byte/sec, 2 block align, 16 bits/samp, 2000 data bytes
sox DBUG wav: 1000 Samps/chans
sox DBUG wav: Searching for 4c 49 53 54

Input File : 'file.wav'
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors
File Size : 2.04k
Bit Rate : 16.4k
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no

Output File : '' (null)
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors

sox DBUG effects: sox_add_effect: extending effects table, new size = 8
sox DBUG spectrogram: duration=1 x_size=1001 pixels_per_sec=1001 dft_size=1024
sox DBUG spectrogram: window_density=0.5
sox INFO spectrogram: actual pixels/s = -inf
sox DBUG spectrogram: step_size=-2147483648 block_steps=0
sox INFO sox: effects chain: input 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox INFO sox: effects chain: spectrogram 1000Hz 1 channels 16 bits 00:00:01.00
sox INFO sox: effects chain: output 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox DBUG sox: start-up time = 0.005625
sox DBUG spectrogram: cols=0 left=1073741312 end=1024
Segmentation fault (core dumped)

Pander

2015-01-22 08:48:34 UTC

Permalink

Post by Jan Stary

A new release candidate has been released

Very Nice. Can you also provide a patch for it? For example, draw the
graph less wide, resulting in more white space.

Post by Jan Stary
sox: SoX v14.4.2
time: Jan 1 2015 20:51:29
uname: OpenBSD lenovo.stare.cz 5.6 GENERIC.MP#735 amd64
compiler: gcc 4.2.1 20070719
arch: 1288 48 88 L
sox INFO formats: detected file format type `wav'
sox DBUG wav: Searching for 66 6d 74 20
sox DBUG wav: WAV Chunk fmt
sox DBUG wav: Searching for 64 61 74 61
sox DBUG wav: WAV Chunk data
sox DBUG wav: Reading Wave file: Microsoft PCM format, 1 channel, 1000 samp/sec
sox DBUG wav: 2000 byte/sec, 2 block align, 16 bits/samp, 2000 data bytes
sox DBUG wav: 1000 Samps/chans
sox DBUG wav: Searching for 4c 49 53 54
Input File : 'file.wav'
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors
File Size : 2.04k
Bit Rate : 16.4k
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Output File : '' (null)
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors
sox DBUG effects: sox_add_effect: extending effects table, new size = 8
sox DBUG spectrogram: duration=1 x_size=1000 pixels_per_sec=1000 dft_size=1024
sox DBUG spectrogram: window_density=0.5
sox DBUG spectrogram: step_size=1 block_steps=1
sox INFO sox: effects chain: input 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox INFO sox: effects chain: spectrogram 1000Hz 1 channels 16 bits 00:00:01.00
sox INFO sox: effects chain: output 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox DBUG sox: start-up time = 0.002191
sox DBUG spectrogram: cols=489 left=0 end=24
sox INFO spectrogram: PNG truncated at 1 seconds
sox INFO spectrogram: PNG truncated at 1 seconds
sox DBUG spectrogram: flushed cols=1000 left=1 end=-512
sox DBUG spectrogram: signal-max=-4.11314
sox: SoX v14.4.2
time: Jan 1 2015 20:51:29
uname: OpenBSD lenovo.stare.cz 5.6 GENERIC.MP#735 amd64
compiler: gcc 4.2.1 20070719
arch: 1288 48 88 L
sox INFO formats: detected file format type `wav'
sox DBUG wav: Searching for 66 6d 74 20
sox DBUG wav: WAV Chunk fmt
sox DBUG wav: Searching for 64 61 74 61
sox DBUG wav: WAV Chunk data
sox DBUG wav: Reading Wave file: Microsoft PCM format, 1 channel, 1000 samp/sec
sox DBUG wav: 2000 byte/sec, 2 block align, 16 bits/samp, 2000 data bytes
sox DBUG wav: 1000 Samps/chans
sox DBUG wav: Searching for 4c 49 53 54
Input File : 'file.wav'
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors
File Size : 2.04k
Bit Rate : 16.4k
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Output File : '' (null)
Channels : 1
Sample Rate : 1000
Precision : 16-bit
Duration : 00:00:01.00 = 1000 samples ~ 75 CDDA sectors
sox DBUG effects: sox_add_effect: extending effects table, new size = 8
sox DBUG spectrogram: duration=1 x_size=1001 pixels_per_sec=1001 dft_size=1024
sox DBUG spectrogram: window_density=0.5
sox INFO spectrogram: actual pixels/s = -inf
sox DBUG spectrogram: step_size=-2147483648 block_steps=0
sox INFO sox: effects chain: input 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox INFO sox: effects chain: spectrogram 1000Hz 1 channels 16 bits 00:00:01.00
sox INFO sox: effects chain: output 1000Hz 1 channels (multi) 16 bits 00:00:01.00
sox DBUG sox: start-up time = 0.005625
sox DBUG spectrogram: cols=0 left=1073741312 end=1024
Segmentation fault (core dumped)
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
SoX-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sox-devel

Eric Wong

2015-12-29 22:07:00 UTC

Permalink

Post by Jan Stary
It seems that if the -x size of the spectrogram is bigger
than the number of actual samples (1000 in the example),
or samples/second, SoX segfaults instead of rejecting that option
(say, limiting the number to the number of samples available).

Thanks. I think ensuring p->block_steps is always >= 1
seems acceptable; but maybe there's a better way to fix this.

------------------------8<-------------------------
Subject: [PATCH] spectrogram: fix segfault when requested size exceeds length

Thanks to a bug report by Jan Stary:

ref: http://mid.gmane.org/***@www.stare.cz

Tested with the following Perl script based on Jan's bug report.
-------------------- spectrogram.t ----------------
use strict;
use Test::More 0.88; # 0.88+ for done_testing
use File::Temp qw/tempdir/;

my $tmpdir = tempdir('sox-spectrogram.XXXXXXXX', CLEANUP => 1);
chdir($tmpdir) or die "failed to chdir: $!\n";
END { chdir('/') }; # allow $tmpdir removal when test completes

sub cmd_ok {
my ($msg, @cmd) = @_;
is(system(@cmd), 0, $msg);
}

cmd_ok('create temporary test file',
qw(sox -c 1 -b 16 -r 1000 -n file.wav synth 1 sin 440 gain -3));

cmd_ok('create PNG with default',
qw(sox file.wav -n spectrogram));

cmd_ok('create PNG with exact -x size',
qw(sox file.wav -n spectrogram -o b.png));

cmd_ok('create PNG with larger -x size (should not SEGV)',
qw(sox file.wav -n spectrogram -x 1001 -o c.png));

cmd_ok('create PNG with exact -X size',
qw(sox file.wav -n spectrogram -X 1000 -o d.png));

cmd_ok('create PNG with larger -X size (should not SEGV)',
qw(sox file.wav -n spectrogram -X 1001 -o e.png));

done_testing();
---
src/spectrogram.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/src/spectrogram.c b/src/spectrogram.c
index afb0b0e..5a2115f 100644
--- a/src/spectrogram.c
+++ b/src/spectrogram.c
@@ -275,6 +275,8 @@ static int start(sox_effect_t * effp)
lsx_debug("window_density=%g", actual / p->dft_size);
p->step_size = (p->slack_overlap? sqrt(actual * p->dft_size) : actual) + .5;
p->block_steps = effp->in_signal.rate / pixels_per_sec;
+ if (p->block_steps == 0)
+ p->block_steps = 1;
p->step_size = p->block_steps / ceil((double)p->block_steps / p->step_size) +.5;
p->block_steps = floor((double)p->block_steps / p->step_size +.5);
p->block_norm = 1. / p->block_steps;

--
EW

------------------------------------------------------------------------------