aboutsummaryrefslogtreecommitdiff
path: root/util/fluxbox-remote.cc
diff options
context:
space:
mode:
authorMathias Gumz <akira at fluxbox dot org>2011-10-22 22:01:45 (GMT)
committerMathias Gumz <akira at fluxbox dot org>2011-10-22 22:01:45 (GMT)
commitee34b376d768ecafc2fa21a79a854df503d1f115 (patch)
treeb6be7d0cbb8ae8899d5faa70ec1b7b9b478c62ad /util/fluxbox-remote.cc
parent3f76e117bf7735058f2b135beb72e015658f97eb (diff)
downloadfluxbox-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