[sparc] iceweasel: Bus Error in setbuf()

[Michael Karcher]

A summary of the current situation:

There are historic programs and libraries relying on the old FILE
structure. These programs and libraries assume that any 4-byte aligned
FILE structure is acceptable, because that was the case with libio 2.0

Most programs and libraries are compiled with libio 2.1. At least on
sparc, this means that FILE objects now need to be aligned on an 8-byte
boundary. The compiler assumes this alignment when generating code using
libio 2.1 (or newer) headers.

The alignment difference is the cause that even though glibc maintainers
took a lot of effort to make the old and the new structure compatible,
there can be unexpected problems on sparc, because it seems like the
alignment issue was not considered at that time.

There is no silver bullet - either we have an 8-byte alignment
requirement, which keeps compatibility with all libio 2.1 code, or we
relax the requirement to 4-byte alignment (by splitting the 64-bit
offset field and implementing the 64-bit-arithmetic by hand), which will
re-enable full compatibility with libio 2.0 code. Especially as libio
2.0 and libio 2.1 libraries can be dynamically mixed, and all code
expects that FILE* pointers of the old and new variant are
interchangable for the narrow-character interface, there is some mess
outside of glibc already that can never be fixed.

A way to minimize the symptoms of this bug is to notice that most, if
not all, FILE structures are allocated inside libc. As long as libc code
controls the address of FILE objects, it can ensure 8-byte alignment,
even for the legacy structures. So my recommendation is:

1. keep not forcing old FILE* to be 8-byte-aligned

Forcing it would make the legacy function (versioned GLIBC_2.0) unable
to cope with (unaligned) objects they currently can cope with


2. do force 8-byte-alignment on the legacy stdin/stdout/stderr

This will make the legacy standard streams compatible with current code


3. do force 8-byte aligment on functions generating FILE structures
(like fopen), even in the legacy interface.

This will make all stream objects allocated in libc functions (which
probably will be all stream objects you encounter) compatible with
current code.


I am completely aware (as pointed out above) that this is not a perfect
fix, but it should be a good enough fix that no observable problems
occur, even if you mix libio 2.0 and libio 2.1 code.

And finally:
4. implement a lintian check that shared objects (programs and
libraries) importing any GLIBC_2.1 or later versioned symbol also
contain an *unversioned* export of _IO_stdin_used on those architectures
where libio 2.0-compatibility is enabled (for example i386, but not
amd64).

In my oppinion, this bug is definitely not release critical, because the
only thing that is broken is a compatiblity layer for programs more than
10 years old. This would count as "a particular option (or menu item)"
of libc6, furthermore not affecting the "core functionality of the
package". So the priority should be normal or minor.

A build process that mangles the export of _IO_stdin_used is (as defined
by the libc ABI, even if not explicitly written down) broken. The bug in
this case was caused by such a kind of broken build process in the
Mozilla applications that already has been fixed. We are still waiting
for a real manifestation of the original bug, which should occur with
libio 2.0 programs only.

Regards,
  Michael Karcher