Dear audio/sox users,
perhaps you have already read this on sox-users.
http://marc.info/?l=sox-users&m=137827656024871&w=2
Trying to use the sox pipes (-p) in a certain way segfaults,
and the way it segfaults seems to be specific to OpenBSD.
> > > $ sox -n one.sox synth 4.145 sin 440 gain -6
> > > $ sox -n two.sox synth 5.325 sin 540 gain -6
> > > $ sox -V "|sox one.sox -p trim 0 -`soxi -D two.sox`" two.sox out.sox
> > > sox: SoX v14.4.1
> > > sox INFO formats: detected file format type `sox'
> > > sox FAIL trim: Position 2 is before start of audio.
> > > sox INFO formats: detected file format type `sox'
> > > Segmentation fault (core dumped)
src/formats does the following to "rewind a pipe":
#define PIPE_AUTO_DETECT_SIZE 256 /* Only as much as we can rewind a pipe */
/* Hack to rewind pipes (a small amount).
* Works by resetting the FILE buffer pointer */
static void UNUSED rewind_pipe(FILE * fp)
{
/* _FSTDIO is for Torek stdio (i.e. most BSD-derived libc's)
* In theory, we no longer need to check _NEWLIB_VERSION or __APPLE__ */
#if defined _FSTDIO || defined _NEWLIB_VERSION || defined __APPLE__
fp->_p -= PIPE_AUTO_DETECT_SIZE;
fp->_r += PIPE_AUTO_DETECT_SIZE;
#elif defined __GLIBC__
fp->_IO_read_ptr = fp->_IO_read_base;
#elif defined _MSC_VER || defined _WIN32 || defined _WIN64 || defined
_ISO_STDIO_ISO_H
fp->_ptr = fp->_base;
#else
/* To fix this #error, either simply remove the #error line and live without
* file-type detection with pipes, or add support for your compiler in the
* lines above. Test with cat monkey.wav | ./sox --info - */
#error FIX NEEDED HERE
#define NO_REWIND_PIPE
(void)fp;
#endif
}
> > > > > > > Can you fire up gdb on the core dump and show us the backtrace?
> > > > > > > (hopefully your sox build has debugging symbols). Thanks.
> >
> > > #0 memcpy ()
> > > at /usr/src/lib/libc/arch/i386/string/bcopy.S:88
> > > 88 rep
> > > (gdb) bt
> > > #0 memcpy () at /usr/src/lib/libc/arch/i386/string/bcopy.S:88
> > > #1 0x06c2394b in fread (buf=0xcfbd6e24, size=1, count=4, fp=0x26bb8f98)
> > > at /usr/src/lib/libc/stdio/fread.c:69
> > > #2 0x0506eac1 in lsx_readbuf () from /usr/local/lib/libsox.so.3.0
> > > #3 0x0506ef00 in lsx_read_dw_buf () from /usr/local/lib/libsox.so.3.0
> > > #4 0x0506ef91 in lsx_readdw () from /usr/local/lib/libsox.so.3.0
> > > #5 0x050713af in startread () from /usr/local/lib/libsox.so.3.0
> > > #6 0x0506d2b7 in open_read () from /usr/local/lib/libsox.so.3.0
> >
> > OK, based on the above I suspect it's in the pipe handling code and not
> > a problem with trim itself. That code (in src/formats.c) contains some
> > strange OS-specific code for rewinding pipes, and I haven't looked
> > closely at it.
>
> I suppose you mean the rewind_pipe() function,
> which indeed looks like a dirty hack to my nonexpert eyes.
> I will try to point some OpenBSD people who know SoX
> at this code.
>
> > I strongly suspect this is OpenBSD-specific and only to pipes.
This is what happens on MacOSX 10.4.11:
$ sox -V "|sox one.sox -p trim 0 -`soxi -D two.sox`" two.sox out.sox
sox: SoX v14.4.1
sox INFO formats: detected file format type `sox'
sox FAIL trim: Position 2 is before start of audio.
sox INFO formats: detected file format type `sox'
sox FAIL formats: can't open input pipe `|sox one.sox -p trim 0 -5.325000':
can't find sox file format identifier
> > Can you reproduce the issue by using a temporary file instead of a pipe?
> SoX refuses to make the temporary file:
>
> $ sox -n one.sox synth 4.145 sin 440 gain -6
> $ sox -n two.sox synth 5.325 sin 540 gain -6
> $ sox one.sox part.sox trim 0 -`soxi -D two.sox`
> sox FAIL trim: Position 2 is before start of audio.
>
> which probably is the right thing. But with the pipe,
> it tries to go on, and crashes. Which might be a hint
> that it really is a pipe problem (namely, trying to rewind a pipe)
> and not a trim problem, right?
Can someone knowledgable about the workings of OpenBSD pipes
please sched some light on what's wrong here
(besides fscking with FILE->_p and FILE->_r)?
Jan
