loading libunitsync.so will break for gcc 5.x executables

loading libunitsync.so will break for gcc 5.x executables

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
abma
Spring Developer
Posts: 3552
Joined: 01 Jun 2009, 00:08

loading libunitsync.so will break for gcc 5.x executables

Post by abma » 29 Jan 2016, 02:21

currently a gcc 5.x executable loading libunitsync.so will crash with some weird errors. the linux static builds are (afaik) compiled with gcc 4.8.

sadly there is no easy solution: to keep the existing way unitsync is used, the program which loads unitsync needs to be compiled with the same compiler version. maybe see https://github.com/springlobby/springlobby/issues/624

afaik flobby / springlobby / weblobby are or will be affected.

possible (IMHO) realistic solutions:

1. create some executable which is shipped with spring static builds which exposes api via tcp
2. use a lobby client only for online playing / download required stuff from webserver (as zk afaik does) and use "inengine" stuff for singleplayer / offline stuff. this very likely would break hosting without the help of an autohost.
... ?

1. has the benefit that it could be used by all lobbies and all online services. also some prototype exists, but atm it only writes stuff to disk: https://github.com/springlobby/lsl/issues/4

also they don't exclude each other, both could be done.

anyone with a better idea / did i miss something?
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: loading libunitsync.so will break for gcc 5.x executables

Post by Kloot » 29 Jan 2016, 02:47

Ehm, all the unitsync API functions have plain C linkage... did gcc5 break that too or is this a deeper issue?
0 x

Super Mario
Posts: 814
Joined: 21 Oct 2008, 02:54

Re: loading libunitsync.so will break for gcc 5.x executables

Post by Super Mario » 29 Jan 2016, 03:11

Did you contact the gcc developers about this?
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: loading libunitsync.so will break for gcc 5.x executables

Post by gajop » 29 Jan 2016, 09:47

Both seem like very drastic steps that will break a lot of applications.

I'd much rather investigate it a bit more to see if a better solution can be found that would offer backward compatibility. If not, just require GCC 4.x for now.

PS: Nothing stopping you from trying both of your ideas, just don't drop libunitsync.
0 x

abma
Spring Developer
Posts: 3552
Joined: 01 Jun 2009, 00:08

Re: loading libunitsync.so will break for gcc 5.x executables

Post by abma » 29 Jan 2016, 10:43

Kloot wrote:did gcc5 break that too or is this a deeper issue?
yes, it seems. i still can hope a bit that i'm wrong, but it seems so. unitsync crashes somewhere when freeing sth. in boost::path.

without addresssanitizer:
*** Error in `./springlobby': free(): invalid pointer: 0x00007fce3402b4a8 ***

address sanitizer:
http://paste.springfiles.com/view/raw/67c8cc44

i'll try with a simple test-app, but cleanrock stepped with flobby into a very similar problem, too. see viewtopic.php?f=64&t=28000&start=20#p574915


hmm, with some more sleep, maybe there is a 3.:

3. static link libc into unitsync


(sorry for the wild guesses, atm i still don't fully understand the problem.)

edit:
it crashes in __cxa_finalize:

"call destructors of global (or local static) C++ objects and exit functions registered with atexit"

https://refspecs.linuxbase.org/LSB_3.2. ... alize.html

this leads to an other possible solution:

4. get rid of all static non-basic data types (i.e. std::string / std::vector / ...)

not sure if thats trivial, unitsync needs to dynamic allocate the memory when loading and free it when unloading:

i.e.

Code: Select all

static std::string lastError;
becomes:

Code: Select all

class CVars {
std::string lastError
};

EXPORT(int) Init(bool isServer, int id)
...
vars = new CVars();
...

EXPORT(void) UnInit()
...
SafeDelete(vars);
...


0 x

User avatar
Silentwings
Moderator
Posts: 3589
Joined: 25 Oct 2008, 00:23

Re: loading libunitsync.so will break for gcc 5.x executables

Post by Silentwings » 29 Jan 2016, 12:48

It would seem very odd to me if gcc had broke basic C linkage compatibility and not put a big hairy warning somewhere in the release notes (and I don't see one). There is http://developerblog.redhat.com/2015/02 ... e-c11-abi/, but the errors that claims too produce don't obviously match these ones.
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: loading libunitsync.so will break for gcc 5.x executables

Post by Kloot » 29 Jan 2016, 12:51

abma wrote: it crashes in __cxa_finalize:

"call destructors of global (or local static) C++ objects and exit functions registered with atexit"
ah, seems like the old "memory that is allocated in the lib should be freed in the lib" requirement isn't satisfied then (meaning it was only not exposed as a problem sooner because of compatible ABI's)
abma wrote:not sure if thats trivial, unitsync needs to dynamic allocate the memory when loading and free it when unloading
yup, no more non-POD globals or local statics (in *any* code compiled into unitsync, so e.g. FileSystem needs to be checked too)

note: this will also affect AI's
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: loading libunitsync.so will break for gcc 5.x executables

Post by AF » 31 Jan 2016, 11:14

Unitsync should be a cli program not a library, and its output should be json/xml/standard format data that can be loaded by whatever program or processing mechanism desired. It would make development of tools significantly easier, make unitsync a lot more testable, and completely sidestep issues such as this
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: loading libunitsync.so will break for gcc 5.x executables

Post by gajop » 31 Jan 2016, 11:41

AF wrote:Unitsync should be a cli program not a library, and its output should be json/xml/standard format data that can be loaded by whatever program or processing mechanism desired. It would make development of tools significantly easier, make unitsync a lot more testable, and completely sidestep issues such as this
Nothing's stopping you from making a JSON/whatever wrapper, but C libraries are a standard and very useful to have.
0 x

abma
Spring Developer
Posts: 3552
Joined: 01 Jun 2009, 00:08

Re: loading libunitsync.so will break for gcc 5.x executables

Post by abma » 01 Feb 2016, 19:19

small update:

it seems that it doesn't crash when springlobby doesn't use boost/filesystem. not sure why it works without it. needs a bit more testing.

flobby which suffers from this problem also uses boost/filesystem, so... needs testing :)
0 x

User avatar
AF
AI Developer
Posts: 20669
Joined: 14 Sep 2004, 11:32

Re: loading libunitsync.so will break for gcc 5.x executables

Post by AF » 07 Feb 2016, 15:56

gajop wrote:Nothing's stopping you from making a JSON/whatever wrapper, but C libraries are a standard and very useful to have.

My recommendation is a "unitsync.exe", I believe any efforts would be better spent building this rather than a complex work around such as a TCP back-channel, as it provides the same information, but in a more flexible format, with additional options ( such as a basic interface for shell scripting, completely decoupled wrapper tools etc ). We already have a cache file which means half the work has already been done
0 x

abma
Spring Developer
Posts: 3552
Joined: 01 Jun 2009, 00:08

Re: loading libunitsync.so will break for gcc 5.x executables

Post by abma » 07 Feb 2016, 16:06

AF wrote:My recommendation is a "unitsync.exe", I believe any efforts would be better spent building this rather than a complex work around such as a TCP back-channel, as it provides the same information, but in a more flexible format, with additional options ( such as a basic interface for shell scripting, completely decoupled wrapper tools etc ). We already have a cache file which means half the work has already been done
without ipc it can't be used in a lot of services, its not worth the effort. also such an executable basicly already exists in lsl, see my first post.
0 x

Post Reply

Return to “Engine”