Bug#634261: iceweasel 5.0 does not start on sparc, bus error
On Tue, Jul 19, 2011 at 06:15:31PM +0200, Mike Hommey wrote:
> On Tue, Jul 19, 2011 at 05:52:28PM +0200, Aurelien Jarno wrote:
> > On Mon, Jul 18, 2011 at 11:52:49AM +0200, Mike Hommey wrote:
> > > reassign 634261 libc6
> > > thanks
> > >
> > > On Mon, Jul 18, 2011 at 12:34:48PM +0300, Aleksi Suhonen wrote:
> > > > Package: iceweasel
> > > > Version: 5.0-3
> > > > Severity: grave
> > > >
> > > >
> > > > The new iceweasel fails to start on sparc64. It crashes before
> > > > it gets anywhere, so removing ~/.mozilla has no effect.
> > > > Here's some debugging output:
> > >
> > > Is that the sparc64 build or the sparc build?
> > >
> > > > (gdb) run
> > > > Starting program: /usr/lib/iceweasel/firefox-bin
> > > > [Thread debugging using libthread_db enabled]
> > > >
> > > > Program received signal SIGBUS, Bus error.
> > > > 0xf7d57718 in _IO_default_setbuf (fp=0xf7e57114, p=0x0, len=0) at genops.c:575
> > > > 575 genops.c: No such file or directory.
> > > > in genops.c
> > > > (gdb) bt
> > > > #0 0xf7d57718 in _IO_default_setbuf (fp=0xf7e57114, p=0x0, len=0)
> > > > at genops.c:575
> > > > #1 0xf7e161f4 in _IO_old_file_setbuf (fp=0xf7e57114, p=0x0, len=0)
> > > > at oldfileops.c:265
> > > > #2 0xf7d4ba68 in _IO_setbuffer (fp=0xf7e57114, buf=0x0,
> > > > size=<value optimized out>) at iosetbuffer.c:44
> > > > #3 0xf67d8e34 in XRE_main (argc=1, argv=0xffffda44, aAppData=0xf79347c0)
> > > > at ../../../toolkit/xre/nsAppRunner.cpp:2780
> > >
> > > Note this line is:
> > > SetupErrorHandling(argv[0]);
> > >
> > > which actually does:
> > > setbuf(stdout, 0);
> > >
> > > So the top frames are in the libc. That suggests a serious problem with the libc.
> > >
> >
> > The problem is caused by the following code (genops.c:575):
> >
> > fp->_IO_write_base = fp->_IO_write_ptr = fp->_IO_write_end = 0;
> >
> > Translated by the compiler into:
> >
> > 0xf7d57714 <+148>: clr [ %i0 + 0x18 ]
> > 0xf7d57718 <+152>: clrx [ %i0 + 0x10 ]
> >
> > In other words by a 32-bit access and a 64-bit access. The compiler is
> > allowed on sparc, as malloc is guaranteed to return 8-byte memory.
> >
> > The thing I still don't understand here, is why fp = stdout = 0xf7e57114
> > is not aligned. fopen() is using malloc() internally, so the resulting
> > pointer should be aligned. Does iceweasel play with the alignment in a
> > bad way there?
>
> I don't expect it to, especially with stdout, and especially during
> startup (the crash is in the very startup, not a lot of iceweasel is
> initialized). And stdout is a symbol exported from libc.so.6.
FYI, I found that it is triggered by the _IO_stdin_used symbol not being
exported from the binary, which happened because of a version-script
couple with -rdynamic. I still think there is something fishy going on
on the libc6 side, but not as bad as originally thought.
Mike
Reply to: