[CRASH] Floating point exception in mythtranscode

[Kris McGrath <shiftybugger@…>]

mythtranscode crashes with a floating point exception in transcode.cpp(109) when called with the following:

mythtranscode --profile autodetect --honorcutlist --chanid 1006 --starttime xxxxxxx222627 --fifodir /var/tmp/xxxxxxx

It fails on 100% of the 10 files that I have tried so far.

[Kris McGrath <shiftybugger@…>]

backtrace

[Kris McGrath <shiftybugger@…>]

mythbackend version

[Kris McGrath <shiftybugger@…>]

sample failing recording: ​http://rapidshare.com/files/453465789/1006_20110320222627.mpg

[sphery]

This seems to be a duplicate of #9425.

Thank you very much for the excellent report, Kris--you provided all the information (backtrace, full command-line arguments, and video sample) we were waiting for on #9425.

[Christophe.Boulain@…]

Hello,

I'm not sure that's the same problem. #9425 reports a segfault, as this ticket reports a FP Exception (division by zero). I've exactly the same problem than Kris, and I updated my git this morning after seeing the fix for #9425.

Line 109 of transcode.cpp is :

        // last_audiotime is at the end of the frame
        last_audiotime = timecode + (len / bytes_per_frame) * 1000 /
            eff_audiorate;

and eff_audiorate=0 (see gdb log & bt)

I'll also attach a complete '-v all' log of mythtranscode.

Note than lossely transcoding (--mpeg2) will transcode OK, but never finished. After transcoding, mythtranscode hang with 100% cpu. Playing the .mpg.tmp file created seems to work, but as mythtranscode never finish, the file is not renamed and db is not updated.

Thanks

[Christophe.Boulain@…]

GDB output MythTranscode?

[Christophe.Boulain@…]

MythTranscode? verbose log

[Christophe.Boulain@…]

My mythtv version

[robertm]

This does not necessarily mean that these two tickets are not duplicates. Your diagnostic info was used to solve #9425, the other ticket has been closed, please update to 53c94717dce6d5a3c0755fcc132afd2df4f26b18 or later and test again, and only reopen with new version and log info if the problem still exists.

[robertm]

Sorry Kris, my mistake, didn't realize you had already updated to the post-#9425 fix. Obviously they are distinct issues.

[JYA]

Actually while on the same line, it's a different crash than the one reported earlier (where it was bytes_per_frame that was 0).

I had noticed that bug too, and also fixed it while at it

[JYA]

Fixed in SHA: b21f784196c37f4dc4c55446dfdb3edd4ebcbe3b

[Kris McGrath <shiftybugger@…>]

Replying to jyavenard:

Fixed in SHA: b21f784196c37f4dc4c55446dfdb3edd4ebcbe3b

Confirmed fixed