spotify / echoprint-codegen

Codegen for Echoprint

Home Page:http://echoprint.me/codegen

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Segmentation fault when duration set

moustaki opened this issue · comments

Using the latest HEAD:

$ ./echoprint-codegen preview.mp3 -s 10 20
Segmentation fault (core dumped)

It works fine without specifying any duration, on the same file, e.g.

$ ./echoprint-codegen preview.mp3 -s 10

Or when specifying a duration < 1 (which doesn't make much sense, I am guessing) e.g.

$ ./echoprint-codegen preview.mp3 -s 10 0.1

It looks like the segfault originates from line 135 of main.cxx:

    sprintf(output,"{\"error\":\"could not decode\", \"tag\":%d, \"metadata\":{\"filename\":\"%s\"}}",
        tag,
        escape(filename).c_str());

which implies that numSamples < -1, which means that the audio wasn't successfully decoded in that particular case.

Digging a bit more into that in gdb, it looks like, in that particular case, the ffmpeg command line never actually gets executed - and indeed, File::Exists(filename) returns false... and filename is empty. The cause of that filename being empty seems to be that the 'already' int in main.cxx is set to argv[4](which seems a bit odd).

The root of the problem seems to be that main.cxx is picking arguments in the wrong place in argv, and the following patch seems to fix it:

https://gist.github.com/3005431

Just noticed that the command-line syntax specified [ filename | -s ], hence closing the issue!

Hi Yves,

Thanks so much for the detailed bug report and patch - that is well appreciated and super helpful.

The intention of the "-s" option is to allow a list of filenames to be supplied to standard input. The codegen interprets "-s" as a special filename to signal this case, so you can call it in one of two ways:

$ ./echoprint-codegen preview.mp3 10 20 # supply the filename on the command line

or

$ ./echoprint-codegen -s 10 20 # supply filename on standard input
preview.mp3
^D

But the codgen should not be segfaulting under any circumstances so we will look into smarter command-line option processing to fix this.

Best,

Andrew