Log and globals initialization and finalization/destruction fix

[jimfcarroll]

This fix uses a singleton pattern and some compiler/cpreprocessor sugar to allow "global" variables to be lazy instantiated and initialized and moved from the BSS segment to the heap (that is, they are instantiated on the heap when they are first used rather than relying on the startup code to initialize the BSS segment). This eliminates the problem associated with global variable dependencies across compilation units.

Reference counting from the BSS segment is used to destruct these globals at the time the last compilation unit that knows about it is finalized by the post-main shutdown. The book keeping is done by smuggling a smart pointer into every file that references a particular "global class" through the use of a 'static' declaration of an instance of that smart pointer in the header file of the global class (did you ever think you'd see a file scope 'static' variable in a header file - on purpose?)

See xbmc/utils/ReferenceCounting.h/cpp.

I built and ran this under Ubuntu, Windows OpenGL, and Mac OS X. I could only build (but not run) the Windows DX configuration.

Currently I know, on Mac OS X, there is at least one more global in the LinuxVideoRenderer* that causes a CRITSEC error. I'll fix that on a subsequent update along with everything else in SystemGlobals.cpp.

[elupus]

This still suffers the destruction order issues (since you reference count based on compilation units). Old code atleast controlled construction/destruction order. So can't see what it really improves since our major issues have been destruction not construction asfar as i know.

[jimfcarroll]

You lost me. This prevents the use of de-initalized variables during destruction and forces the order of destruction to be natural according to use. As evidence that this certainly solves SOMETHING, several of the CRITSEC errors, which occur when someone uses a CCriticalSection after it's been destructed, have been eliminated, precisely because of this. How many other places does the use of an uninitialized object happen that we don't know about because we don't have code that checks? Also those CCriticalSections are not leaked as a result.

I think you missed the point of reference counting by compilation unit. It is true that a particular compilation unit could have been uninitialized, and therefore have decremented it's reference count, but still have code that ends up executing and referencing the 'global.' That works fine. The reference counting simply determines the point in time when NO ONE needs the object anymore - and therefore it can be deleted.

[jimfcarroll]

As a quick additional note, I had a conversation with davilla about simply allowing the globals to leak - then we wouldn't have any issues during destruction. This is not an option on platforms where the xbmc app itself is run essentially as a "plugin." Hence the need to get the reference counting right.

[elupus]

Yup.. i missed the point that there is seperate refcounted objects in each compilation unit that uses the global.

[Fneufneu]

it broke the build on FreeBSD: final linking failed:

g++ -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -D_DEBUG -Wall -O2 -I/usr/local/include -fPIC -DPIC -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -D_DEBUG -Wall -O2 -I/usr/local/include -L/usr/local/lib -L/usr/local/lib -o xbmc.bin -Wl,--whole-archive lib/cmyth/libcmyth/libcmyth.a lib/cmyth/librefmem/librefmem.a xbmc/linux/linux.a xbmc/network/network.a xbmc/video/windows/videowindows.a xbmc/utils/utils.a xbmc/cores/DllLoader/exports/util/exports_utils.a xbmc/cores/DllLoader/exports/exports.a xbmc/settings/settings.a xbmc/video/video.a xbmc/guilib/guilib.a  xbmc/xbmc.a xbmc/addons/addons.a xbmc/cores/playercorefactory/playercorefactory.a xbmc/cores/dvdplayer/DVDPlayer.a xbmc/cores/paplayer/paplayer.a xbmc/cores/VideoRenderers/VideoRenderer.a xbmc/cores/VideoRenderers/VideoShaders/VideoShaders.a lib/tinyXML/tinyxml.a xbmc/cores/cores.a xbmc/interfaces/python/python.a xbmc/cores/DllLoader/dllloader.a xbmc/cores/dvdplayer/DVDCodecs/DVDCodecs.a xbmc/cores/dvdplayer/DVDCodecs/Audio/Audio.a xbmc/cores/dvdplayer/DVDCodecs/Overlay/Overlay.a xbmc/cores/dvdplayer/DVDCodecs/Video/Video.a xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxers.a xbmc/cores/dvdplayer/DVDInputStreams/DVDInputStreams.a xbmc/cores/dvdplayer/DVDSubtitles/DVDSubtitles.a xbmc/cores/AudioRenderers/audiorenderers.a xbmc/cores/ExternalPlayer/ExternalPlayer.a xbmc/filesystem/filesystem.a xbmc/filesystem/MusicDatabaseDirectory/musicdatabasedirectory.a xbmc/filesystem/VideoDatabaseDirectory/videodatabasedirectory.a xbmc/input/input.a xbmc/dialogs/dialogs.a xbmc/music/karaoke/karaoke.a xbmc/music/music.a xbmc/music/dialogs/musicdialogs.a xbmc/music/infoscanner/musicscanner.a xbmc/music/tags/musictags.a xbmc/music/windows/musicwindows.a xbmc/video/dialogs/videodialogs.a xbmc/pictures/pictures.a xbmc/playlists/playlists.a xbmc/programs/programs.a xbmc/powermanagement/powermanagement.a xbmc/storage/storage.a xbmc/threads/threads.a xbmc/windows/windows.a xbmc/interfaces/python/xbmcmodule/xbmcmodule.a xbmc/network/libscrobbler/scrobbler.a lib/libRTV/librtv-x86_64-freebsd.a lib/libUPnP/libupnp-x86_64-freebsd.a lib/libXDAAP/libxdaap-x86_64-freebsd.a xbmc/interfaces/interfaces.a xbmc/cdrip/cdrip.a xbmc/interfaces/json-rpc/json-rpc.a lib/jsoncpp/src/lib_json/libjsoncpp.a xbmc/interfaces/http-api/http-api.a xbmc/dbwrappers/dbwrappers.a lib/libsquish/libsquish-x86_64-freebsd.a lib/libapetag/.libs/libapetag.a lib/xbmc-dll-symbols/dll-symbols.a xbmc/rendering/rendering.a xbmc/windowing/windowing.a  xbmc/rendering/gl/rendering_gl.a lib/libXBMS/libxbms-x86_64-freebsd.a lib/UnrarXLib/UnrarXLib.a lib/libhts/libhts.a xbmc/threads/posix/threads_posix.a xbmc/network/linux/network_linux.a xbmc/powermanagement/linux/powermanagement_linux.a xbmc/storage/linux/storage_linux.a xbmc/windowing/X11/windowing_X11.a -Wl,--no-whole-archive -lavcodec -lXrandr -lavahi-client -lavahi-common -lSDL_image -lrt -ltiff -ljasper -lSDL_mixer -lsmbclient -lfaad -lmysqlclient -lmodplug -lmpeg2convert -lmpeg2 -lwavpack -lcrypto -lssl -lz -llzo2 -pthread -ljpeg -lbz2 -lGLU -lGLEW -lGL  -L/usr/local/lib -lmad -lm   -L/usr/local/lib -lfribidi   -L/usr/local/lib -lsqlite3   -L/usr/local/lib -lpng -lz -lm   -L/usr/local/lib -lpcre   -L/usr/local/lib -lpcre -lpcrecpp   -L/usr/local/lib -lcdio -lm -lcam   -L/usr/local/lib -lsamplerate   -L/usr/local/lib -lfreetype   -L/usr/local/lib -logg   -L/usr/local/lib -lvorbis -lm -logg   -L/usr/local/lib -lvorbisenc -lvorbis -lm -logg   -L/usr/local/lib/mysql -lmysqlclient -lz -lcrypt -lm -L/usr/local/lib -lasound   -L/usr/local/lib -lenca -lm   -L/usr/local/lib -lXt -lX11 -lSM -lICE   -L/usr/local/lib -lXtst   -L/usr/local/lib -lXext   -L/usr/local/lib -lXmu -lXt -lX11 -lSM -lICE   -pthread -L/usr/local/lib -ldbus-1   -Wl,-rpath,/usr/local/lib -pthread -L/usr/local/lib -lSDL   -pthread -L/usr/local/lib -lhal -ldbus-1   -pthread -L/usr/local/lib -lhal-storage -lhal -ldbus-1   -L/usr/local/lib -lavcodec -lavformat -lavutil -lpostproc -lswscale   -rdynamic
xbmc/cores/DllLoader/dllloader.a(ldt_keeper.o)(.text+0x1a0): In function `Setup_LDT_Keeper':
/usr/home/fneufneu/xbmc/xbmc/cores/DllLoader/ldt_keeper.c:244: undefined reference to `i386_set_ldt'
gmake: *** [xbmc.bin] Error 1

[jimfcarroll]

Looking at the code, I don't understand how my changes are related to that missing reference (not that they aren't). My Makefile.in change simply moved all of the static libraries to --whole-archive, and this is more flexible, not less. Looking at your fork the Makefile.in is the same as prior to my changes.

xbmc.bin: $(OBJSXBMC) $(DYNOBJSXBMC)
ifeq ($(findstring osx,@ARCH@), osx)
    $(CXX) $(LDFLAGS) -o xbmc.bin -Wl,-all_load,-ObjC $(DYNOBJSXBMC) $(OBJSXBMC) $(LIBS) -rdynamic
else
    $(CXX) $(CXXFLAGS) $(LDFLAGS) -o xbmc.bin -Wl,--whole-archive $(DYNOBJSXBMC) $(OBJSXBMC) -Wl,--no-whole-archive $(LIBS) -rdynamic
endif

Looking at the code, the pertinent section of the ldt_keeper.c file is the same in both (besides the fact that there's not a single reference to a global in the .c file).

Also, this builds under OS X which seems to have the same block of code included and used in ldt_keeper.c.

Do you know where that symbol is supposed to be resolved to?
Is that library on the link line?
If so, does it appear after dllloader.a (I believe it would need to unless it's in the --whole-archive section of the link - stupid single pass linker:) )?

[jimfcarroll]

Fneufneu, I added a branch with a FreeBSD fix for you to test. It should build now. If it does it should address your crash-on-exit issue. Let me know. There's another possibility for the crash on exit problem in the CLinuxRenderer - which is one of the many globals I didn't get to yet. If it still crashes, let me know and I'll do that one next.

[jimfcarroll]

FneuFneu reports that this is fixed, and SO FAR, has alleviated the crash-on-exit issue he was experiencing.