[rescue] Mozilla Firefox

[Charles Shannon Hendrix]

Fri, 23 Apr 2004 @ 11:48 -0500, Jonathan C. Patschke said:

> On Fri, 23 Apr 2004, Charles Shannon Hendrix wrote:
> 
> > Far more complicated allocations are quite common, and a lot more
> > difficult than just calling free() on a single reference.
> 
> And almost all of them can be solved by maintaining memory-allocation
> metadata inside the structure you're working with.  It's not really
> rocket-science.  It's just like managing any other budget.

Even that gets complicated.

Look, I'm not saying it is impossible, and in most cases it is actually
quite easy.  But at the same time, a good automatic memory system will
often do a very good job.  Nothing is perfect of course.

I usually try to use structs too.  In fact, usually when faced with
complex free operations, I reconsider my algorithm to make sure I'm not
overcomplicating it for no reason.  A few simple changes to C, as I've
mentioned in the OO thread, would make a lot of this cleaner than it is
now.

A more basic problem is that we have a dearth of good programmers, and
while it would be nice if they were not there, they are.  They aren't
going away.

Here's a common error I found while working at Bank of America:

    somefunction(...)
    {
	char buffer[1024];
	/* do some work */
	return buffer;
    }

...or:

    somefunction(...)
    {
	char *buffer;
	buffer = malloc(something);
	/* do some work */
	free(buffer);
	return buffer;
    }

The code worked through blind luck.  Then one day after a year in
operation, the code finally went through a path that caused it to
overwrite the memory location in question before it was referenced.

My guess is that this cost them over $100K one week, which is when I was
asked to check the code and fix it.

External pointers to stack memory and areas that had been free()'d were
common, particular in some data filter code they had.  In fact, I've
found this in a lot of C code.

One programmer told me that this was OK, because the system would not
re-use memory areas allocated with malloc() if it was still referenced.
Regarding using an external reference to a function's stack space, he
was "pretty sure" that it would not be overwritten unless that function
were called again.

Unfortunately, a lot of C compilers don't even flag cases like that with
a warning.

Interesting too that in the second case where the point is free'd, gcc
issues no warning at all, even with all paranoia settings turned on.

The splint program does warn about it though, and I imagine lint would
too.

Note: this isn't an example in support of GC... just noting how bad a
lot of programmer's are.






-- 
shannon "AT" widomaker.com -- ["Trouble rather the tiger in his lair than
the sage amongst his books For to you kingdoms and their armies are mighty
and enduring,  but to him they are but toys of the moment to be overturned
by the flicking of a finger." - anonymous     ]