object to a just-initialized state. deflateEnd() is correct (no comment
needed for that; it's obvious, I don't know why I used deflateReset to
begin with).
zlib doesn't appear to do anything special with allocations; running
the following:
#include <zlib.h>
main()
{
z_stream z; z.zalloc = NULL; z.zfree = NULL;
inflateInit2( &z, -MAX_WBITS ); inflateReset( &z );
}
under Valgrind shows:
==17033== 7080 bytes in 1 blocks are possibly lost in loss record 1 of 1
==17033== at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
==17033== by 0x1B91D4B4: zcalloc (in /usr/lib/libz.so.1.2.1.2)
==17033== by 0x1B91D608: inflateInit2_ (in /usr/lib/libz.so.1.2.1.2)
==17033== by 0x80485A4: main (in /home/glenn/a.out)
The reason that only some people were experiencing a major memory leak
was that it had to do with packages, a lot of devs don't use packages.
This leak could not be found through conventional methods, as zlib's ram
seems to be allocated from the global ram.
didn't make it work, since there was no cast overload to bool&, etc; it
just forced the (non-POD) type to that type, which resulted in the struct
being clobbered.
- eventually, this will reduce the gargantuan PrefsManager
- adding prefs doesn't require modifying PrefsManager.h and recompiling a lot
- starting with these options because they aren't in ScreenOptionsMaster
re-locking it. In some threads implementations (Linux 2.6), this causes the
mount thread to hog the lock, which causes SetMountThreadState to hang. Move
the "check and delay" part of the mount thread outside of the lock, so other
threads have opportunity to get the lock.
"DisableRadar=0 // turn this to 1 if you are experiencing trouble with the groove radar (voodoo3's)"
Theme metrics are not the correct place for dealing with driver bugs; users
can't be told to hack metrics.ini to make their system work. (I havn't seen
any reports of problems here in a long time, anyway.)
Chris Danford