diff options
author | Mathias Gumz <akira at fluxbox dot org> | 2011-10-22 22:01:45 (GMT) |
---|---|---|
committer | Mathias Gumz <akira at fluxbox dot org> | 2011-10-22 22:01:45 (GMT) |
commit | ee34b376d768ecafc2fa21a79a854df503d1f115 (patch) | |
tree | b6be7d0cbb8ae8899d5faa70ec1b7b9b478c62ad /util/fluxbox-remote.cc | |
parent | 3f76e117bf7735058f2b135beb72e015658f97eb (diff) | |
download | fluxbox-ee34b376d768ecafc2fa21a79a854df503d1f115.zip fluxbox-ee34b376d768ecafc2fa21a79a854df503d1f115.tar.bz2 |
Bugfix: clean up static resources correctly
93924af160ea303c94a2576b0e57a04e94c9228c might corrupt memory with gcc-4.6.1 when
finishing fluxbox (clicking 'exit', sending it a SIGINT). Allthough the order, in which static / global
objects are initialized is undefined (at least between separate compilation units), the order in
which they are destroyed is well defined: in reverse order of initialization.
this means, that if 'ScreenImlibContextContainer contexts' (of ImageImlib2.cc)
gets initialized AFTER 'ImageImlib2 imlib2_loader' of Image.cc, it gets destroyed before
imlib2_loader. When that happens, ~ImageImlib2() works on a destroyed object.
(That lead to '* glibc detected * fluxbox: corrupted double-linked list: 0x0000000000dd2710 ***'
later on in 'iconv_close')
Diffstat (limited to 'util/fluxbox-remote.cc')
0 files changed, 0 insertions, 0 deletions