Bug#625522: glibc: causes segfault in Xorg
Aurelien Jarno wrote: Le 04/05/2011 07:43, Jonathan Nieder a écrit : Jonathan Nieder wrote: Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518 which is fixed (sort of) by commit 0354e355 (2011-04-01). Are you sure this is related? I find strange a recent version of xorg is still not fixed No, not sure --- I was only reminded. But it does fit the symptoms well: regression occuring when upgrading to glibc 2.13, consisting of a segfault in memcpy_sse3. (As you suggested) it might be specific to some driver or some aspect of the configuration. The easiest way to confirm would be with valgrind. No, it's not something possible to cherry-pick as it is based on symbol versioning from version 2.14. Also it only really apply to binary-only distribution, in Debian as soon as your rebuild the package, it will use the new 2.14 symbols, and memcpy instead of memmove. That sounds great --- it would take care of upgrades from broken packages in squeeze and as soon as you rebuild a package, there is a chance to fix it. I imagine the release team wouldn't like it much, though. I don't think we can really keep a version in experimental just for that. And reverting that patch means nobody will complain, and issues will never be fixed. Reverting may be the best way in the short term, especially if the upstream fix is four months away. I suppose Steve was right to ask for help on -devel. Maybe someone will come up with a better idea. E.g., how about adopting hjl's suggestion and making the behavior (temporarily) conditional on a LD_DONT_BIND_IFUNC_MEMCPY_TO_MEMMOVE environment variable? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504070503.GA10230@elie
Re: glibc: causes segfault in Xorg
Hi, Michel Dänzer wrote: On Mit, 2011-05-04 at 00:10 -0500, Jonathan Nieder wrote: Steve M. Robbins wrote: Program received signal SIGSEGV, Segmentation fault. __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153 153 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory. in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S (gdb) bt #0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153 #1 0x73858db1 in shadowUpdatePacked () from /usr/lib/xorg/modules/libshadow.so #2 0x7385843f in ?? () from /usr/lib/xorg/modules/libshadow.so #3 0x0043571d in BlockHandler () #4 0x0045dcda in WaitForSomething () #5 0x004314b2 in ?? () #6 0x004257de in _start () [...] The purpose of shadowUpdatePacked is to copy pixels from a shadow framebuffer to the visible screen. It would be rather pointless for the shadow framebuffer to be contained within the visible screen, so shadowUpdatePacked should always be able to safely use memcpy as far as overlapping areas is concerned. If shadowUpdatePacked is indeed calling memcpy for overlapping areas here, that's probably a bug in the X driver being used. Thanks, Michel. Steve, could you install xserver-xorg-video-radeon-dbg and get a full backtrace (bt full), or even better, run xorg under valgrind and see what it says? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504071834.GB10230@elie
Re: glibc: causes segfault in Xorg
On Mit, 2011-05-04 at 02:18 -0500, Jonathan Nieder wrote: Michel Dänzer wrote: On Mit, 2011-05-04 at 00:10 -0500, Jonathan Nieder wrote: Steve M. Robbins wrote: Program received signal SIGSEGV, Segmentation fault. __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153 153 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory. in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S (gdb) bt #0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153 #1 0x73858db1 in shadowUpdatePacked () from /usr/lib/xorg/modules/libshadow.so #2 0x7385843f in ?? () from /usr/lib/xorg/modules/libshadow.so #3 0x0043571d in BlockHandler () #4 0x0045dcda in WaitForSomething () #5 0x004314b2 in ?? () #6 0x004257de in _start () [...] The purpose of shadowUpdatePacked is to copy pixels from a shadow framebuffer to the visible screen. It would be rather pointless for the shadow framebuffer to be contained within the visible screen, so shadowUpdatePacked should always be able to safely use memcpy as far as overlapping areas is concerned. If shadowUpdatePacked is indeed calling memcpy for overlapping areas here, that's probably a bug in the X driver being used. Thanks, Michel. Steve, could you install xserver-xorg-video-radeon-dbg [...] More importantly xserver-xorg-core-dbg, to get debugging symbols for /usr/lib/xorg/modules/libshadow.so . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304494193.5633.404.camel@thor.local
Re: glibc: causes segfault in Xorg
On Mit, 2011-05-04 at 02:18 -0500, Jonathan Nieder wrote: Michel Dänzer wrote: On Mit, 2011-05-04 at 00:10 -0500, Jonathan Nieder wrote: Steve M. Robbins wrote: Program received signal SIGSEGV, Segmentation fault. __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153 153 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory. in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S (gdb) bt #0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153 #1 0x73858db1 in shadowUpdatePacked () from /usr/lib/xorg/modules/libshadow.so #2 0x7385843f in ?? () from /usr/lib/xorg/modules/libshadow.so #3 0x0043571d in BlockHandler () #4 0x0045dcda in WaitForSomething () #5 0x004314b2 in ?? () #6 0x004257de in _start () [...] The purpose of shadowUpdatePacked is to copy pixels from a shadow framebuffer to the visible screen. It would be rather pointless for the shadow framebuffer to be contained within the visible screen, so shadowUpdatePacked should always be able to safely use memcpy as far as overlapping areas is concerned. If shadowUpdatePacked is indeed calling memcpy for overlapping areas here, that's probably a bug in the X driver being used. Thanks, Michel. Steve, could you install xserver-xorg-video-radeon-dbg and get a full backtrace (bt full), or even better, run xorg under valgrind and see what it says? Actually, looking at the Xorg.0.log file, there's no mention of the radeon driver at all, it's using the fbdev driver: [ 3604.046] (II) FBDEV(0): hardware: radeondrmfb (video memory: 9000kB) [ 3604.046] (II) FBDEV(0): checking modes against framebuffer device... [ 3604.046] (II) FBDEV(0): checking modes against monitor... [ 3604.046] (--) FBDEV(0): Virtual size is 3200x1200 (pitch 3200) And the numbers don't seem to add up, 3200x1200 would require almost 15M of VRAM. Steve, can you provide the output of fbset -i and the /etc/X11/xorg.conf file as well? Any reason for not using the radeon driver? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304496527.5633.409.camel@thor.local
Re: Bug#625521: glibc: causes segfault in Xorg
Michel Dänzer daen...@debian.org (04/05/2011): More importantly xserver-xorg-core-dbg, to get debugging symbols for /usr/lib/xorg/modules/libshadow.so . If fbdev is indeed used (see Michel's other mail about that), rebuilding it with debugging symbols would be nice. AFAICT from a quick grep, the entry point to shadowUpdate*Packed would be through: | src/fbdev.c: shadowUpdateRotatePackedWeak() : shadowUpdatePackedWeak(), in the driver, leading to that in the server: | miext/shadow/shpacked.c:shadowUpdatePacked [Weak or not] or | miext/shadow/shrotate.c:shadowUpdateRotatePacked [Weak or not] Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#625521: glibc: causes segfault in Xorg
On Mit, 2011-05-04 at 11:08 +0200, Cyril Brulebois wrote: Michel Dänzer daen...@debian.org (04/05/2011): More importantly xserver-xorg-core-dbg, to get debugging symbols for /usr/lib/xorg/modules/libshadow.so . If fbdev is indeed used (see Michel's other mail about that), rebuilding it with debugging symbols would be nice. AFAICT from a quick grep, the entry point to shadowUpdate*Packed would be through: | src/fbdev.c: shadowUpdateRotatePackedWeak() : shadowUpdatePackedWeak(), Those are just callback pointers passed to shadowAdd(). The driver doesn't call shadowUpdatePacked() directly (in fact you'll note the backtrace doesn't have any frames belonging to the driver), but the shadow layer is only used as set up by the driver. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304500485.5633.412.camel@thor.local
Re: Bug#625521: glibc: causes segfault in Xorg
Michel Dänzer daen...@debian.org (04/05/2011): Those are just callback pointers passed to shadowAdd(). The driver doesn't call shadowUpdatePacked() directly (in fact you'll note the backtrace doesn't have any frames belonging to the driver), but the shadow layer is only used as set up by the driver. Alright. Wasn't sure whether that was a somewhat broken backtrace with missing stuff, or something else. Thanks for the clarification. Mraw, KiBi. signature.asc Description: Digital signature
Bug#625522: glibc: causes segfault in Xorg
Le 04/05/2011 09:05, Jonathan Nieder a écrit : Aurelien Jarno wrote: Le 04/05/2011 07:43, Jonathan Nieder a écrit : Jonathan Nieder wrote: Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518 which is fixed (sort of) by commit 0354e355 (2011-04-01). Are you sure this is related? I find strange a recent version of xorg is still not fixed No, not sure --- I was only reminded. But it does fit the symptoms well: regression occuring when upgrading to glibc 2.13, consisting of a segfault in memcpy_sse3. (As you suggested) it might be specific to some driver or some aspect of the configuration. The easiest way to confirm would be with valgrind. No, it's not something possible to cherry-pick as it is based on symbol versioning from version 2.14. Also it only really apply to binary-only distribution, in Debian as soon as your rebuild the package, it will use the new 2.14 symbols, and memcpy instead of memmove. That sounds great --- it would take care of upgrades from broken packages in squeeze and as soon as you rebuild a package, there is a chance to fix it. Except that package rebuild doesn't mean a new upload (e.g binNMUs). I imagine the release team wouldn't like it much, though. I don't think we can really keep a version in experimental just for that. And reverting that patch means nobody will complain, and issues will never be fixed. Reverting may be the best way in the short term, especially if the upstream fix is four months away. I suppose Steve was right to ask for help on -devel. Maybe someone will come up with a better idea. I am not convinced that the upstream fix is really the solution. As soon as the package is rebuild, the problem will happen again. E.g., how about adopting hjl's suggestion and making the behavior (temporarily) conditional on a LD_DONT_BIND_IFUNC_MEMCPY_TO_MEMMOVE environment variable? I don't really feel like enabling critical features depending on an environment variable that might not be properly propagated in some shell scripts. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc1292a.6010...@aurel32.net
Bug#617759: icedove: symbol lookup error: /usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc
Jonathan Nieder wrote:
$ icedove; echo $?
/usr/lib/icedove/icedove-bin: symbol lookup error:
/usr/lib/icedove/components/libdbusservice.so: undefined symbol: NS_Alloc
127
Backtrace:
#0 _dl_signal_cerror (errcode=0, objname=0x7fffe6e70640
/usr/lib/icedove/components/libdbusservice.so,
occation=0x77df6f03 symbol lookup error, errstring=0x7fffd690
undefined symbol: NS_Alloc)
at dl-error.c:138
#1 0x77de7187 in _dl_lookup_symbol_x (undef_name=value optimized
out,
undef_map=value optimized out, ref=0x7fffd7f8, symbol_scope=value
optimized out,
version=value optimized out, type_class=value optimized out, flags=5,
skip_map=0x0) at dl-lookup.c:779
#2 0x77dea782 in _dl_fixup (l=value optimized out, reloc_arg=value
optimized out)
at ../elf/dl-runtime.c:118
#3 0x77df0635 in _dl_runtime_resolve () at
../sysdeps/x86_64/dl-trampoline.S:41
#4 0x7fffdc294430 in Alloc (this=0x7fffe6efa8a0,
aContractID=0x7fffd928) at nsMemory.h:68
#5 nsGenericFactory::GetContractID (this=0x7fffe6efa8a0,
aContractID=0x7fffd928)
at nsGenericFactory.cpp:115
#6 0x779520fc in ClassIDWriter (table=value optimized out,
hdr=value optimized out,
number=value optimized out, arg=value optimized out) at
nsComponentManager.cpp:1137
#7 0x779270d0 in PL_DHashTableEnumerate (table=0x706eb1a8,
etor=0x7795202d ClassIDWriter(PLDHashTable*, PLDHashEntryHdr*,
PRUint32, void*), arg=0x7fffda90)
at pldhash.c:754
#8 0x779523d7 in nsComponentManagerImpl::WritePersistentRegistry
(this=0x706eb160)
at nsComponentManager.cpp:1246
#9 0x7795513b in nsComponentManagerImpl::AutoRegister
(this=0x706eb160, aSpec=0x0)
at nsComponentManager.cpp:3469
#10 0x77930163 in NS_InitXPCOM3_P (result=value optimized out,
binDirectory=value optimized out,
appFileLocationProvider=value optimized out, staticComponents=value
optimized out,
componentCount=value optimized out) at nsXPComInit.cpp:773
#11 0x77bc34c7 in ScopedXPCOMStartup::Initialize (this=0x7fffe580)
at nsAppRunner.cpp:1119
#12 0x77bc650d in XRE_main (argc=value optimized out, argv=value
optimized out,
aAppData=value optimized out) at nsAppRunner.cpp:3283
#13 0x0040184b in main (argc=1, argv=0x7fffe808) at
nsMailApp.cpp:101
bt full output attached.
#0 _dl_signal_cerror (errcode=0, objname=0x7fffe6e70640
/usr/lib/icedove/components/libdbusservice.so,
occation=0x77df6f03 symbol lookup error, errstring=0x7fffd690
undefined symbol: NS_Alloc)
at dl-error.c:138
No locals.
#1 0x77de7187 in _dl_lookup_symbol_x (undef_name=value optimized
out,
undef_map=value optimized out, ref=0x7fffd7f8, symbol_scope=value
optimized out,
version=value optimized out, type_class=value optimized out, flags=5,
skip_map=0x0) at dl-lookup.c:779
reference_name = 0x7fffe6e70640
/usr/lib/icedove/components/libdbusservice.so
versionstr = 0x77df6a53
versionname = 0x77df6a53
old_hash = 4294967295
current_value = {s = 0x0, m = 0x0}
scope = value optimized out
__PRETTY_FUNCTION__ = _dl_lookup_symbol_x
i = value optimized out
protected = value optimized out
#2 0x77dea782 in _dl_fixup (l=value optimized out, reloc_arg=value
optimized out)
at ../elf/dl-runtime.c:118
version = 0xfefefefefefefeff
flags = 5
reloc = value optimized out
sym = 0x7fffdc291538
result = value optimized out
value = value optimized out
__PRETTY_FUNCTION__ = _dl_fixup
#3 0x77df0635 in _dl_runtime_resolve () at
../sysdeps/x86_64/dl-trampoline.S:41
No locals.
#4 0x7fffdc294430 in Alloc (this=0x7fffe6efa8a0,
aContractID=0x7fffd928) at nsMemory.h:68
No locals.
#5 nsGenericFactory::GetContractID (this=0x7fffe6efa8a0,
aContractID=0x7fffd928)
at nsGenericFactory.cpp:115
No locals.
#6 0x779520fc in ClassIDWriter (table=value optimized out,
hdr=value optimized out,
number=value optimized out, arg=value optimized out) at
nsComponentManager.cpp:1137
factoryEntry = 0x7fffe6e7a690
fd = 0x7fffe6e70d30
cidString = {75a500a2-0030-40f7-86f8-63f225b940ae}
className = 0x0
loaderName = value optimized out
loaderData = 0x706eb2b0
contractID = 0x0
classInfo = {nsCOMPtr_base = {mRawPtr = 0x7fffe6efa8a8}, No data
fields}
location = value optimized out
#7 0x779270d0 in PL_DHashTableEnumerate (table=0x706eb1a8,
etor=0x7795202d ClassIDWriter(PLDHashTable*, PLDHashEntryHdr*,
PRUint32, void*), arg=0x7fffda90)
at pldhash.c:754
entryAddr = value optimized out
entryLimit = 0x7fffe6e84000 \030,\355\367\377\177
i = 128
capacity = 2048
entrySize = 16
ceiling = value optimized out
didRemove
Bug#625522: glibc: causes segfault in Xorg
Aurelien Jarno wrote: Except that package rebuild doesn't mean a new upload (e.g binNMUs). Yes, it would be painful if many packages have bugs of this kind. Open source projects tend to check for this (and I've never run into it after using libc 2.13 for a while) but I could easily be underestimating how bad it is. What I meant is that packages rebuilt against libc from sid are generally targetted at wheezy. That would (one hopes) give a little time to test and fix them. I am not convinced that the upstream fix is really the solution. As soon as the package is rebuild, the problem will happen again. I think it's mostly meant as a workaround to allow people to keep using Flash and old binaries. Another big downside is making almost everything depend on libc6 (= 2.14). Binaries built against glibc with the upstream fix wouldn't be usable on older systems. Le 04/05/2011 09:05, Jonathan Nieder a écrit : E.g., how about adopting hjl's suggestion and making the behavior (temporarily) conditional on a LD_DONT_BIND_IFUNC_MEMCPY_TO_MEMMOVE environment variable? I don't really feel like enabling critical features depending on an environment variable that might not be properly propagated in some shell scripts. I'm not a huge fan of the envvar trick, but I think you read it backwards. Unlike hjl in the bug log, I was suggesting using the safe behavior when the envvar is not set. At worst a script using sudo or env -i would cause programs it calls to use memmove instead of memcpy. Unfortunately I fear testers would be unlikely to actually use such a variable. Even MALLOC_PERTURB_ is not as widely used as one would like, judging from the bugs it sometimes uncovers. So yes, back to the drawing board. Thanks for your thoughtfulness. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504120231.GA9919@elie
Bug#625522: glibc: causes segfault in Xorg
Le 04/05/2011 14:02, Jonathan Nieder a écrit : Aurelien Jarno wrote: Except that package rebuild doesn't mean a new upload (e.g binNMUs). Yes, it would be painful if many packages have bugs of this kind. Open source projects tend to check for this (and I've never run into it after using libc 2.13 for a while) but I could easily be underestimating how bad it is. What I meant is that packages rebuilt against libc from sid are generally targetted at wheezy. That would (one hopes) give a little time to test and fix them. I am not convinced that the upstream fix is really the solution. As soon as the package is rebuild, the problem will happen again. I think it's mostly meant as a workaround to allow people to keep using Flash and old binaries. Another big downside is making almost everything depend on libc6 (= 2.14). Binaries built against glibc with the upstream fix wouldn't be usable on older systems. Le 04/05/2011 09:05, Jonathan Nieder a écrit : E.g., how about adopting hjl's suggestion and making the behavior (temporarily) conditional on a LD_DONT_BIND_IFUNC_MEMCPY_TO_MEMMOVE environment variable? I don't really feel like enabling critical features depending on an environment variable that might not be properly propagated in some shell scripts. I'm not a huge fan of the envvar trick, but I think you read it backwards. Unlike hjl in the bug log, I was suggesting using the safe behavior when the envvar is not set. At worst a script using sudo or env -i would cause programs it calls to use memmove instead of memcpy. Unfortunately I fear testers would be unlikely to actually use such a variable. Even MALLOC_PERTURB_ is not as widely used as one would like, judging from the bugs it sometimes uncovers. So yes, back to the drawing board. Thanks for your thoughtfulness. I have tried to play a bit with some test codes. I have discovered that even with old memcpy() implementation, it's not always possible to have code that overlap. What changes with the new memcpy_ssse3 is that the the copy happens backward, so the conditions are not the same. It means that if we simply replace memcpy() by memmove(), people might write code that works well with the new libc, but doesn't work on old libc (or even worse depending on how other distributions have chosen to workaround this bug, if they chose to do so). It doesn't seems to be a good idea, especially for people using Debian as a development platform. Basically it seems we only want to replace calls to __memcpy_ssse3_back by calls to __memmove_ssse3_back. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc15537.8040...@aurel32.net
Bug#625616: libc6: Reproducible crash when allocating in a static constructor
Package: libc6
Version: 2.13-2
Severity: important
The following program crashes before executing main(). It is 100%
reproducible.
On a debian unstable machine updated one month ago, the crash did not
appear. The culprit is not gcc, since when compiling right now this
program with gcc 4.5 and 4.4, the crash still appears. I am not sure
that libc6 is the culprit, or another related library (such as binutils).
$ cat test.cxx
#include iostream
#include ext/bitmap_allocator.h
class Hello
{
public:
Hello ()
{}
~Hello ()
{}
void act ()
{ std::cout Hello, world! std::endl; }
};
static void __attribute__ (( constructor )) PWLIB_StaticLoader() { \
__gnu_cxx::bitmap_allocatorHello allocator; \
Hello* salut = allocator._M_allocate_single_object (); \
salut-act (); \
}
int
main (int /*argc*/,
char* /*argv*/[])
{
return 0;
}
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libc-bin 2.13-2 Embedded GNU C Library:
Binaries
ii libgcc1 1:4.6.0-6 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.39 Debian configuration
management sy
pn glibc-doc none (no description available)
ii locales 2.13-2 Embedded GNU C Library:
National L
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc16beb.5000...@pu-pm.univ-fcomte.fr
WikiGroups
To see the web version of this message click here: http://www.magnetmail.net/actions/email_web_version.cfm?recipient_id=715416346message_id=1344737user_id=ISC_ Wednesday, May 4, 2011 Dear Supporter of Group Activities, Groups have and always will be a very fundamental, constructive, and active part of our society. Unfortunately even today there is a lack of an online platform that is specifically designed for and focused on group and organization activity. Thus, the WikiGroups Project was born. WikiGroups is building a future where: People can easily locate, join and connect with groups. People can easily establish and market a group. Groups can build the right context (like a group office) to facilitate group communications and activities; Groups can allocate members and resources into sub-spaces to support exclusive member communications and activities; and Groups can easily create, launch and manage public and internal campaigns. To that effort we are inviting you to be one of WikiGroups' Charter Members on behalf of your group or organization. As such, you will receive priority SpaceName registration to ensure others don't take the name you want in the future. Please visit http://www.WikiGroups.org and click Join, to experience possibilities only enabled by the powerful Group OS it was designed in. Sincerely, Frederic Sheu Director, WikiGroups Institute for Content Activity Science Engineering Email: fs...@wikigroups.org ** 5001 Birch Street, Newport Beach, CA 92660 ** Use this link to unsubscribe: http://www.magnetmail.net/Actions/unsubscribe.cfm?message_id=1344737user_id=ISC_recipient_id=715416346email=debian-glibc@lists.debian.orggroup_id=637178
Bug#625616: libc6: Reproducible crash when allocating in a static constructor
reassign 625616 binutils
thanks
Le 04/05/2011 17:08, Eugen Dedu a écrit :
Package: libc6
Version: 2.13-2
Severity: important
The following program crashes before executing main(). It is 100%
reproducible.
On a debian unstable machine updated one month ago, the crash did not
appear. The culprit is not gcc, since when compiling right now this
program with gcc 4.5 and 4.4, the crash still appears. I am not sure
that libc6 is the culprit, or another related library (such as binutils).
The problem is also reproducible with both libc6 2.11 and 2.13. On the
other hand it is reproducible with binutils = 2.21.51.20110403-1 but
not with binutils = binutils_2.21.0.20110327-3. It is therefore most
likely a binutils issue, reassigning.
$ cat test.cxx
#include iostream
#include ext/bitmap_allocator.h
class Hello
{
public:
Hello ()
{}
~Hello ()
{}
void act ()
{ std::cout Hello, world! std::endl; }
};
static void __attribute__ (( constructor )) PWLIB_StaticLoader() { \
__gnu_cxx::bitmap_allocatorHello allocator; \
Hello* salut = allocator._M_allocate_single_object (); \
salut-act (); \
}
int
main (int /*argc*/,
char* /*argv*/[])
{
return 0;
}
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libc-bin 2.13-2 Embedded GNU C Library:
Binaries
ii libgcc1 1:4.6.0-6 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.39 Debian configuration
management sy
pn glibc-doc none (no description available)
ii locales 2.13-2 Embedded GNU C Library:
National L
-- debconf information excluded
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc17b3f.9010...@aurel32.net
Processed: Re: Bug#625616: libc6: Reproducible crash when allocating in a static constructor
Processing commands for cont...@bugs.debian.org: reassign 625616 binutils Bug #625616 [libc6] libc6: Reproducible crash when allocating in a static constructor Bug reassigned from package 'libc6' to 'binutils'. Bug No longer marked as found in versions eglibc/2.13-2. thanks Stopping processing here. Please contact me if you need assistance. -- 625616: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625616 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130452564230883.transcr...@bugs.debian.org
r4640 - in glibc-package/trunk/debian: . patches/any
Author: aurel32 Date: 2011-05-04 17:54:36 + (Wed, 04 May 2011) New Revision: 4640 Modified: glibc-package/trunk/debian/changelog glibc-package/trunk/debian/patches/any/local-no-pagesize.diff Log: * patches/any/local-no-pagesize.diff: use __sysconf() instead of sysconf(). Modified: glibc-package/trunk/debian/changelog === --- glibc-package/trunk/debian/changelog2011-05-02 18:20:00 UTC (rev 4639) +++ glibc-package/trunk/debian/changelog2011-05-04 17:54:36 UTC (rev 4640) @@ -1,3 +1,10 @@ +eglibc (2.13-3) UNRELEASED; urgency=low + + * patches/any/local-no-pagesize.diff: use __sysconf() instead of +sysconf(). + + -- Aurelien Jarno aure...@debian.org Wed, 04 May 2011 19:53:33 +0200 + eglibc (2.13-2) unstable; urgency=low [ Aurelien Jarno ] Modified: glibc-package/trunk/debian/patches/any/local-no-pagesize.diff === --- glibc-package/trunk/debian/patches/any/local-no-pagesize.diff 2011-05-02 18:20:00 UTC (rev 4639) +++ glibc-package/trunk/debian/patches/any/local-no-pagesize.diff 2011-05-04 17:54:36 UTC (rev 4640) @@ -19,7 +19,7 @@ }; -#define NBPG PAGE_SIZE -+#define NBPG (sysconf(_SC_PAGESIZE)) ++#define NBPG (__sysconf(_SC_PAGESIZE)) #define UPAGES1 #define HOST_TEXT_START_ADDR (u.start_code) #define HOST_DATA_START_ADDR (u.start_data) @@ -39,7 +39,7 @@ -#define PAGE_SHIFT12 -#define PAGE_SIZE (1UL PAGE_SHIFT) -+#define PAGE_SIZE (sysconf(_SC_PAGESIZE)) ++#define PAGE_SIZE (__sysconf(_SC_PAGESIZE)) #define PAGE_MASK (~(PAGE_SIZE-1)) #define NBPG PAGE_SIZE #define UPAGES1 @@ -59,7 +59,7 @@ -#define PAGE_SHIFT12 -#define PAGE_SIZE (1UL PAGE_SHIFT) -+#define PAGE_SIZE (sysconf(_SC_PAGESIZE)) ++#define PAGE_SIZE (__sysconf(_SC_PAGESIZE)) #define PAGE_MASK (~(PAGE_SIZE-1)) #define NBPG PAGE_SIZE #define UPAGES1 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qhghw-0006oe...@alioth.debian.org
Processed: Re: Bug#625607: Backtrace…
Processing commands for cont...@bugs.debian.org: reassign 625607 libc6 2.13-1 Bug #625607 [cmake] cmake: Segfaults on sparc Bug reassigned from package 'cmake' to 'libc6'. Bug No longer marked as found in versions cmake/2.8.4+dfsg.1-2. Bug #625607 [libc6] cmake: Segfaults on sparc Bug Marked as found in versions eglibc/2.13-1. affects 625607 cmake Bug #625607 [libc6] cmake: Segfaults on sparc Removed indication that 625607 affects shiboken Added indication that 625607 affects cmake thanks Stopping processing here. Please contact me if you need assistance. -- 625607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13045478417762.transcr...@bugs.debian.org
Processed: affects 625607
Processing commands for cont...@bugs.debian.org: affects 625607 src:libvigraimpex Bug #625607 [libc6] cmake: Segfaults on sparc Removed indication that 625607 affects cmake Added indication that 625607 affects src:libvigraimpex thanks Stopping processing here. Please contact me if you need assistance. -- 625607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13045478777957.transcr...@bugs.debian.org
Processed: affects 625607
Processing commands for cont...@bugs.debian.org: affects 625607 src:shiboken Bug #625607 [libc6] cmake: Segfaults on sparc Removed indication that 625607 affects src:libvigraimpex Added indication that 625607 affects src:shiboken thanks Stopping processing here. Please contact me if you need assistance. -- 625607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13045482799162.transcr...@bugs.debian.org
Processed: affects 625607
Processing commands for cont...@bugs.debian.org: affects 625607 src:libreoffice Bug #625607 [libc6] cmake: Segfaults on sparc Removed indication that 625607 affects src:shiboken Added indication that 625607 affects src:libreoffice thanks Stopping processing here. Please contact me if you need assistance. -- 625607: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625607 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130454969913787.transcr...@bugs.debian.org
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 09:29:53AM +0200, Michel Dänzer wrote:
On Mit, 2011-05-04 at 02:18 -0500, Jonathan Nieder wrote:
Thanks, Michel. Steve, could you install xserver-xorg-video-radeon-dbg
[...]
More importantly xserver-xorg-core-dbg, to get debugging symbols
for /usr/lib/xorg/modules/libshadow.so .
OK, I've installed both -dbg packages and here's the backtrace
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/X...(no debugging symbols found)...done.
(gdb) set args :0
(gdb) run
Starting program: /usr/bin/X :0
process 14244 is executing new program: /usr/bin/Xorg
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153
in ../sysdeps/x86_64/multiarch/memcpy-ssse3.S
(gdb) bt full
#0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:153
No locals.
#1 0x7faa64837db1 in shadowUpdatePacked (pScreen=0x2502620,
pBuf=0x2503b40) at ../../../miext/shadow/shpacked.c:105
damage = 0x2503bb0
pShadow = value optimized out
nbox = 0
pbox = value optimized out
shaBase = 0x7faa5ca3b010
sha = value optimized out
shaStride = 3200
scrBase = 1920
scrLine = 0
scr = 3200
shaBpp = 32
shaXoff = value optimized out
shaYoff = value optimized out
x = value optimized out
y = value optimized out
w = 3200
h = value optimized out
width = 0
i = 1280
winBase = 0x7faa64836000
win = value optimized out
winSize = 1920
#2 0x7faa6483743f in shadowRedisplay (pScreen=0x2502620) at
../../../miext/shadow/shadow.c:61
pBuf = 0x2503b40
pRegion = value optimized out
#3 0x0043571d in BlockHandler (pTimeout=0x7fff82b25f58,
pReadmask=0x7eda40) at ../../dix/dixutils.c:389
i = value optimized out
j = value optimized out
#4 0x0045dcda in WaitForSomething (pClientsReady=0x28b86a0) at
../../os/WaitFor.c:219
i = value optimized out
waittime = {tv_sec = 600, tv_usec = 0}
wt = 0x7fff82b25f40
timeout = value optimized out
clientsReadable = {fds_bits = {0 repeats 16 times}}
clientsWritable = {fds_bits = {1712, 450971566080, 1, 42696624,
42791104, 42698352, 140369853046400, 1760, 14272, 140369849872147, 192,
140369853046400, 42696640, 1740,
42696624, 1760}}
selecterr = value optimized out
nready = 0
devicesReadable = {fds_bits = {140733193388033, 42791312,
140369853046400, 42791472, 140369853046400, 1680, 304, 140369849859444, 0,
140369882633504, 1680,
140369853046488, 140369853046504, 1, 1665, 317831862540}}
now = value optimized out
someReady = value optimized out
#5 0x004314b2 in Dispatch () at ../../dix/dispatch.c:367
clientReady = 0x28b86a0
result = value optimized out
client = value optimized out
nready = value optimized out
icheck = 0x7eca70
start_tick = value optimized out
#6 0x004257de in main (argc=2, argv=value optimized out, envp=value
optimized out) at ../../dix/main.c:287
i = value optimized out
alwaysCheckForInput = {0, 1}
(gdb) quit
A debugging session is active.
Inferior 1 [process 14244] will be killed.
Quit anyway? (y or n)
signature.asc
Description: Digital signature
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 02:18:35AM -0500, Jonathan Nieder wrote: Thanks, Michel. Steve, could you install xserver-xorg-video-radeon-dbg and get a full backtrace (bt full), or even better, run xorg under valgrind and see what it says? OK, I ran valgrind Xorg; note that valgrind was not exiting so I used ^C after approx 10 seconds. ==14381== Memcheck, a memory error detector ==14381== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==14381== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==14381== Command: Xorg :0 ==14381== Parent PID: 13550 ==14381== ==14381== Conditional jump or move depends on uninitialised value(s) ==14381==at 0x4016466: index (strchr.S:56) ==14381==by 0x400720A: expand_dynamic_string_token (dl-load.c:324) ==14381==by 0x400761F: _dl_map_object (dl-load.c:2182) ==14381==by 0x400185D: map_doit (rtld.c:636) ==14381==by 0x400D965: _dl_catch_error (dl-error.c:178) ==14381==by 0x4001776: do_preload (rtld.c:820) ==14381==by 0x4004474: dl_main (rtld.c:1705) ==14381==by 0x401499D: _dl_sysdep_start (dl-sysdep.c:244) ==14381==by 0x4001422: _dl_start (rtld.c:341) ==14381==by 0x4000AF7: ??? (in /lib/ld-2.13.so) ==14381==by 0x1: ??? ==14381==by 0x7FF000CC6: ??? ==14381== ==14381== Conditional jump or move depends on uninitialised value(s) ==14381==at 0x401646B: index (strchr.S:59) ==14381==by 0x400720A: expand_dynamic_string_token (dl-load.c:324) ==14381==by 0x400761F: _dl_map_object (dl-load.c:2182) ==14381==by 0x400185D: map_doit (rtld.c:636) ==14381==by 0x400D965: _dl_catch_error (dl-error.c:178) ==14381==by 0x4001776: do_preload (rtld.c:820) ==14381==by 0x4004474: dl_main (rtld.c:1705) ==14381==by 0x401499D: _dl_sysdep_start (dl-sysdep.c:244) ==14381==by 0x4001422: _dl_start (rtld.c:341) ==14381==by 0x4000AF7: ??? (in /lib/ld-2.13.so) ==14381==by 0x1: ??? ==14381==by 0x7FF000CC6: ??? ==14381== ==14381== Conditional jump or move depends on uninitialised value(s) ==14381==at 0x400AF5E: _dl_relocate_object (do-rel.h:65) ==14381==by 0x40037B0: dl_main (rtld.c:2265) ==14381==by 0x401499D: _dl_sysdep_start (dl-sysdep.c:244) ==14381==by 0x4001422: _dl_start (rtld.c:341) ==14381==by 0x4000AF7: ??? (in /lib/ld-2.13.so) ==14381==by 0x1: ??? ==14381==by 0x7FF000CC6: ??? ==14381==by 0x7FF000CCB: ??? ==14381== ==14381== Conditional jump or move depends on uninitialised value(s) ==14381==at 0x400AF67: _dl_relocate_object (do-rel.h:68) ==14381==by 0x40037B0: dl_main (rtld.c:2265) ==14381==by 0x401499D: _dl_sysdep_start (dl-sysdep.c:244) ==14381==by 0x4001422: _dl_start (rtld.c:341) ==14381==by 0x4000AF7: ??? (in /lib/ld-2.13.so) ==14381==by 0x1: ??? ==14381==by 0x7FF000CC6: ??? ==14381==by 0x7FF000CCB: ??? ==14381== ==14381== Conditional jump or move depends on uninitialised value(s) ==14381==at 0x400AF5E: _dl_relocate_object (do-rel.h:65) ==14381==by 0x40038F3: dl_main (rtld.c:2331) ==14381==by 0x401499D: _dl_sysdep_start (dl-sysdep.c:244) ==14381==by 0x4001422: _dl_start (rtld.c:341) ==14381==by 0x4000AF7: ??? (in /lib/ld-2.13.so) ==14381==by 0x1: ??? ==14381==by 0x7FF000CC6: ??? ==14381==by 0x7FF000CCB: ??? ==14381== ==14381== Conditional jump or move depends on uninitialised value(s) ==14381==at 0x400AF67: _dl_relocate_object (do-rel.h:68) ==14381==by 0x40038F3: dl_main (rtld.c:2331) ==14381==by 0x401499D: _dl_sysdep_start (dl-sysdep.c:244) ==14381==by 0x4001422: _dl_start (rtld.c:341) ==14381==by 0x4000AF7: ??? (in /lib/ld-2.13.so) ==14381==by 0x1: ??? ==14381==by 0x7FF000CC6: ??? ==14381==by 0x7FF000CCB: ??? ==14381== ==14381== Warning: noted but unhandled ioctl 0x4601 with no size/direction hints ==14381==This could cause spurious value errors to appear. ==14381==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==14381== Warning: noted but unhandled ioctl 0x4611 with no size/direction hints ==14381==This could cause spurious value errors to appear. ==14381==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==14381== Warning: noted but unhandled ioctl 0x4606 with no size/direction hints ==14381==This could cause spurious value errors to appear. ==14381==See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==14381== Conditional jump or move depends on uninitialised value(s) ==14381==at 0x69672EB: __strcasecmp_l_ssse3 (strcmp.S:243) ==14381==by 0x5B64212: FontFileMatchRenderer (in /usr/lib/libXfont.so.1.4.1) ==14381==by 0x5B60475: FontFileAddFontFile (in /usr/lib/libXfont.so.1.4.1) ==14381==by 0x5B5F066: FontFileReadDirectory (in /usr/lib/libXfont.so.1.4.1) ==14381==by 0x5B62E2E: FontFileInitFPE (in /usr/lib/libXfont.so.1.4.1) ==14381==by 0x431F25: SetFontPathElements (dixfonts.c:1720) ==14381==
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 10:08:47AM +0200, Michel Dänzer wrote: Steve, can you provide the output of fbset -i and the /etc/X11/xorg.conf file as well? Any reason for not using the radeon driver? I don't know why the radeon driver is not in use. I have two monitors (1600x1200 and 1920x1200) and configure things using the KDE system config tool. fbset -i: mode 1280x1024 geometry 1280 1024 3200 1200 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode Frame buffer device information: Name: radeondrmfb Address : 0xd0142000 Size: 9216000 Type: PACKED PIXELS Visual : TRUECOLOR XPanStep: 1 YPanStep: 1 YWrapStep : 0 LineLength : 7680 Accelerator : No xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Device Identifier Configured Video Device EndSection Section Screen Identifier Configured Screen Device Configured Video Device SubSection Display Virtual 3200 1200 EndSubSection #DefaultDepth 24 #SubSection Display #Viewport 0 0 #Depth 24 #EndSubSection EndSection signature.asc Description: Digital signature
