Red Hat Bugzilla – Bug 202152
buffer overflow detected while starting gnome
Last modified: 2008-08-02 19:40:32 EDT
After a yum update to 20060810's stuff, I am no longer ablel to start GNOME on my G5. I am getting the
attached backtrace from every program that starts, so I assume this is not just gnome-panel's fault, but
some underlying library that everything is using. Please reassign as appropriate, as I don't know which
desktop-related component is to blame (I'm sure you feel the same way about installer stuff). The result
is a huge cycle of bug-buddy and gnome_sigsegv processes. This also happens if I attempt to start XFCE.
Perhaps more font goofiness, as I have had font goofiness on this machine in the past.
Created attachment 134001 [details]
So this FcCacheMachineSignature function looks a little fishy
i'm building a new package into rawhide that may fix this issue.
If it doesn't, i'd appreciate if you could do one or more of the following
1) install fontconfig-debuginfo and get a better backtrace from gdb
2) downgrade kernels and tell me if the problem vanishes
3) run a program that crashes through valgrind --tool=memcheck and see what it
Created attachment 134032 [details]
overflow patch that was built
Also, i taked a bit with Uli on IRC, and he suggested you attach the output of
so that we can see what sysconf (_SC_PAGE_SIZE) would return.
Ray, your patch hides any problem. I suggest you check that the signature is
correctly terminated by '\n' and otherwise print a warning.
well, with my patch the \n will always be there.
The patch definitely isn't right though. It will put 0000 for the page size
actually. we should probably clamp the pagesize to ffff.
Created attachment 134036 [details]
patch take 2
Created attachment 134041 [details]
So I talked with Behdad a bit on irc. The strings contents aren't that
important. It's just used to generate a unique key from a machine type. by
removing the space in between the last two parts of the string we can support
64k page sizes fine.
This is much better in the build I pulled from brew just now. Thanks.
Just had this conversation with keithp:
[13:46:24] <halfline> keithp: can you roll in
https://bugs.freedesktop.org/show_bug.cgi?id=7936 to your changes ?
[13:46:53] <keithp> halfline: already fixed
[13:47:09] <keithp> architecture detection is done at build time now
[13:47:34] <keithp> halfline: if you can, please attempt a build of
fc-2_4-keithp and send me the failure output
[13:48:50] <keithp> halfline: that would be cool; I need to have a list of all
prospective architectures for the autodetection code to work right
[13:49:30] <halfline> okay, i'll ping him about it
[13:49:51] <keithp> halfline: fc-2_4-keithp :-)
So would you mind doing a
yum -y install git-core
and then giving the output of the fc-arch failure?
./fc-arch auto < ../fc-arch/fcarch.tmpl.h > fcarch.h
./fc-arch: unknown signature
Please update fcarch.tmpl.h and rebuild
Could you suggest a short name for this architecture?
How does this differ from a ppc with 4k pages? Different CPU or just a different
configuration? It's not a 64-bit CPU, so ppc64 doesn't make a lot of sense, but
perhaps ppc-64k would. And should we call a 4k page version ppc-4k?
No, Chris is running on a 64-bit powerpc machine (with 64k page size).
Note there are (mostly) 64-bit ppc machines out there with 4k page size, just
not recent rawhide.
that doesn't jive with the signature output above; the first 00000004 is sizeof
(char *) for the machine. It looks like a 32-bit PPC with 64k pages to me.
Oh right, it is a ppc64 machine, but in Fedora we only run a 64-bit kernel. Most
userspace apps are 32-bit by default.
Note we do have build environments without multilib packages that do run 64-bit
So i guess you'll need entries for
ppc-64k, ppc64-64k, ppc-4k, ppc64-4k (the last one for other distros, not rawhide)