some problems with .sobj coding

	Bottom Previous Topic Next Topic
Register To Post

kas1e

Posted on: 2011/5/9 20:21 #1

Home away from home

I have working in last few days on some interesting game, design of which are heavy based on sobjes/plugins.

The game splitted on objects, which loads on the running stage from the code by some "loadplugins()" function. Most of those .sobjes can be done statically (not like .so, but as .a) and linking to the binary, but one of the sobjs are not uses even if i linked it as static, because main binary want to load it only via "loadplugins()".

And so, as result, when i have everytihng builded static (but have one that sobj are as .so), then of course i can't use it, and loadplugins() itself failed just because that latest sobj, want all the others. And by all that crap, i just forced to use shared version.

So, added all that -use-dynld, -fPIC, --export-dynamic where is need it, and when game starts, its start to load sobjes via loadplugin() , and, i happyly crashes in the libstdc++.so, with such crash log. In brief, stack trace looks like this:

Quote:

Symbol info:
Instruction pointer 0x7F5F5940 belongs to module "libstdc++.so" (PowerPC)
Symbol: _ZNSs6assignERKSs + 0x240 in section 10 offset 0x0006E940

Stack trace:
libstdc++.so:_ZNSs6assignERKSs()+0x240 (section 10 @ 0x6e940)
libmrt.so:_ZN3mrt9Exception11add_messageEPKci()+0xD8 (section 11 @ 0x2a0)
libmrt.so:_ZN3mrt9Directory6createERKSsb()+0x2F0 (section 11 @ 0x12f80)
libmrt.so:_ZN3mrt9Directory11get_app_dirERKSsS2_()+0x170 (section 11 @ 0x132a4)
libbtanks_engine.so:_ZN5IGameC1Ev()+0x2CC (section 13 @ 0x1e7f04)
libbtanks_engine.so:_ZN5IGame12get_instanceEv()+0xA8 (section 13 @ 0x1e862c)
btanks.exe:main()+0x224 (section 9 @ 0x410)
native kernel module newlib.library.kmod+0x00001f44
native kernel module newlib.library.kmod+0x00002b90
native kernel module newlib.library.kmod+0x00002d54
btanks.exe:_start()+0x170 (section 9 @ 0x170)
native kernel module dos.library.kmod+0x0001b524
native kernel module kernel.debug+0x00063d50
native kernel module kernel.debug+0x00063dd0

So, libbtanks_engine.so , trying to init game, going to libmrt.so, which do:

directory.cpp/get_app_dir(),
directory.cpp/directory_create(),
exception.cpp/add_message(),
crash in stdc++ in assign()

The function get_app_dir() are:

Quote:

const std::string Directory::get_app_dir(const std::string &name, const std::string &shortname) {
std::string path = "PROGDIR:" + shortname;
mrt::Directory dir;
try {
dir.create(path);
} catch(...) {}
return path;
}

If i comment out that part of code inside, then, its going futher, but of course later crashes as well in the libstdc++.so

I can think about bad code of course, but the same code works fine if i build it as static (and i can run the binary, it works, just exits on the stage when want to load that .sobj which can be only as sobj).

Have anyone any clue ?

Join us to improve dopus5!
AmigaOS4 on youtube

TSK

Re: some problems with .sobj coding

Posted on: 2011/5/9 20:41 #2

Just can't stay away

Here's one way to load plugins into memory. But you have to query addresses of all functions one by one:


struct Elf32_SymbolQuery query;

Elf32_Handle elfhandle,filehandle;

BPTR PluginSeglist=ZERO;

int32 (*PluginFunction1)();

int32 (*PluginFunction2)();



PluginSeglist=IDOS->LoadSeg("PluginFile");

IDOS->GetSegListInfoTags(PluginSeglist,GSLI_ElfHandle,&elfhandle,TAG_DONE);

filehandle=IElf->OpenElfTags(OET_ElfHandle,elfhandle,TAG_DONE);



query.Flags=ELF32_SQ_BYNAME;

query.Name="PluginFunction1";

IElf->SymbolQuery(filehandle,1,&query); // query.Value (uint32) has the result

PluginFunction1=(APTR)query.Value;



query.Flags=ELF32_SQ_BYNAME;

query.Name="PluginFunction2";

IElf->SymbolQuery(filehandle,1,&query); // query.Value (uint32) has the result

PluginFunction2=(APTR)query.Value;



IElf->CloseElfTags(filehandle,CET_CloseInput,TRUE,TAG_DONE);

I don't know if this helps in your case.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray

kas1e

Re: some problems with .sobj coding

Posted on: 2011/5/9 21:08 #3

Home away from home

@TSK
Quote:

Here's one way to load plugins into memory. But you have to query addresses of all functions one by one:

Its not my code as usuall, and there is all dependeces depend on other dependeces in code, and just putting to the begining of main() loading of that sobj, will not helps (imho). Because game later trying to register classes, which they parse by some resourcemanager.cpp , when its loaded via loadplugins().

And, in end of all, that .so also want others so (which in end will cause the same crash).

As i see there is 2 ways:

1. understand why it crashes (i remember someone saing back in times, that our sobjes cant catch exceptions normally, with all that catch() stuff, so maybe it is the same bug

2. trying to get code of that "really necessary" single sobjs, register somehow all the classes manually in the code, and put that code not to so, but to .a, and link it statically (i tryed it before, but what was a bit strange for me, its the with or without that .a , size of binary do not changes, what make me think, that no one single fucntion of that sobj, by some reassons not uses directly from the main binary.

Second way sounds prefferable for me, because with static version i even have something on screen already, just game can't register all the classes which are in that sobj. In end of all will try to contact with authors, maybe they will help to build it statically.

Join us to improve dopus5!
AmigaOS4 on youtube

afxgroup

Re: some problems with .sobj coding

Posted on: 2011/5/10 9:16 #4

Amigans Defender

remove libstdc++.so from SDK and use the .a instead.. Actually is the only solution

i'm really tired...

kas1e

Re: some problems with .sobj coding

Posted on: 2011/5/10 11:30 #5

Home away from home

@afxgroup
That is good idea indeed !

Btw, for now i remove all the stdc++.so from sdk, so, libstdc++.a are used, but what is interesting, is that i use libSDL_Mixer.so (latest from os4depot), which are compiled with libstd++.so.

And as result i have that:

No binary, no all my builded sobjs not reles on the libstdc++.so. But because libSDL_Mixer.so reles to libstdc++.so, looks like mixer automatically up libstdc++, and all the sobjs and main binary by some reassons start to use libstdc++ for all the other code as well, and as result , the same crash.

But for me its a bit strange, because i was in hope, that libstdc++ will be used _only_ for sdl_mixer.so (because only mixer want it now), but not like it now : just for all the code.

Anyway, i just use libSDL_Mixer as static, and , what is funny i again have the same crash ! but at this moment not in the libstd++.so, but in my own , game's, libsdlx.so:

Quote:

Symbol info:
Instruction pointer 0x7F69F7F0 belongs to module "libsdlx.so" (PowerPC)
Symbol: _ZNSs6assignERKSs + 0x10C in section 13 offset 0x000654FC

Stack trace:
libsdlx.so:_ZNSs6assignERKSs()+0x10C (section 13 @ 0x654fc)
libmrt.so:_ZN3mrt9Exception11add_messageEPKci()+0xD0 (section 11 @ 0x298)
libmrt.so:_ZN3mrt9Directory6createERKSsb()+0xCC (section 11 @ 0x12fcc)
libmrt.so:_ZN3mrt9Directory11get_app_dirERKSsS2_()+0x1A8 (section 11 @ 0x13554)
libbtanks_engine.so:_ZN5IGameC1Ev()+0x2D0 (section 13 @ 0x1d2efc)
libbtanks_engine.so:_ZN5IGame12get_instanceEv()+0x80 (section 13 @ 0x1d3650)
btanks.exe:main()+0x224 (section 9 @ 0x410)
native kernel module newlib.library.kmod+0x00001f44
native kernel module newlib.library.kmod+0x00002b90
native kernel module newlib.library.kmod+0x00002d54
btanks.exe:_start()+0x170 (section 9 @ 0x170)
native kernel module dos.library.kmod+0x0001b524
native kernel module kernel.debug+0x00063d50
native kernel module kernel.debug+0x00063dd0

Strange why it before point on libstdc++.so, and not on libsdlx.so ?

Anyway, it point on surface:assign fucntion, from the sdlx.so , which are:

Quote:

Surface::Surface():surface(NULL) {}
Surface::Surface(SDL_Surface *x) : surface(x) {}

void Surface::assign(SDL_Surface *x) {
free();
surface = x;
}

(and that code work in static version of cource, because i see how sdl window initialized, i can see first menu, etc). The only problem that it crashes there in shared version of code.

Edited by kas1e on 2011/5/10 11:47:52
Edited by kas1e on 2011/5/10 11:49:45

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: some problems with .sobj coding

Posted on: 2011/5/10 17:38 #6

Home away from home

It was a pain, and one more time saying for me that heavy usage of sobjes together with all that c++ stuff on aos4 its still buggy.

How i fix the stuff in end:

I include all the code from that single sobj which are necessary for loadplugins(), and with some small modifications put in the main code, compile everything statically and remove loadplugins(); Then some more problems there and there, and in end of all:

screen1
screen2
screen3

Works pretty stable and fast on peg2/1ghz, and still need to fix some stuff with sounds before releasing

Join us to improve dopus5!
AmigaOS4 on youtube

Register To Post
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )