av_rescale_q returns wrong 64bits in arm cortex-a8 processor

[kaijun]

When I try to convert a audio pts timestamp 61415424 into clock time via av_rescale_q() of mathmatics.c in arm cortext-a8 processor of beagleboard, it returns a wrong 64bit.
in av_rescale_rnd(a,b,c,AV_ROUND_NEAR_INF), where a=61415424, b=1000000000, c=28224000, I checked it's return value is 2176000000 (0x81B32000). But it returns 18446744071590584320 (0xFFFFFFFF81B32000). It seems the high 32bits return minus instead of 0x0 due to sign bit in low 32bit (for timestamp smaller than 61415424, there is no problem). This case never happened when I used ffmpeg from svn repository.

[Michael Niedermayer]

you could add a few av_log/printf or use a debugger to follow the code in av_rescale_rnd() and check where it goes wrong

[kaijun]

yes, I have debugged. The value is correct inside av_rescale_rnd(). But after it returns, the value is wrong.

[Michael Niedermayer]

That sounds like a compiler bug

[kaijun]

I use same compiler. This case happens at e1a86d03855f2fb1bf7961efd6794ddd9226f228 (master-git), but not at c6c2dfcf15c1d93b2189adff6f71c5c4b6b05338 (0.6.2). I guess some compilation options in configure or Makefile produce the issue.

[Carl Eugen Hoyos]

Please use git bisect to find the version introducing the problem.

[Carl Eugen Hoyos]

Which compiler are you using?

[kaijun]

angstrom

[Carl Eugen Hoyos]

I don't know what "angstrom" is but I would have expected a version number or "cc -v" output - please provide that.
Do I understand correctly that the problem cannot be reproduced with gcc?

[kaijun]

arm-angstrom-linux-gnueabi-gcc is a cross-compiler for arm-based device like beagleboard.

run arm-angstrom-linux-gnueabi-gcc -v

Using built-in specs.
COLLECT_GCC=tmp/sysroots/x86_64-linux/usr/armv7a/bin/arm-angstrom-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.3/lto-wrapper
Target: arm-angstrom-linux-gnueabi
Configured with: /home/tang/Projects/OE/build/tmp/work/armv7a-angstrom-linux-gnueabi/gcc-cross-4.5-r38.1+svnr170880/gcc-4_5-branch/configure --build=x86_64-linux --host=x86_64-linux --target=arm-angstrom-linux-gnueabi --prefix=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a --exec_prefix=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a --bindir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/bin --sbindir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/bin --libexecdir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/libexec --datadir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/share --sysconfdir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/etc --sharedstatedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/com --localstatedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/var --libdir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/lib --includedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/include --oldincludedir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/include --infodir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/share/info --mandir=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/share/man --with-libtool-sysroot --enable-largefile --disable-nls --enable-ipv6 --with-gnu-ld --enable-shared --enable-languages=c,c++,objc,fortran --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-angstrom-linux-gnueabi- --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-float=softfp --with-sysroot=/home/tang/Projects/OE/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi --with-build-sysroot=/home/tang/Projects/OE/build/tmp/sysroots/armv7a-angstrom-linux-gnueabi --with-build-time-tools=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr/armv7a/bin --disable-libunwind-exceptions --with-mpfr=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr -with-libelf=/home/tang/Projects/OE/build/tmp/sysroots/x86_64-linux/usr --with-system-zlib --program-prefix=arm-angstrom-linux-gnueabi- --enable-cxa_atexit
Thread model: posix
gcc version 4.5.3 20110311 (prerelease) (GCC)

[Carl Eugen Hoyos]

Where you able to run git bisect to find the change introducing the problem?

[kaijun]

Can you give me specific steps? I have run git bisect good or bad with
e1a86d03855f2fb1bf7961efd6794ddd9226f228 was both good and bad

[Carl Eugen Hoyos]

I am not sure I understand: You wrote above that c6c2dfcf15c1d93b2189adff6f71c5c4b6b05338 works fine but that e1a86d03855f2fb1bf7961efd6794ddd9226f228 shows the problem you describe.

So you can run:

$ make distclean
$ git bisect start
$ git bisect good c6c2dfcf15c1d93b2189adff6f71c5c4b6b05338
$ git bisect bad e1a86d03855f2fb1bf7961efd6794ddd9226f228
$ ./configure && make

Then test if the problem occurs with the resulting binary or not and repeat the following lines until the responsible commit is found (git bisect good if the problem does not occur, git bisect bad if you can reproduce the issue):

$ make distclean && git bisect good / bad
$ ./configure && make

When you are finished, run

$ make distclean && git bisect reset

to get back to the revision before running the tests.

[kaijun]

this issue happens at 0ebcdf5cdad6bf20a5170735a7f77b23ecc081ac where mathematics.h is removed from libavutil/avutil.h. After it is reverted, the issue is gone. I don't know why this would produce the issue.

[Carl Eugen Hoyos]

Replying to kaijun61:

this issue happens at 0ebcdf5cdad6bf20a5170735a7f77b23ecc081ac where mathematics.h is removed from libavutil/avutil.h.

Given that libavutil/avutil,h does include mathematics.h this does not sound like a very likely explanation:
​http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/avutil.h;hb=HEAD#l330

The version numbers you used above also look suspicious: Are you sure that you are using a supported, non-broken version of FFmpeg as offered on ​http://ffmpeg.org/download.html

[kaijun]

I need to mention, since ffmpeg is moved libav, I got source codes from libav. I assume both share same source codes. Are they different?

[Carl Eugen Hoyos]

I don't think FFmpeg has moved, please test sources from ​http://ffmpeg.org/download.html and report if you can reproduce your problem.

[kaijun]

I find mathematics.h was reverted later on for other reasons.

[Carl Eugen Hoyos]

Do I understand you correctly that the issue is not reproducible with FFmpeg?

[kaijun]

I feel confused about ffmpeg and libav. Before and including ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a85ce653fb14ae968419453fabf1ffe10d1f15df commit, both repos. look same. But from this snap, I don't see mathematics.h included. But its previous one and one after two commits, i.e. one you want me to look at have mathematics.h. Also after this snap, both libav and ffmpeg have different commits.

[Carl Eugen Hoyos]

Replying to kaijun61:

I feel confused about ffmpeg and libav. Before and including ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a85ce653fb14ae968419453fabf1ffe10d1f15df commit, both repos. look same.

For several months, there is one (of several) forks of FFmpeg that is known to contain many (>100) regressions over FFmpeg. Since some of those bugs in this fork are possibly security-relevant, we strongly recommend only to use FFmpeg from ​http://ffmpeg.org (which you can download from the videolan server). The FFmpeg tree also contains the complete history of this fork, but there should be no reason for you to use it, the commit you quote above does come from the mentioned fork, the correct version to test would be 48706f41 (the subsequent commit):
​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=48706f41e1a17e04b0aa09852eff021833708233

But from this snap, I don't see mathematics.h included. But its previous one and one after two commits, i.e. one you want me to look at have mathematics.h. Also after this snap, both libav and ffmpeg have different commits.

Can you tell me if you can reproduce the problem you described above with FFmpeg git head (or any released version)?

[kaijun]

the issue is not reproducible in head commit.

[Carl Eugen Hoyos]

Thank you for testing!