mantarimay/Aegisub
1
0
Fork 0
forked from mia/Aegisub
Code Pull requests Activity
Aegisub/aegisub/libass/ass_cache_template.h

119 lines
3.7 KiB
C
Raw Normal View History

Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
#ifdef CREATE_STRUCT_DEFINITIONS
#undef CREATE_STRUCT_DEFINITIONS
#define START(funcname, structname) \
typedef struct structname {
#define GENERIC(type, member) \
type member;
#define FTVECTOR(member) \
FT_Vector member;
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
#define BITMAPHASHKEY(member) \
bitmap_hash_key_t member;
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
#define END(typedefnamename) \
} typedefnamename;
#elif defined(CREATE_COMPARISON_FUNCTIONS)
#undef CREATE_COMPARISON_FUNCTIONS
#define START(funcname, structname) \
static int funcname##_compare(void *key1, void *key2, size_t key_size) \
{ \
struct structname *a = key1; \
struct structname *b = key2; \
return // conditions follow
#define GENERIC(type, member) \
a->member == b->member &&
#define FTVECTOR(member) \
a->member.x == b->member.x && a->member.y == b->member.y &&
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
#define BITMAPHASHKEY(member) \
bitmap_compare(&a->member, &b->member, sizeof(a->member)) &&
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
#define END(typedefname) \
1; \
}
#elif defined(CREATE_HASH_FUNCTIONS)
#undef CREATE_HASH_FUNCTIONS
#define START(funcname, structname) \
static unsigned funcname##_hash(void *buf, size_t len) \
{ \
struct structname *p = buf; \
unsigned hval = FNV1_32A_INIT;
#define GENERIC(type, member) \
hval = fnv_32a_buf(&p->member, sizeof(p->member), hval);
#define FTVECTOR(member) GENERIC(, member.x); GENERIC(, member.y);
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
#define BITMAPHASHKEY(member) { \
unsigned temp = bitmap_hash(&p->member, sizeof(p->member)); \
hval = fnv_32a_buf(&temp, sizeof(temp), hval); \
}
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
#define END(typedefname) \
return hval; \
}
#else
#error missing defines
#endif
// describes a bitmap; bitmaps with equivalents structs are considered identical
START(bitmap, bipmap_hash_key_s)
GENERIC(char, bitmap) // bool : true = bitmap, false = outline
GENERIC(ass_font_t *, font)
GENERIC(double, size) // font size
GENERIC(uint32_t, ch) // character code
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
FTVECTOR(outline) // border width, 16.16 fixed point value
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
GENERIC(int, bold)
GENERIC(int, italic)
GENERIC(char, be) // blur edges
GENERIC(double, blur) // gaussian blur
GENERIC(unsigned, scale_x) // 16.16
GENERIC(unsigned, scale_y) // 16.16
GENERIC(int, frx) // signed 16.16
GENERIC(int, fry) // signed 16.16
GENERIC(int, frz) // signed 16.16
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
GENERIC(int, fax) // signed 16.16
GENERIC(int, fay) // signed 16.16
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
// shift vector that was added to glyph before applying rotation
// = 0, if frx = fry = frx = 0
// = (glyph base point) - (rotation origin), otherwise
GENERIC(int, shift_x)
GENERIC(int, shift_y)
FTVECTOR(advance) // subpixel shift vector
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
FTVECTOR(shadow_offset) // shadow subpixel shift
GENERIC(unsigned, drawing_hash) // hashcode of a drawing
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
END(bitmap_hash_key_t)
// describes an outline glyph
START(glyph, glyph_hash_key_s)
GENERIC(ass_font_t *, font)
GENERIC(double, size) // font size
GENERIC(uint32_t, ch) // character code
GENERIC(int, bold)
GENERIC(int, italic)
GENERIC(unsigned, scale_x) // 16.16
GENERIC(unsigned, scale_y) // 16.16
FTVECTOR(advance) // subpixel shift vector
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
FTVECTOR(outline) // border width, 16.16
GENERIC(unsigned, drawing_hash) // hashcode of a drawing
GENERIC(unsigned, flags) // glyph decoration flags
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
END(glyph_hash_key_t)
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
// Cache for composited bitmaps
START(composite, composite_hash_key_s)
GENERIC(int, aw)
GENERIC(int, ah)
GENERIC(int, bw)
GENERIC(int, bh)
GENERIC(int, ax)
GENERIC(int, ay)
GENERIC(int, bx)
GENERIC(int, by)
BITMAPHASHKEY(a)
BITMAPHASHKEY(b)
END(composite_hash_key_t)
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
#undef START
#undef GENERIC
#undef FTVECTOR
Update libass to 15df37. Originally committed to SVN as r3102.
2009-07-11 17:48:50 +02:00
#undef BITMAPHASHKEY
Plug a bunch of memory leaks from uau in the mplayer2 repo: http://repo.or.cz/w/mplayer.git?a=commit;h=312d9e4b104741b834aa5d71b02228d0cd988a4e libass: Fix cache lookup problem causing memory bloat The cache code did hash lookups by storing key values in struct fields and then hashing and comparing the struct as a single memory block. In at least one case such a struct contained uninitialized padding bytes which prevented the complete memory area of the struct from matching even though the fields did. As a result the code failed to find existing objects in the cache and stored new versions of them, causing gigabytes of memory use in some circumstances. Initializing the struct memory to zero before writing the fields avoided such memory use in tests but is not guaranteed to work if I interpret the C standard correctly (the compiler is allowed to write garbage over padding bytes when changing struct member values). Change the code to use struct-specific hashing and comparison functions that work field by field to guarantee correct behavior. Create these by replacing the struct definition with a template that lists the fields and can be used the generate each of struct definition, hash function and compare function with some preprocessor magic (otherwise every field would need to be listed separately in all three). Originally committed to SVN as r2895.
2009-05-04 08:48:21 +02:00
#undef END
Copy permalink