Re: [SoX-users] Fwd: Re: sox merge two files of different length

[Eric Wong <normalperson@yhbt.net>]

Adding sox-devel to Cc:, Jan was able to trigger a segfault on
OpenBSD i386 with the below example on 14.4.1.

Jan Stary <hans@stare.cz> wrote:
> On Sep 04 06:22:25, normalperson@yhbt.net wrote:
> > Can you replace .wav with .sox (or other formats) and reproduce the
> > issue with a different format?
> 
> The same happens with the .sox format:
> 
>   $ 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) 
> 
> 
> > > > > 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.

Can you reproduce the issue by using a temporary file instead of a pipe?
I strongly suspect this is OpenBSD-specific and only to pipes.

> > A system call trace probably isn't going to be useful in this case.
> 
> I was just suspecting some of the time_t related problems
> to possibly show up. But I will stick to gdb then.
> 
> 	Jan
> 
> PS: should we move this to -dev?

Probably, yes.  Cc-ed them.  I'm not a real sox developer :)

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk