[FFmpeg-cvslog] r18896 - trunk/libavcodec/eatgq.c

Måns Rullgård mans
Sat May 23 22:46:14 CEST 2009


Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Sat, May 23, 2009 at 05:46:08PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> 
>> > On Sat, May 23, 2009 at 04:25:11PM +0100, M?ns Rullg?rd wrote:
>> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> >> > So it seems to me that the commit message is quite accurate, even if
>> >> > we might want to avoid aligned data on the stack completely in the
>> >> > future.
>> >> 
>> >> Aligning stack variables is either possible or impossible.  Unreliable
>> >> is equivalent to impossible.  The commit message is misleading.
>> >
>> > No, unreliable meant "possible, but probably several compilers we might
>> > like to support are broken, so it is better to avoid it".
>> 
>> It is known to fail on several compilers/systems we *do* support right
>> now.  For instance, regression tests are failing on Sparc and Blackfin
>> because of such invalid assumptions.
>
> Are there proper bug reports for them? The FATE machine seems to have
> more issues than that. If not only other issues.

I have fixed the ones I've pinned down, but there are still some I
haven't looked into yet.

>> > If you insist I can extend the commit message into such extended prose,
>> > but I really think such details would be more appropriate in some
>> > developer reference.
>> > Particularly since it seems to me that your view of FFmpeg code is
>> > severely out of touch with reality,
>> 
>> I am well aware of the existence of flawed code presently in FFmpeg.
>> This is no excuse for adding even more of it.
>
> Would you or someone else volunteer to add a section to the coding
> documentation? That's one of the better ways to avoid that in the
> future.

Good idea.

> Still, given the code you reply to I think we are on the same side on
> this, just looking at the data I have this looks like a very minor issue
> _in practice_.

There are only a few bits of code presently in FFmpeg that result in
actual runtime errors, so in that sense it is perhaps a minor issue.
This does not mean it is generally safe to rely on alignment of stack
variables beyond the maximum required alignment of any native type on
the target architecture.

>> I think it's time YOU got back in touch with reality, a reality which
>> contains vastly more than gcc/linux/x86.

Sorry, that was too harsh.

> Well, you misunderstood my point:
> 1) What I consider core parts of FFmpeg relies on alignment on stack, so
> it can't really be that bad in reality
> 2) It makes it look far less obvious to me what the "official" FFmpeg
> position is: are the compilers buggy (as that one message we still print
> says) and that's not our problem or should the code be changed?
>
> Obviously it is not so simple. Apart from that I fear that reality
> (unfortunately) actually does not contain much more than gcc/linux/x86
> (well, at least any two of those three).

FATE has armcc/linux/arm which has only one of those.

> And looking at FATE, it seems to me that even on the "strange"
> architectures more errors come from something else, not stack
> alignment issues...

Here's an excerpt from the kernel log on my Alpha machine:

ffmpeg_g(21360): unaligned trap at 00000001203bc770: 00000200007c8c21 29 4
ffmpeg_g(21360): unaligned trap at 00000001203bc770: 00000200007c8c29 29 4
ffmpeg_g(21360): unaligned trap at 00000001203bc770: 00000200007c8c31 29 4
ffmpeg_g(21360): unaligned trap at 00000001203bc770: 00000200007c8c39 29 4
ffmpeg_g(22343): unaligned trap at 00000001204ad364: 00000200008c0d8c 29 1
ffmpeg_g(22343): unaligned trap at 00000001204ad394: 00000200008c0ef4 29 1
ffmpeg_g(22343): unaligned trap at 00000001204ad3c4: 00000200008c105c 29 1
ffmpeg_g(22343): unaligned trap at 00000001204ad3f4: 00000200008c11c4 29 1
ffmpeg_g(22384): unaligned trap at 00000001204ad364: 00000200008c0d8c 29 1
ffmpeg_g(22384): unaligned trap at 00000001204ad394: 00000200008c0ef4 29 1
ffmpeg_g(22384): unaligned trap at 00000001204ad3c4: 00000200008c105c 29 1
ffmpeg_g(22384): unaligned trap at 00000001204ad3f4: 00000200008c11c4 29 1
ffmpeg(24756): unaligned trap at 00000001202e6228: 0000000120a7c9fc 2d 2
ffmpeg(24756): unaligned trap at 00000001202e6230: 0000000120a7c9ec 2d 2
ffmpeg(24756): unaligned trap at 00000001202e8d34: 0000000120a7c9ec 2d 31
ffmpeg(24756): unaligned trap at 00000001202e8d3c: 0000000120a7c9fc 2d 31
ffmpeg(24783): unaligned trap at 00000001202b421c: 00000200002ca011 28 1
ffmpeg(24783): unaligned trap at 00000001202b421c: 00000200002ca015 28 1
ffmpeg(24783): unaligned trap at 00000001202b421c: 00000200002ca019 28 1
ffmpeg(24783): unaligned trap at 00000001202b421c: 00000200002ca01d 28 1

Quite clearly, something is not aligned correctly.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-cvslog mailing list