FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-04-2011, 05:42 AM
"Steve M. Robbins"
 
Default glibc: causes segfault in Xorg

On Wed, May 04, 2011 at 12:10:48AM -0500, 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).

Oh my word. So glibc 2.13 breaks random binaries that happened to
incorrectly use memcpy() instead of memmove()? What's wrong with the
glibc developers (and Ulrich Drepper in particular)?

I'm with Linus on this: let's just revert to the old behaviour. A
tiny amount of clock cycles saved isn't worth the instability.

Thanks,
-Steve

P.S. I tried rebuilding glibc myself locally, but gcc also segfaults
in the process :-(
 
Old 05-04-2011, 08:51 AM
Adam Borowski
 
Default glibc: causes segfault in Xorg

On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote:
> On Wed, May 04, 2011 at 12:10:48AM -0500, 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).
>
> Oh my word. So glibc 2.13 breaks random binaries that happened to
> incorrectly use memcpy() instead of memmove()?

memcpy() has fat warnings about the areas not overlapping, and that's the
very purpose of that function: a memmove() that is faster but less safe.

> What's wrong with the glibc developers (and Ulrich Drepper in particular)?

Nothing wrong, it is exactly the same as new compilers breaking behaviour
forbidden by the standard that used to work before.

The only problem is the breakage happening rarely, and thus being able to
survive for long.

> I'm with Linus on this: let's just revert to the old behaviour. A
> tiny amount of clock cycles saved isn't worth the instability.

I'd instead propose to sacrifice a tiny amount of cycles to check for
overlapping and abort()ing so buggy code can be fixed. Random instability
is the worst kind of error, a clean crash is easy to fix. Heck, we can even
make a change just before wheezy is frozen to make it call memmove() when a
breakage is detected. Just please don't paper over the bugs until then.

--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
 
Old 05-04-2011, 09:48 AM
Raphael Hertzog
 
Default glibc: causes segfault in Xorg

On Wed, 04 May 2011, Adam Borowski wrote:
> I'd instead propose to sacrifice a tiny amount of cycles to check for
> overlapping and abort()ing so buggy code can be fixed. Random instability
> is the worst kind of error, a clean crash is easy to fix. Heck, we can even
> make a change just before wheezy is frozen to make it call memmove() when a
> breakage is detected. Just please don't paper over the bugs until then.

While I can sympathize with this (it's what I want as a developer), it's
certainly not a good idea in Debian in general: we have many derivatives
taking unstable/testing at various points in time, and we also want to
make testing generally usable by end-users.

So it's best if you consider unstable always in production-mode by
default.

It's the same story than building applications/libraries with
DISABLE_DEPRECATED, it's good for developers but we should not enable
those in unstable/testing because we prefer not breaking packages that
have not been updated yet.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110504094833.GD22961@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110504094833.GD22961@rivendell.home.ouaza.com
 
Old 05-04-2011, 10:19 AM
Aurelien Jarno
 
Default glibc: causes segfault in Xorg

Le 04/05/2011 11:48, Raphael Hertzog a crit :
> On Wed, 04 May 2011, Adam Borowski wrote:
>> I'd instead propose to sacrifice a tiny amount of cycles to check for
>> overlapping and abort()ing so buggy code can be fixed. Random instability
>> is the worst kind of error, a clean crash is easy to fix. Heck, we can even
>> make a change just before wheezy is frozen to make it call memmove() when a
>> breakage is detected. Just please don't paper over the bugs until then.
>
> While I can sympathize with this (it's what I want as a developer), it's
> certainly not a good idea in Debian in general: we have many derivatives
> taking unstable/testing at various points in time, and we also want to
> make testing generally usable by end-users.
>
> So it's best if you consider unstable always in production-mode by
> default.

So how do you plan to detect bugs if you never enable a feature?

Don't answer me "experimental", this is enabled in experimental for over
a month, and AFAIK it is also enabled in the latest Ubuntu release.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DC1281B.2030705@aurel32.net">http://lists.debian.org/4DC1281B.2030705@aurel32.net
 
Old 05-04-2011, 10:29 AM
Julien BLACHE
 
Default glibc: causes segfault in Xorg

"Steve M. Robbins" <steve@sumost.ca> wrote:

Hi,

> I'm with Linus on this: let's just revert to the old behaviour. A
> tiny amount of clock cycles saved isn't worth the instability.

Tiny amount?! The optimized memcpy() variants that break shitty code
bring a 4 to 5x speedup on the processors they've been written for!

JB.

--
Julien BLACHE - Debian & GNU/Linux Developer - <jblache@debian.org>

Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3jyn4gx.fsf@sonic.technologeek.org">http://lists.debian.org/87d3jyn4gx.fsf@sonic.technologeek.org
 
Old 05-04-2011, 11:04 AM
Goswin von Brederlow
 
Default glibc: causes segfault in Xorg

Adam Borowski <kilobyte@angband.pl> writes:

> On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote:
>> I'm with Linus on this: let's just revert to the old behaviour. A
>> tiny amount of clock cycles saved isn't worth the instability.
>
> I'd instead propose to sacrifice a tiny amount of cycles to check for
> overlapping and abort()ing so buggy code can be fixed. Random instability
> is the worst kind of error, a clean crash is easy to fix. Heck, we can even
> make a change just before wheezy is frozen to make it call memmove() when a
> breakage is detected. Just please don't paper over the bugs until then.

+1.

Maybe do this in 2 steps: 1) give a warning on stderr, 2) abort.
If even gcc fails (see other mail in this thread) then aborting when we
don't need to doesn't seem like a good option.

Or have a env var to disable the abort() so one can work around it.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ei4ebuc8.fsf@frosties.localnet">http://lists.debian.org/87ei4ebuc8.fsf@frosties.localnet
 
Old 05-04-2011, 11:34 AM
sean finney
 
Default glibc: causes segfault in Xorg

On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
> "Steve M. Robbins" <steve@sumost.ca> wrote:
>
> Hi,
>
> > I'm with Linus on this: let's just revert to the old behaviour. A
> > tiny amount of clock cycles saved isn't worth the instability.
>
> Tiny amount?! The optimized memcpy() variants that break shitty code
> bring a 4 to 5x speedup on the processors they've been written for!

And furthermore, even if Debian chooses to "fix" this, upstreams will
be forced to eventually cater to the default glibc behavior for every
other libc distro out there that does not have their own "fix" (and
non-libc OS's where this behavior already exists), so gains would be
potentially limited.

That said, regressions do suck, especially when they take the form of
heisenbugs. But one could easily hack something LD_PRELOAD'able check
for stuff like this without forcing a global change.

my 0.02 $LC_MONETARY anyway,

sean


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110504113415.GB2598@cobija.connexer.com">http://lists.debian.org/20110504113415.GB2598@cobija.connexer.com
 
Old 05-04-2011, 12:06 PM
Raphael Hertzog
 
Default glibc: causes segfault in Xorg

On Wed, 04 May 2011, Aurelien Jarno wrote:
> Le 04/05/2011 11:48, Raphael Hertzog a écrit :
> > So it's best if you consider unstable always in production-mode by
> > default.
>
> So how do you plan to detect bugs if you never enable a feature?

Really abort()ing is not a nice behaviour, it would be way better to print
a warning and fallback to a correct behaviour. Users can then report the
problems without experiencing a non working-application.

When something like this is not possible, I'm afraid Debian unstable is
not a good place to experiment...

I know this answer is not entirely satisfactory but the truth is there
are other distributions which follow another developement model that are
better suited to experiment such things, for example Fedora.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110504120641.GB23517@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110504120641.GB23517@rivendell.home.ouaza.com
 
Old 05-04-2011, 12:23 PM
Aurelien Jarno
 
Default glibc: causes segfault in Xorg

Le 04/05/2011 14:06, Raphael Hertzog a crit :
> a nice behaviour, it would be way better to print
> a warning and fallback to a correct behaviour. Users can then report the
> problems without experiencing a non working-application.

Printing a warning on a thing that is potentially used everywhere,
especially in scripts is not a good idea. It will simply corrupt the
data that the othe part of the script is waiting for, and that even on
stderr, a lot of scripts are not (correctly?) designed for that.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DC14537.8050406@aurel32.net">http://lists.debian.org/4DC14537.8050406@aurel32.net
 
Old 05-04-2011, 12:30 PM
Aurelien Jarno
 
Default glibc: causes segfault in Xorg

Le 04/05/2011 07:42, Steve M. Robbins a crit :
> On Wed, May 04, 2011 at 12:10:48AM -0500, 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).
>
> Oh my word. So glibc 2.13 breaks random binaries that happened to
> incorrectly use memcpy() instead of memmove()? What's wrong with the
> glibc developers (and Ulrich Drepper in particular)?
>
> I'm with Linus on this: let's just revert to the old behaviour. A
> tiny amount of clock cycles saved isn't worth the instability.
>
> Thanks,
> -Steve
>
> P.S. I tried rebuilding glibc myself locally, but gcc also segfaults
> in the process :-(
>

Are you sure it is something related? Which gcc version are you using?
Do you have a backtrace point to the same issue?

I am using this libc version for two months (on a CPU having ssse3
instruction set), it is also used by other distributions, so I find
strange it breaks something so common than gcc. For XOrg it can be due
to the difference in configuration, that's why the problem stayed unnoticed.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DC146EB.9000901@aurel32.net">http://lists.debian.org/4DC146EB.9000901@aurel32.net
 

Thread Tools




All times are GMT. The time now is 02:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org