Simply call talloc_strdup rather than strdup, (using the talloc_parent
of our 'state' object, (known here as yyextra).
This fix now makes glsl-orangebook-ch06-bump.frag 99.97% leak free:
total heap usage: 55,623 allocs, 55,609 frees
Only 14 missing frees now.
Could have just added a call to free() to main, but since we're using
talloc everywhere else, we might as well just use it here too. So pass
a new 'ctx' argument to load_text_file.
This removes a single memory leak from all invocations of the
standalone glsl compiler.
Easily done now that s_expression is allocated with talloc. Simply
switch from new to talloc_strdup and the job is done.
This closes the great majority (11263) of the remaining leaks in the
glsl-orangebook-ch06-bump.frag test:
total heap usage: 55,623 allocs, 55,546 frees
(was 44,283 frees)
This test is now 99.86% leak-free.
By propagating a 'ctx' parameter through these calls.
This fix happens to have no impact on glsl-orangebook-ch06-bump.frag,
(since it doesn't trigger any errors).
By simply propagating a 'ctx' parameter through these function
calls. (We do this because these function are otherwise only receiving
an exec_list, which is not a valid talloc context.)
This closes 1611 leaks in the glsl-orangebook-ch06-bump.frag test:
total heap usage: 55,623 allocs, 44,283 frees
(was 42,672 frees)
And fix all callers to use the tallbac-based new for exec_node
construction. We make ready use of talloc_parent in order to get
valid, (and appropriate) talloc owners for everything we construct
without having to add new 'ctx' parameters up and down all the call
trees.
This closes the majority of the memory leaks in the
glsl-orangebook-ch06-bump.frag test:
total heap usage: 55,623 allocs, 42,672 frees
(was 14,533 frees)
Now 76.7% leak-free. Woo-hoo!
And use the talloc-based new for all of the ast objects created by the
parser. This closes a lot of memory leaks, and will allow us to use
these ast objects as talloc parents in the future, (for things like
exec_nodes, etc.).
This closes 164 leaks in the glsl-orangebook-ch06-bump.frag test:
total heap usage: 55,623 allocs, 14,553 frees
(was 14,389 frees)
Two of these destructors are non-empty, (s_symbol and s_list), so this
commit could potentially introduce memory leaks, (though, no additional
leaks are found in glsl-orangebook-ch06-bump.frag at least---perhaps
the current code is never calling delete on these classes?).
Going forward, we will switch to talloc for exec_node so we won't need
explicit destrcutors to free up any memory used.
We take advantage of overloading of the new operator (with an
additional parameter!) to make this look as "C++ like" as possible.
This closes 507 memory leaks when compiling glsl-orangebook-ch06-bump.frag
when measured with:
valgrind ./glsl glsl-orangebook-ch06-bump.frag
as seen here:
total heap usage: 55,623 allocs, 14,389 frees
(was 13,882 frees before)
This is a short-lived object. It exists only for the duration of the
compile_shader() function, (as opposed to the shader and whole_program
which live longer).
The state is created with the same talloc parent as the shader, so
that other allocation can be done with talloc_parent(state) as the
owner in order to attach to a long-lived object.
My current reading of the relevant static functions suggests that last
is never used without being uninitialized, (we only use it if the
expansion function returned non-NULL and the expansion functions
always set it before returning non-NULL).
Apparently gcc isn't coming to the same conclusion. Initializing this
to NULL nicely quites gcc and will guarantee a nice, early segfault if
my anaylsis turns out to be wrong.
This block of code is useless because a (nearly-equivalent) assignment
is made immediately after. The only difference is the omission of
-Wunreadchable-code in the assignment being used. Presumably, that was
intended to be -Wunreachable-code (without the first 'd'), but since
this hasn't been being used we just drop it.
This prevents the two code paths from getting out of sync. Also, future
work will need the shader source as a string anyway.
Unfortunately, this copies and pastes load_text_file from main.cpp, with
small changes (support for reading from stdin, talloc).
Carl Worth
Eric Anholt
Kenneth Graunke
Ian Romanick