stack smashing Was: Re: Scanning Formats (TIFF vs. JPEG)
derschjo at msu.edu
Sun Aug 20 16:33:59 CDT 2006
Well, I seem to have struck a nerve here, now haven't I? I was
intending my comment to be mostly tongue-in-cheek, but I guess I failed
on that count. Next time I'll use more smileys.
> The problem is that in Java, you can get
> away with allocating gobs of memory without having to free it, and
> justify it with "Oh, the GC will clear it for me" however that attitude
> does not work when dealing with JDBC connections, or file handles.
So your argument seems to be that the experience to know that JDBC and
file handles are the exception to the rule is necessary here. No
argument there. It's an unfortunate issue with the language (or it may
be an unfortunate issue with the way the JDBC libraries are written).
The same mistakes can be made in any other language that lacks a GC.
> So, while you might be able to get away with writing sloppy memory
> allocation code in Java,
How does one write memory allocation code in Java? As far as I know,
there's really only one interface to it and it's provided by the
runtime. If you're talking about being wasteful with memory, that's one
thing... but you can be wasteful with memory in any language with no
> I pointed at C and assembly as examples of languages that lack garbage
> collection. Because they lack this "feature", they therefore enforce
> writing of better code, or force you to face much earlier crashes,
> and/or a clear growth of memory footprint over time.
I posit that you can write crappy code in any language and still get
away with it. Hell, I'd say it's a lot easier to write crappy code in
C. The things I've seen done with pointers... ugh. As for C
_enforcing_ writing better code (solely due to lack of a GC?) -- you're
kidding right? It enforces _knowledgeable_ programmers to be 100 times
more careful (and the key here is _knowledgeable_) , but it won't
prevent _anyone_ from shooting themselves in the foot without even
knowing it even if they think they are being careful (buffer overruns,
invalid pointers, etc). That's why this thead about stack-smashing got
started in the first place, eons ago...
> With Java, the memory footprint climbs up and down over time as the GC
> is invoked, and if the GC has to do a lot of work, the JVM freezes, and
> many memory leaks you may have are masked by the GC. You don't really
> know if you have a leak or not until it's too late (when you see your
> JVM has a 2GB footprint and is doing GC's that take over 60 seconds to
> complete), and even then, its difficult to locate it amongst several
> thousand threads.
I don't know about Java specifically, but I know that for C# there are
profiling tools to help you nail down memory leaks when they occur. I
assume that these also exist for Java. If you're looking for memory
leaks solely based on memory footprint of the process, then yes, you're
going to have problems.
> I do think that it is proper to blame every language for all of their
I agree with the sentiment, but I still disagree that "inexperienced
programmers" is a shortcoming of the language. I can see every
programming language on earth falling into this bucket.
> - please do not pretend to hold some sort of high moral
> ground by claiming to uphold a language as some sort of godly
> perfection, while in the same breath, you have turned up your nose at
> the idea of writing threaded database connectivity drivers in "raw"
I have done no such thing. I merely sought to point out a flaw in a
proposition you made -- that it would be better to replace easily
maintainable/portable (in the _right hands_) code written in a
high-level language, dealing with high-level concepts (database access,
multithreading) with hand-built assembly code. And you propose doing
this _only_ because it somehow magically causes people to make fewer
mistakes with memory allocation. I don't think this is a reasonable
argument. There is a place for assembly code, but I don't believe this
particular case is one of them. I'd also argue that one can make many
more mistakes much more easily in assembly, even if one manages to
allocate memory correctly.
I think the argument you're really making here is that _experienced_
programmers (ones who have dealt with low-level languages like assembly
and C) know the pitfalls of memory allocation, file handles, performance
issues, etc... and as such could make much better use of Java. What
you're really saying is that you need to hire better programmers, and
that some programmers need to be better educated in computer architecture.
> But don't fail to call out the flaws where you find
> them - even if they happen to be in a favored or popular language.
I don't necessarily disagree. All languages have issues. What I
disagree with is your earlier claim that rewriting code better suited
for high-level languages in assembly is some sort of magic bullet that
would somehow reduce programmer error. If you gave the same Java coder
who's borking up the JDBC connections the task to rewrite it in assembly
I doubt very much that person would come up with an error-free
implementation in a reasonable timeframe. I think it would be far more
productive to sit down with the coder, beat him with a LART and explain
that JDBC and File handles need to be closed (and why!).
More information about the cctalk