KDE SC 4.7 Release Candidate Hits The Web

[RealNC]

Also, does anyone knows if kwin 4.7 finall fixes the garbage that displays momentarily when opening a new window? (Again, compiz doesn't suffer from this...)

It's still there. It seems to be an X.Org bug though. It was reported upstream, but it hasn't been fixed yet. The bug report has a patch attached to it:

http://bugs.freedesktop.org/show_bug.cgi?id=34427

I applied the patch and it helped.

[RealNC]

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.

[energyman]

I hope you're right. KDE is in so much need of bug fixing. I don't care what the ratio of bugs to LOC is supposed to be, it still feels and looks like it has more bugs compared to gnome. Maybe it has less bugs, but at least on gnome they know how to cover them up really well and they don't stick out all the time affecting productivity and workflow as much :P

PS: I doubt they have run out of "new great features". Just take a look at the file transfer notification introduced in version 4.6. Why do we need a graph in the thing?? Sure it's kind of cool for the geek, but if I want to look at graphs I'd rather use the system monitor. Why duplicate features, especially when there are so many bugs in the bloody notification system to begin with?

because a graph is a good thing? What would you do? Just three numbers? Nothing but a text 'file transfer in progress'? I like the graphs. Really, I do.

[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.

[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).

[darkbasic]

They forget to remove it even for non-beta:

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

[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.

[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.

[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.

[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).