ons 2010-05-05 klockan 17:30 +0200 skrev Jim Meyering:
> I propose (seriously, now) to add this to /etc/profile,
> or to some always-sourced file like /etc/profile.d/glibc.sh:
>
> # Enable glibc's malloc perturbing feature in Rawhide.
> # http://udrepper.livejournal.com/11429.html
> r
Peter Jones wrote:
> Obsoletes is an awfully blunt instrument for this - it'd be a lot better to
> make change the debug.sh (and its .csh friend) have a conditional+config to
> decide whether to import the sysconfig bits based on either a) is this
> rawhide,
> and b) has the admin overridden "a" i
On 05/06/2010 12:41 PM, Garrett Holmstrom wrote:
> On 5/6/2010 4:16, Thomas Spura wrote:
>> Am Mittwoch, den 05.05.2010, 21:34 -0500 schrieb Eric Sandeen:
>>> Matt McCutchen wrote:
On Wed, 2010-05-05 at 16:51 -0400, Bill Nottingham wrote:
> See the 'debugmode' package.
Neat, I wa
On 5/6/2010 4:16, Thomas Spura wrote:
> Am Mittwoch, den 05.05.2010, 21:34 -0500 schrieb Eric Sandeen:
>> Matt McCutchen wrote:
>>> On Wed, 2010-05-05 at 16:51 -0400, Bill Nottingham wrote:
See the 'debugmode' package.
>>>
>>> Neat, I wasn't aware of that package.
>>
>> which is why I still li
Am Mittwoch, den 05.05.2010, 21:34 -0500 schrieb Eric Sandeen:
> Matt McCutchen wrote:
> > On Wed, 2010-05-05 at 16:51 -0400, Bill Nottingham wrote:
> >> Jim Meyering (j...@meyering.net) said:
> >>> This is useful enough that it is worth considering for inclusion
> >>> in /etc/profile.
> >> See th
Jim Meyering writes:
> Michal Schmidt wrote:
>> Would export MALLOC_CHECK_=3 be a useful addition too?
>
> Does that impose much of a performance impact?
> I haven't used it or measured it enough to know off hand.
openSUSE Factory is setting it by default since several years (it gets
disabled ag
Matt McCutchen wrote:
> On Wed, 2010-05-05 at 16:51 -0400, Bill Nottingham wrote:
>> Jim Meyering (j...@meyering.net) said:
>>> This is useful enough that it is worth considering for inclusion
>>> in /etc/profile.
>> See the 'debugmode' package.
>
> Neat, I wasn't aware of that package.
which is
On Wed, 2010-05-05 at 16:51 -0400, Bill Nottingham wrote:
> Jim Meyering (j...@meyering.net) said:
> > This is useful enough that it is worth considering for inclusion
> > in /etc/profile.
>
> See the 'debugmode' package.
Neat, I wasn't aware of that package. Turns out it's broken because the
e
Jim Meyering (j...@meyering.net) said:
> This is useful enough that it is worth considering for inclusion
> in /etc/profile.
See the 'debugmode' package.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Am Mittwoch, den 05.05.2010, 13:54 -0400 schrieb Frank Ch. Eigler:
> Jeff Spaleta writes:
>
> > [...]
> >> Stating something like this clearly on login & install would be nice,
> >> not just for this MALLOC_PERTURB_ change but in general.
> >
> > Doesn't this whole discussion about debugging vers
On Wed, May 5, 2010 at 9:54 AM, Frank Ch. Eigler wrote:
> Good point. Clearly though one can't delay the setting of the final
> release behaviors too long, or else *those* won't get tested.
I'm not arguing about what that point should be. I'm just saying that
this glib debugging stuff should syn
Jeff Spaleta writes:
> [...]
>> Stating something like this clearly on login & install would be nice,
>> not just for this MALLOC_PERTURB_ change but in general.
>
> Doesn't this whole discussion about debugging versus performance also
> apply to F13 pre-release testing as well.. and not just raw
On 05/05/2010 12:42 PM, Jeff Spaleta wrote:
> On Wed, May 5, 2010 at 9:28 AM, Eric Sandeen wrote:
>> Agreed, I'm tired of (insert random benchmarking site) saying "OH NOES!
>> Fedora got SLOWER AGAIN!" when it's really a lot of debug going on.
>>
>> Stating something like this clearly on login & i
On Wed, May 5, 2010 at 9:28 AM, Eric Sandeen wrote:
> Agreed, I'm tired of (insert random benchmarking site) saying "OH NOES!
> Fedora got SLOWER AGAIN!" when it's really a lot of debug going on.
>
> Stating something like this clearly on login & install would be nice,
> not just for this MALLOC_P
On 05/05/2010 12:21 PM, David Malcolm wrote:
> On Wed, 2010-05-05 at 18:24 +0200, Michal Schmidt wrote:
>> On Wed, 05 May 2010 17:30:29 +0200 Jim Meyering wrote:
>>> I propose (seriously, now) to add this to /etc/profile,
>>> or to some always-sourced file like /etc/profile.d/glibc.sh:
>>>
>>>
On Wed, 2010-05-05 at 18:24 +0200, Michal Schmidt wrote:
> On Wed, 05 May 2010 17:30:29 +0200 Jim Meyering wrote:
> > I propose (seriously, now) to add this to /etc/profile,
> > or to some always-sourced file like /etc/profile.d/glibc.sh:
> >
> > # Enable glibc's malloc perturbing feature in R
Michal Schmidt wrote:
> On Wed, 05 May 2010 17:30:29 +0200 Jim Meyering wrote:
>> I propose (seriously, now) to add this to /etc/profile,
>> or to some always-sourced file like /etc/profile.d/glibc.sh:
>>
>> # Enable glibc's malloc perturbing feature in Rawhide.
>> # http://udrepper.livejou
On Wed, 05 May 2010 17:30:29 +0200 Jim Meyering wrote:
> I propose (seriously, now) to add this to /etc/profile,
> or to some always-sourced file like /etc/profile.d/glibc.sh:
>
> # Enable glibc's malloc perturbing feature in Rawhide.
> # http://udrepper.livejournal.com/11429.html
> re
H. Guémar wrote:
>> This is useful enough that it is worth considering for inclusion
> in /etc/profile.
>
> during development cycle: +1
> for stable/production release: not so much (users would hate us for that)
It's definitely not suitable for everyone.
My suggestion was intended to be provocati
On Wed, 2010-05-05 at 11:01 +0200, Jim Meyering wrote:
> If you are into development on glibc-based systems
> and do not set MALLOC_PERTURB_ to a nonzero value, then you
> are missing an easy opportunity to detect subtle bugs early.
>
> Sure, you can use valgrind, and it will detect whatever a
> M
> This is useful enough that it is worth considering for inclusion
in /etc/profile.
during development cycle: +1
for stable/production release: not so much (users would hate us for that)
regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/list
If you are into development on glibc-based systems
and do not set MALLOC_PERTURB_ to a nonzero value, then you
are missing an easy opportunity to detect subtle bugs early.
Sure, you can use valgrind, and it will detect whatever a
MALLOC_PERTURB_ setting would have caught, and more, but it's
far mo
22 matches
Mail list logo
