date:20110504

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

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: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: 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

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   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#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

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 
> #include 
> 
> class Hello
> {
> public:
> Hello ()
>  {}
> 
>~Hello ()
>  {}
> 
>void act ()
>  { std::cout << "Hello, world!" << std::endl; }
> };
> 
> static void __attribute__ (( constructor )) PWLIB_StaticLoader() { \
>__gnu_cxx::bitmap_allocator 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  (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

WikiGroups

2011-05-04 Thread fsheu

To see the web version of this message click here:
http://www.magnetmail.net/actions/email_web_version.cfm?recipient_id=715416346&message_id=1344737&user_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=1344737&user_id=ISC_&recipient_id=715416346&email=debian-glibc@lists.debian.org&group_id=637178

Bug#625616: libc6: Reproducible crash when allocating in a static constructor

2011-05-04 Thread Eugen Dedu


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 
#include 

class Hello
{
public:
   Hello ()
{}

  ~Hello ()
{}

  void act ()
{ std::cout << "Hello, world!" << std::endl; }
};

static void __attribute__ (( constructor )) PWLIB_StaticLoader() { \
  __gnu_cxx::bitmap_allocator 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  (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

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#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#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=, 
undef_map=, ref=0x7fffd7f8, symbol_scope=, 
version=, type_class=, flags=5, 
skip_map=0x0) at dl-lookup.c:779
#2  0x77dea782 in _dl_fixup (l=, reloc_arg=)
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=, 
hdr=, 
number=, arg=) at 
nsComponentManager.cpp:1137
#7  0x779270d0 in PL_DHashTableEnumerate (table=0x706eb1a8, 
etor=0x7795202d , 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=, 
binDirectory=, 
appFileLocationProvider=, staticComponents=, 
componentCount=) at nsXPComInit.cpp:773
#11 0x77bc34c7 in ScopedXPCOMStartup::Initialize (this=0x7fffe580) 
at nsAppRunner.cpp:1119
#12 0x77bc650d in XRE_main (argc=, argv=, 
aAppData=) 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=, 
undef_map=, ref=0x7fffd7f8, symbol_scope=, 
version=, type_class=, 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 = 
__PRETTY_FUNCTION__ = "_dl_lookup_symbol_x"
i = 
protected = 
#2  0x77dea782 in _dl_fixup (l=, reloc_arg=)
at ../elf/dl-runtime.c:118
version = 0xfefefefefefefeff
flags = 5
reloc = 
sym = 0x7fffdc291538
result = 
value = 
__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=, 
hdr=, 
number=, arg=) at 
nsComponentManager.cpp:1137
factoryEntry = 0x7fffe6e7a690
fd = 0x7fffe6e70d30
cidString = "{75a500a2-0030-40f7-86f8-63f225b940ae}"
className = 0x0
loaderName = 
loaderData = 0x706eb2b0
contractID = 0x0
classInfo = { = {mRawPtr = 0x7fffe6efa8a8}, }
location = 
#7  0x779270d0 in PL_DHashTableEnumerate (table=0x706eb1a8, 
etor=0x7795202d , arg=0x7fffda90)
at pldhash.c:754
entryAddr = 
entryLimit = 0x7fffe6e84000 "\030,\355\367\377\177"
i = 128
capacity = 2048
entrySize = 16
ceiling = 
didRemove = 0
entry = 0x7fffe6e7d020
op = 
#8  0x779523d7 in nsComponentManagerImpl::WritePersistentRegistry 
(this=0x706eb160)
at nsComponentManager.cpp:1246
file = { = {mRawPtr = 0x7fffd98d4480}, }
localFile = { = {mRawPtr = 0x7fffd98d4480}, }
originalLeafName = { = { = 
{ = {
mData = 0x7fffda30 "compreg.dat", mLength = 11, mFlags = 
65553}, }, 
mFixedCapacity = 63, mFixedBuf = 0x7fffda30 "compreg.dat"}, 
  mStorage = 
"compreg.dat\000\377\177\000\000\360\332\377\377\377\177\000\000\277\201\222\367\377\177\000\000X\332\377\377\377\177\000\000\b\000\000@\000\000\000\000N\006\227\367\377\177\000\000\354\332\377\377\377\177\000"}
fd = 0x7fffe6e70d30
rv = 
exists = 32767
parent = { = {mRawPtr = 0x7fffdad0}, }
leafName = { = { = { = {
m

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

Re: Bug#625521: glibc: causes segfault in Xorg

2011-05-04 Thread Cyril Brulebois

Michel Dänzer  (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

Re: Bug#625521: glibc: causes segfault in Xorg

2011-05-04 Thread Michel Dänzer

On Mit, 2011-05-04 at 11:08 +0200, Cyril Brulebois wrote: 
> Michel Dänzer  (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

2011-05-04 Thread Cyril Brulebois

Michel Dänzer  (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: glibc: causes segfault in Xorg

2011-05-04 Thread Michel Dänzer

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: glibc: causes segfault in Xorg

2011-05-04 Thread Michel Dänzer

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

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

Bug#625522: glibc: causes segfault in Xorg