The X window system also allows any program to send synthetic events to any window (or listen in on any window, for that matter). And while the server will mark the unreal events as synthetic, there is no way for the target application to know the exact source, so if it has a reason to accept some synthetics (e.g. from a companion program, or even from itself), it has to accept them all.
Here too, how bad a security problem this is depends on what the applications do with the events. Xterm, for instance, ignores all synthetic events by default, but it can be configured to process them.
Indeed. But this is a compilation tojan, after all. And it hurts most when one compiles as root on a machine that is connected. So...
I too am guilty of compilings things as root on my home box every now and then. Yeah, call me lazy, I know that I deserve it. But I do have a long standing rule that I never ever work as root, or even just log in as such, while connected (I have a dial-up line). Each program that is run by root is an additional security risk, even if it's run manually and only once every 6 months.
Oh, I absolutely agree with that. I use GC in a C++ context, but definitely not exclusively. Sometimes you need to have more control than precooked GC schemes will give you.
As a side note, I wrote my own malloc/free replacement library with some custom extensions to provide better allocation control ande debugging. Just for the fun of it. For our purposes it beats the pants of the versions that come with HP-UX, Solaris, and Linux in terms of speed as well as memory usage. Later on a a collegue built the GC framework that I'm using on top of my custom malloc in such a way that it coexists very nicely with it. This gives the developers the best of both worlds.
Now that I am awake again, I have to correct the above figures: please read 250 instead of 25 and 500 instead of 50. Those are the ones I meant to post in the first place anyway.
Nope. Purify works with several commercial Unices: HP-UX, Solaris, AIX, and I think even SGI's concoction. And with 'doze, of course, but who cares about those guys.:-)
Indirectly or directly - from the point of view of a malloc debugger it is the same thing. A malloc debug tool cannot make these subtle distinctions.
The (in)directness has nothing to do with the core point I was making. It's just an additional example of why tracking point-of-leak also is computationally more difficult than tracking point-of-access.
My real point is that to track point-of-leak, you need to cover at a lot more possibilitties. For instance, you need to cover the case where A leaks because B, which happens to hold a pointer a A hidden in between a lot of ints, chars, floats, structs, and unions (!) leaks. But B might leak only at the point where part of C is accidently overwritten (note: not freed or leaked!) due to some dangling pointer D being followed. In contrast, to just only track the location of the last access to B, you only need to worry about code that accesses B directly on the one hand, and dangling pointers "into B" (yes, I'm simplifying for the sake of not turning this post into an essay) on the other. Tools such as Purify could relatively easily be extended to give you the last access. The same does not hold for the exact location of the leak. The latter functionality can be implemented, but it's a lot more involved.
Trust me, I do know what I'm talking about. I've been writing tools to track and optimise memory accesses for a living for nearly 5 years now and have actually implemented a lot of the stuff that I mention above.
No, it's not. Time of last access to an dynamically allocated block is when you last directly accessed it. Time of leaking is when you, possibly indirectly, caused it to become unreachable by accesssing some other block that looks totally unrelated unless you know a lot more about the program than Purify does.
Tracking the last access can be done with reasonable overhead. I know this for sure, because I actually worked on stuff that can track all accesses (full stack trace) and that could easily be altered to single out the final one.
But deciding when something became unreachable is a whole lot harder. Even more so if, as is the case with Purify, you do not know the semantics of of the blobs of memory that you're toying with.
For my current project (a source code transformation system operating on C code), it depends on the input that I feed the program.
Typical Purify slowdowns are in the 25% range (e.g. when we're processing the MPEG-4 VM).
But I have one pathological test case that reached over 50% before I rewrote part of the code. This test case was quite interesting, actually: in causing such a big slowdown, Purify in fact pointed out a performance bottleneck (albeit a somewhat "irrelevant" one that I only fixed once I had to fix a real bug in the same file anyway).
While I agree with the unlerlaying message of your post, it must also be pointed out that the slowdown that Purify causes depends a lot on the nature of the code at hand. If the program does nothing but address memory, it will be large (especially if it uses pointers all the time). If the program spends its time performing arithmetic on registers or waiting for disk I/O to finish, it won't be.
From what I read about how Valgrind works, it will also slow down non-memory instructions.
Re:Valgrid is not as complete as Purify
on
Valgrind 1.0.0 Released
·
· Score: 3, Informative
When I called Rational to ask if they planned on supporting Linux, they said "Maybe sometime in the future", but when I continued questioning them, they said they had no immediate plans to start working on Linux versions of any of their software.
Franckly, I have the impression that Rational regard Purify and Quantify as cash cows that should not be touched unless absolutely required. All they ever did since they bought them was:
implement a Windows version (there's more cash at hand in that world);
change the licensing scheme to be ever more annoying;
fix minor annoyances after HP or Sun released new compiler versions;
finally add gcc support for version 2.95 when 3.0 had already been released for some time.
Other than the gcc 2.95 thing, I have seen no real improvements in years (I don't use Windows). Over the years, we forked over a lot of money for "support", though.
It's a great tool, but I'm not impressed with the company behind it.
Not only that. There aren't enough good programers to go around (I'll admit that my criteria for this label are extremely stringent, but still). So we need the average ones. And those need a lot of support.
Besides, I've seen Purify detect errors in code written by the best programer I've ever met. This guy is way beyond what most fellow programers can imagine both in terms of architecture/design and in terms of attention do detail in implementation. But just like the rest of us he's not infallible.
Re:Valgrid is not as complete as Purify
on
Valgrind 1.0.0 Released
·
· Score: 2, Interesting
The bad thing about Purify is that there ain't no Linux version.
I have used Purify ever since it was first put onto the market by Pure Software about a decade ago. But nowadays, Linux is becoming our real development platform, so if Rational ain't careful: exit Purify. Yes, it's sad, but I've told them often enough that Linux support is what they should bring me, not yet another rewrite of their licensing scheme.
Would I use MS product if it's free? Why not? I even use some that isn't (or rather wasn't, since they EOL-ed it long since).
But that's not to say "MicroSoft rejoice, for he will convert once it's free". I personally don't care about free or not (well, as long as I can find the money to bay the payware that I need, but that's an issue at an other level) (Besides: If I can't find it, its not my problem, but that of the producer who is missing out on a user.). But I do care about getting tools that let me do what I want to do the way that I want to do it, that do not fall over every other minute, and that can be fixed if they fall over. Taking all those aspects into account, all current MS software is out of the question whenever I have a say about what stuff I use.
From the command line, maybe. But I do use a graphical MH wraper and MH style folders are my number 1 requirement whenever I go out shopping for an e-mail client. As mentioned before, the ability to apply standard UNNIX commands to folders and messages is priceless.
With multiGB disks costing nearly nothing, who cares about a bit of space wastage for small mails? I use 1 file per message, and I can assure you that the ease of being able to manipulate them in arbitrary ways (think grep & Co!) is worth much more than the few byts of disk spaces that I might save by changing format.
Besides, as the origional story correctly notes: more and more mails are wasteful multimegabyte monsters with more attachmants than any sane human wants to see. This pretty much dwarfs any concerns about the small files!
Either their server is extremely shaky (slashdotted after only 2 posts (without even a "first" one:-), can that really happen?), or it doesn't work behind a firewall. It keeps saying "the connection with kartoo failed", even with a 3 minute timeout setting. Seems a bit useless to me...
Re:Mozilla/Netscape usage & anti-Netscape sent
on
Mozilla RC3 Released
·
· Score: 2, Interesting
In some markets, there still is some hope, as I posted not so long ago. The good news is that our percentage Mozilla/NS6 using visitors is rising (albeit slowly). The "bad" news is that we definitely are atypical: yesterday we got about 16% non-Windows visitors.
Being 1) a computer scientist; and 2) an officer in my country's naval reserve, I happen to know about Navy's having radios.:-)
I also know about 1) how navies work (everything has to be mil spec, so they generally do not have the latest and greatest; bandwidth limitations apply to ship-to-shore traffic (especially while at sea), etc.); and 2) about how bugs are located in software. Before you can patch it, you must find it first. To find it, you need access to the symptoms and "We're dead in the water, Sir. No Sir, I don't know what happened. Sorry Sir." isn't good enough a description.
In theory they would be able to patch the code, recompile, etc. In practice the Navy doesn't have all that many ueberhackers in its rangs. It can't afford to put one aboard each ship that leaves port.
I'm not sure about the latest on Linux passwords, but are you sure that you don't get access when only typing the first 8 characters of your password? I'm asking, because back in the dark ages (early nineties) I had a 9 character password on UNIX (various flavours) for a while. I knew about the 8 character limit but, as it happened, my password generating algorithm at that time resulted in 9 characters and so that's how I remembered it. The last character was irrelevant in practice, but it was accepted, thus creating the illusion of a 9 character password.
It all depends on your public. Our site is oriented to very technically minded people, partly from the ECAD comunity which even is very UNIX minded. Hence, our stats reed more or less like this: 65% IE, 25% NS4, 5% NS6/Mozilla, 1% Opera, 4% all the others combined.
Slashdot Mirror
The X window system also allows any program to send synthetic events to any window (or listen in on any window, for that matter). And while the server will mark the unreal events as synthetic, there is no way for the target application to know the exact source, so if it has a reason to accept some synthetics (e.g. from a companion program, or even from itself), it has to accept them all.
Here too, how bad a security problem this is depends on what the applications do with the events. Xterm, for instance, ignores all synthetic events by default, but it can be configured to process them.
Indeed. But this is a compilation tojan, after all. And it hurts most when one compiles as root on a machine that is connected. So...
I too am guilty of compilings things as root on my home box every now and then. Yeah, call me lazy, I know that I deserve it. But I do have a long standing rule that I never ever work as root, or even just log in as such, while connected (I have a dial-up line). Each program that is run by root is an additional security risk, even if it's run manually and only once every 6 months.
4: Compile on a system that is not connected to the net. Or at least properly firewalled.
Oh, I absolutely agree with that. I use GC in a C++ context, but definitely not exclusively. Sometimes you need to have more control than precooked GC schemes will give you.
As a side note, I wrote my own malloc/free replacement library with some custom extensions to provide better allocation control ande debugging. Just for the fun of it. For our purposes it beats the pants of the versions that come with HP-UX, Solaris, and Linux in terms of speed as well as memory usage. Later on a a collegue built the GC framework that I'm using on top of my custom malloc in such a way that it coexists very nicely with it. This gives the developers the best of both worlds.
Now that I am awake again, I have to correct the above figures: please read 250 instead of 25 and 500 instead of 50. Those are the ones I meant to post in the first place anyway.
Sorry.
Nope. Purify works with several commercial Unices: HP-UX, Solaris, AIX, and I think even SGI's concoction. And with 'doze, of course, but who cares about those guys. :-)
The (in)directness has nothing to do with the core point I was making. It's just an additional example of why tracking point-of-leak also is computationally more difficult than tracking point-of-access.
My real point is that to track point-of-leak, you need to cover at a lot more possibilitties. For instance, you need to cover the case where A leaks because B, which happens to hold a pointer a A hidden in between a lot of ints, chars, floats, structs, and unions (!) leaks. But B might leak only at the point where part of C is accidently overwritten (note: not freed or leaked!) due to some dangling pointer D being followed. In contrast, to just only track the location of the last access to B, you only need to worry about code that accesses B directly on the one hand, and dangling pointers "into B" (yes, I'm simplifying for the sake of not turning this post into an essay) on the other. Tools such as Purify could relatively easily be extended to give you the last access. The same does not hold for the exact location of the leak. The latter functionality can be implemented, but it's a lot more involved.
Trust me, I do know what I'm talking about. I've been writing tools to track and optimise memory accesses for a living for nearly 5 years now and have actually implemented a lot of the stuff that I mention above.
The Mozilla people use Purify.
It is the same thing.
No, it's not. Time of last access to an dynamically allocated block is when you last directly accessed it. Time of leaking is when you, possibly indirectly, caused it to become unreachable by accesssing some other block that looks totally unrelated unless you know a lot more about the program than Purify does.
But the overhead would make it near unusable.
Tracking the last access can be done with reasonable overhead. I know this for sure, because I actually worked on stuff that can track all accesses (full stack trace) and that could easily be altered to single out the final one.
But deciding when something became unreachable is a whole lot harder. Even more so if, as is the case with Purify, you do not know the semantics of of the blobs of memory that you're toying with.
For my current project (a source code transformation system operating on C code), it depends on the input that I feed the program.
Typical Purify slowdowns are in the 25% range (e.g. when we're processing the MPEG-4 VM).
But I have one pathological test case that reached over 50% before I rewrote part of the code. This test case was quite interesting, actually: in causing such a big slowdown, Purify in fact pointed out a performance bottleneck (albeit a somewhat "irrelevant" one that I only fixed once I had to fix a real bug in the same file anyway).
In fairness, if the language protects them from their own incompetence, it can rightfully be said to be superior in some sense. :-)
Ideally there would be no incompetent programmers, but ideally there wouldn't be any bugs either.
While I agree with the unlerlaying message of your post, it must also be pointed out that the slowdown that Purify causes depends a lot on the nature of the code at hand. If the program does nothing but address memory, it will be large (especially if it uses pointers all the time). If the program spends its time performing arithmetic on registers or waiting for disk I/O to finish, it won't be.
From what I read about how Valgrind works, it will also slow down non-memory instructions.
Franckly, I have the impression that Rational regard Purify and Quantify as cash cows that should not be touched unless absolutely required. All they ever did since they bought them was:
Other than the gcc 2.95 thing, I have seen no real improvements in years (I don't use Windows). Over the years, we forked over a lot of money for "support", though.
It's a great tool, but I'm not impressed with the company behind it.
Not only that. There aren't enough good programers to go around (I'll admit that my criteria for this label are extremely stringent, but still). So we need the average ones. And those need a lot of support.
Besides, I've seen Purify detect errors in code written by the best programer I've ever met. This guy is way beyond what most fellow programers can imagine both in terms of architecture/design and in terms of attention do detail in implementation. But just like the rest of us he's not infallible.
The bad thing about Purify is that there ain't no Linux version.
I have used Purify ever since it was first put onto the market by Pure Software about a decade ago. But nowadays, Linux is becoming our real development platform, so if Rational ain't careful: exit Purify. Yes, it's sad, but I've told them often enough that Linux support is what they should bring me, not yet another rewrite of their licensing scheme.
Would I use MS product if it's free? Why not? I even use some that isn't (or rather wasn't, since they EOL-ed it long since).
But that's not to say "MicroSoft rejoice, for he will convert once it's free". I personally don't care about free or not (well, as long as I can find the money to bay the payware that I need, but that's an issue at an other level) (Besides: If I can't find it, its not my problem, but that of the producer who is missing out on a user.). But I do care about getting tools that let me do what I want to do the way that I want to do it, that do not fall over every other minute, and that can be fixed if they fall over. Taking all those aspects into account, all current MS software is out of the question whenever I have a say about what stuff I use.
From the command line, maybe. But I do use a graphical MH wraper and MH style folders are my number 1 requirement whenever I go out shopping for an e-mail client. As mentioned before, the ability to apply standard UNNIX commands to folders and messages is priceless.
With multiGB disks costing nearly nothing, who cares about a bit of space wastage for small mails? I use 1 file per message, and I can assure you that the ease of being able to manipulate them in arbitrary ways (think grep & Co!) is worth much more than the few byts of disk spaces that I might save by changing format.
Besides, as the origional story correctly notes: more and more mails are wasteful multimegabyte monsters with more attachmants than any sane human wants to see. This pretty much dwarfs any concerns about the small files!
Either their server is extremely shaky (slashdotted after only 2 posts (without even a "first" one :-), can that really happen?), or it doesn't work behind a firewall. It keeps saying "the connection with kartoo failed", even with a 3 minute timeout setting. Seems a bit useless to me...
In some markets, there still is some hope, as I posted not so long ago. The good news is that our percentage Mozilla/NS6 using visitors is rising (albeit slowly). The "bad" news is that we definitely are atypical: yesterday we got about 16% non-Windows visitors.
Being 1) a computer scientist; and 2) an officer in my country's naval reserve, I happen to know about Navy's having radios. :-)
I also know about 1) how navies work (everything has to be mil spec, so they generally do not have the latest and greatest; bandwidth limitations apply to ship-to-shore traffic (especially while at sea), etc.); and 2) about how bugs are located in software. Before you can patch it, you must find it first. To find it, you need access to the symptoms and "We're dead in the water, Sir. No Sir, I don't know what happened. Sorry Sir." isn't good enough a description.
In theory they would be able to patch the code, recompile, etc. In practice the Navy doesn't have all that many ueberhackers in its rangs. It can't afford to put one aboard each ship that leaves port.
I'm not sure about the latest on Linux passwords, but are you sure that you don't get access when only typing the first 8 characters of your password? I'm asking, because back in the dark ages (early nineties) I had a 9 character password on UNIX (various flavours) for a while. I knew about the 8 character limit but, as it happened, my password generating algorithm at that time resulted in 9 characters and so that's how I remembered it. The last character was irrelevant in practice, but it was accepted, thus creating the illusion of a 9 character password.
It all depends on your public. Our site is oriented to very technically minded people, partly from the ECAD comunity which even is very UNIX minded. Hence, our stats reed more or less like this: 65% IE, 25% NS4, 5% NS6/Mozilla, 1% Opera, 4% all the others combined.