Anders Johansson wrote:
On Sunday 23 December 2007 01:26:08 Carlos E. R. wrote:
The Saturday 2007-12-22 at 18:09 +0100, Anders Johansson wrote:
Actually, it helps solve it, sometimes. The application crashes, probably I wouldn't say "probably". It shouldn't be par for the course for an application to not check return values from memory allocation functions That's not what I said. Look again:
] The application crashes, probably ] with an error, maybe a core dump or a backtrace, and it can be examined.
There is a comma after the "crashes".
I didn't say that it "probably crashes". I said that it will crash, and then probably will produce an error message.
The idea is that an application that has a memory hole and uses a lot of memory doesn't crash, but by running with an "ulimit" it will crash when it hits the limit, ant then the error, coredump, or backtrace can be examined.
Well, the idea might work, but I still say that you're too dogmatic. Even an application that forgets to free() memory can still test the return code from malloc() properly. It's not a given that it will crash. It might just exit normally, without a core being produced]
If it doesn't check return values from malloc() (or something which calls malloc()), it WILL crash due to a segmentation fault (trying to write to structure members through a structure-pointer which is NULL or -1. If it does check return it can still crash, but that would be due to other problems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org