Need some help to finalize AmigaOS4 port of AssaultCube

[kas1e]

Does a backtrace reveal anything? (type 'bt' in GDB)

GDB for us works a bit buggy (i contacted with authors of GDB port, they say that i should not belive to amigaos4 port of GDB, because its suck in current state).

But, as i know "bt" in GDB, mean "stack trace" ? If so, then we have in amigaos4 some kind of little-easy inbuild debugger, which generate stack trace info for every crash. And for the AC crash, it generate such stack trace:

ac_client:_ZN9vertmodel4part6renderEiifiP6dynent()+0x2C0 (section 7 @ 0x82e8c)
ac_client:_ZN3md36renderEiifiRK3vecffP6dynentP11modelattachf()+0x6F4 (section 7 @ 0x8434c)
ac_client:_Z11rendermodelPKciifRK3vecfffiP9playerentP11modelattachf()+0x304 (section 7 @ 0x75fd4)
ac_client:_ZN6weapon14renderhudmodelEii()+0x174 (section 7 @ 0xd1ef4)
ac_client:_Z10drawhudguniifi()+0xBC (section 7 @ 0x65524)
ac_client:_Z12gl_drawframeiiff()+0x764 (section 7 @ 0x69928)
ac_client:main()+0xE78 (section 7 @ 0x46e30)

That mean that from main calls gl_drawfram, from gl_drawfram cals drawhudguninif, and so on, and in end crash happenes on the latest (at top) line.

Then, by usage of "addr2line" program, i found, that:

15/0.MOS_WORK:ac> addr2line -e ac_client --section=.text 0x82e8c
vertmodel.h:870

And that line 870 in vertmodel, is that loopv (render meshes blablabla). Of course pretty possible, that bug only happenes here, but all the problems coming early, maybe in drawhudguniifi() or kind.

The other time, i got such stack trace on the same crash (when i turn everything off/0 in advanced-video options):

ac_client_with_line:_ZN9vertmodel4part6renderEiifiP6dynent()+0x2C0 (section 7 @ 0x82e8c)
ac_client_with_line:_ZN3md36renderEiifiRK3vecffP6dynentP11modelattachf()+0x358 (section 7 @ 0x83fb0)
ac_client_with_line:_Z11rendermodelPKciifRK3vecfffiP9playerentP11modelattachf()+0x304 (section 7 @ 0x75fd4)
ac_client_with_line:_Z15rendermapmodelsv()+0x1F8 (section 7 @ 0x3dc54)
ac_client_with_line:_Z11drawminimapii()+0x6A0 (section 7 @ 0x68f24)
ac_client_with_line:_Z12gl_drawframeiiff()+0xA8 (section 7 @ 0x6926c)
ac_client_with_line:main()+0xE78 (section 7 @ 0x46e30)

At this time bug again the same , but from other call (from rendermapmodelssv).

Pretty possible that its start to happenes in rendermodel-modelattach stuff. I check that address (0x75fd4):

15/0.MOS_WORK:ac> addr2line -e ac_client --section=.text 0x75fd4
rendermodel.cpp:451

Which are mean "m->endrender();".

Also for now i catch some more info, which can be interesting i think. I trying to run ac, and have in shell:

blablabl

init: localconnect
read map packages/maps/official/ac_douze.cgz rev 17 (173 milliseconds)
Douze (AC-Version) by makkE - layout by stanze
loaded textures (697 milliseconds)
loaded mapmodels (0 milliseconds)
loaded mapsounds (1441 milliseconds)
game mode is "TDM"
init: mainlooptwa

For first what is strange a bit for me, its 0 milliseconds for the loaded mapmodels.

And next interesting moment, that game before crash, show me the screen, which looks pretty fine:



And then imediately crash. Just by some luck i switch on the other screen while it loads, and because of "inactive" ac_screen, i can capture the screenshot. But then, when i make it active everything crashes with such stack trace which i show.

Another time, when i switch everything off in advanced video options, it loads one time, and i can move, run, but when i press fire, imidiately crash with the same stacktrace points.

That make me think, that : loading happens fine. Because if i see gun/hands, then all is loaded in memory already, and game are can load all of this correctly. But then a crash: maybe because of "redraw", maybe because of "rerendering the scene", but , crash happenes only when that line 870 in vertmodel.h are here => what also make me think, that there is something exactly related to handler of all that hands/guns/stuff maybe ?

Anyway, thank you already for all that help. I know its annoing to fix all that problems (which in end, very possible will be because of our opengl realisation) but for sure game can works here, just need to found what cause the problem..

---

Do some more depper "comment out" testings, and found, that game works as well (but without models/hands/guns), when i only commented these lines in rendermodel.cpp:

line 227:
m->render(b.anim, b.varseed, b.speed, b.basetime, b.o, b.yaw, b.pitch, b.d, a, b.scale);

and line 443:
m->render(anim, varseed, speed, basetime, o, yaw, pitch, d, a, scale);

So looks like bugs happenes here (and only later, they causes by line 870 in vertmodel.h in the loopv(render-meshes) function).

I think we can play with settings for that functions to found where is problem ? Like for example set "scale" to 0 all the time, and all the other possible values to static ones (one by one), to found in which one all the problems.