KDE SC 4.7 Release Candidate Hits The Web

[energyman]

Regardless of whether it's a good choice, a KDE startup script is not the right place to make that choice for non-KDE apps.

have you checked that your distri does have the same entry? Or that it isn't set globally?

[RealNC]

I really can't be bothered to check

Oh, so typing "env | grep MALLOC_CHECK_" is too much of a bother. OK. And also, you think it's a good idea, but then you don't go ahead and enable it globally? Gee, why is that?

[RealNC]

MALLOC_CHECK 3 IS a good choice.

You don't believe? Use google for fsck sake!

ORLY? A development/debugging setting that slows down execution of every application, sometimes up to 25% or more, is a good choice for end-users? If you have used Google yourself instead of only telling others to, you would have found that this is supposed to be enabled only for betas and snapshots of KDE, not for release canditates.

So with when problems arise a warning is printed and the program aborted.

Which is a WISE CHOICE for test candidates like alphas, betas and release candidates.

No, for RCs it is not.

Question: why do YOU think it is a bad choice? Please with complete sources.

Because of the runtime overhead that makes the whole system go slower? OK, your opinion is that KDE should enable this for Firefox, mplayer, VMWare, VirtualBox, and every other app I have installed and which isn't part of KDE itself. It's your opinion, and you're entitled to it. Me, I think it's a retarded opinion. And I'm entitled to it too.

[BlackStar]

Then I take it you're using MALLOC_CHECK_=3 on your system too all the time, right? Since it's such a nice idea.

Possibly. I'm running a vanilla 4.6.3 install, so if it's enabled there then I'm running with that option enabled all the time.

I really can't be bothered to check, everything seems to work fine here (as far as crashes are concerned - KDE is still buggy even if it doesn't crash all that much nowadays).

[Ex-Cyber]

MALLOC_CHECK 3 IS a good choice.

Regardless of whether it's a good choice, a KDE startup script is not the right place to make that choice for non-KDE apps.

[energyman]

MALLOC_CHECK 3 IS a good choice.

You don't believe? Use google for fsck sake!

What are the results?


Setting MALLOC_CHECK_ :
If MALLOC_CHECK_ is set to 0 (zero), the memory management functions are simply more tolerant of error but do not give warnings.
Maybe be useful if we are prevented from finding one memory bug by another that is not convenient to fix at the moment; it might allow us to use other tools to chase down the other memory bug.
It may also be useful if you are running code that works on another system but not on Linux and we want a quick workaround that may allow the code to function temporarily, before you have the chance to resolve the error.
If MALLOC_CHECK_ is set to 1 (one), the memory management functions print out warning messages on standard error when they notice problems.
It is useful if we are not aware of any problems and just want to be notified if any problem exist.
If MALLOC_CHECK_ is set to 2 (two), the memory management functions call abort() when they notice problems.
This is most useful from inside the debugger or a shell starting an application or daemon, because it allows you to get a backtrace as soon as the memory management functions discover the error, which will get us closest to the point at which the error has happened.
It is useful if we get a core caused by a memory corruption, we would have more information about memory allocation therefore, making things better for troubleshooting where we need to find out which application overwrote a memory address.
We can still combine settings 1 and 2 and MALLOC_CHECK_ is set to 3 (three), where it will print out the warning messages on standard error (1) and will call abort() when problems are noticed (2).

as quoted from Novell.

So with when problems arise a warning is printed and the program aborted.

Which is a WISE CHOICE for test candidates like alphas, betas and release candidates. You want to find those problems BEFORE you release - and somebody use the same problems to hack your box. Or the desktop freezes.

Question: why do YOU think it is a bad choice? Please with complete sources.

[RealNC]

MALLOC_CHECK is a good idea for betas and release candidates.

For RCs? No, it's not. You seem to miss the point that this applies globally, for all applications, not just KDE.

Additionally, any crashes you encounter with that are application bugs that should be reported. Hiding buffer overruns and memory corruption under the rag is a really bad idea any way you look at it (security, stability, performance).

Then I take it you're using MALLOC_CHECK_=3 on your system too all the time, right? Since it's such a nice idea.

[darkbasic]

They forget to remove it even for non-beta:

https://bugs.kde.org/show_bug.cgi?id=247398

[BlackStar]

I think I found the root problem. /usr/bin/startkde (this script is used also for KDM logins) sets MALLOC_CHECK_=3. Argh!? No wonder I had crashes with programs that were previously working. And the system seemed so much slower.

I deleted the offending lines from startkde and restarted KDE. The machine seems to be back to about the same performance as with KDE 4.6 now.

lol @ all the people claiming "4.7 is so much faster here". With MALLOC_CHECK_ set *globally* for *every* application that starts after KDM? Yeaaah, suuuuure. Nice trolling people.

MALLOC_CHECK is a good idea for betas and release candidates.

Additionally, any crashes you encounter with that are application bugs that should be reported. Hiding buffer overruns and memory corruption under the rag is a really bad idea any way you look at it (security, stability, performance).

[energyman]

I think I found the root problem. /usr/bin/startkde (this script is used also for KDM logins) sets MALLOC_CHECK_=3. Argh!? No wonder I had crashes with programs that were previously working. And the system seemed so much slower.

I deleted the offending lines from startkde and restarted KDE. The machine seems to be back to about the same performance as with KDE 4.6 now.

lol @ all the people claiming "4.7 is so much faster here". With MALLOC_CHECK_ set *globally* for *every* application that starts after KDM? Yeaaah, suuuuure. Nice trolling people.

for some people the improvements might offset the slowdows through mallock_check. Yeah, I know, thinking and stuff.

Nice trolling tho.