If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
You know, all this can be avoided with the use of smart pointers. There are, certainly, situations where you absolutely can't afford the small overhead of a light object such as a smart pointer, but all in all naked pointers should be only needed when absolutely necessary IMHO.
Also, using smart pointers allow you in many cases to avoid having to make deep copies of objects, so you can get an overall speedup in your code when using them.
But of course, we'll have the usual avalanche of bitching against U
buntu, Canonical and what not.
And how do you propose using smart pointers in freaking C?
I hope they will fix this issue before releasing -rc, because I want to switch to Kubuntu and stick with it.
I like Kubuntu but I wouldn't count on this too much...
They were releasing this distribution versions (older *buntus) in history with known bugs in kernel or Xorg before because of the strict release dates.
These GLX 1.4 changes were from 1.8.0. Why backport them in the first place to a LTS?
Good question. The theory, at least, was that going all the way to 1.8 was risky, but staying on pure 1.7 would leave them something that wouldn't be sufficient over the lifespan of an LTS.
In practice, they now have a hybrid mess of the two, probably filled with bugs, and which they'll have to support without independently of upstream Xorg. And for some reason, this seemed preferable to just dropping in 1.8, and fixing any problems that resulted...
Wait, you didn't let me finish with my proposal, LOL
Incidentally, I had the chance of browsing some KDE code for a bug fix, and it's all naked pointers, even though Qt provides some shared pointers. Oh well.
Pointers are not bad at all especially in the Qt case where any QObject can have a parent (if the destructor of the parent is called any child is destructed as well).
In fact if you want that a dialog is deleted when it is hidden you can simply do that by a flag and not resort on the parent being destroyed, or you could also reuse the dialog later.
Probably in most cases you looked at shared pointers would be a complete unnecessary overhead. If you use smartpointers everywhere + other "always secure"-measures you should probably use a different programming-language that was designed for that.
One possible solution is to roll back the GLX 1.4 enablement patches, and the patch which caused the memory leak to appear. These GLX patches were produced by RedHat and incorporated into Debian, they were not brought in due to Ubuntu-specific requirements and thus it is believed dropping these patches would not impact any of Lucid's development goals. The one risk to be mindful of is if any userspace applications have come to depend on the newer GLX functionality.
This way or writing sounds like Ubuntu 10.04 will be a broken release full of memory leaks. You can write a better title, like "Ubuntu 10.04 develoment/beta release is hit by major X.Org memory leak".
The problem would have been if the release the "stable" 10.04 with the memory leak. It is only a beta version, this is sometimes the price for using it.
The Ubuntu developers should use more Upstream stable code, and not take some more or less good known stable code and start to patch it, they will get less users and devs to test it.
Why did they not take the Xserver 1.8 code, release 10.04, and push updates with 1.8.1, and 1.8.2, etc. but only the 1.8.x serie. More or less as they do with the kernel?