Execute GetModOptionCount, crash in game The Cursed and Evolution RTS

try to execute in separate project, also crash

I guess the same issue

mantised: http://springrts.com/mantis/view.php?id=2916

unitsync.log is empty
how to turn it on ?

setting



in springsettings.cfg should enable some logging.

can you be more specific what functions you are calling?

this example doesn't crash: http://pastebin.com/R7izPY59

(written in python using the unitsync / ctypes wrapper from upq)

we call GetModOptionCount()

games that are 100% crash: The Cursed 1.16, Evoultion RTS 1.9
OS: Windows

we'll try to turn the logging

UnitSync crashed exactly after getModOptionCount in The Cursed 1.16.
By the way, can I change LOG_LEVEL_INFO?

abma was asking for what functions you are calling.
if you would really be calling only this one function, it would be no wonder that you crash, and i am sure you are not doing that.

i guess we can be somewhat sure that it is a problem that happens on windows only. that could mean it is related to a file-system call, or it has to do with access to non-explicitly initialized memory, or... maybe something else. :D

That's UnitSync Functions calls sequence that cause crash. Help me!!!

sorry, i don't get a crash here, when i try to call these functions on windows...


can you please run the program with an attached debugger and get a stacktrace?

Abma, spring must be in isolation mode in order to get the crash

it also doesn't crash for me in isolation-mode... :-/

please do a "bt full" with "gdb"...

Thx for responce :)
It's really weird crash. I can't catch exception by gdb, stack is not available. May be it's special to windows7 64 or mingw 4.4.0?

you need debug symbols for untisync. they can be found here for current latest release:
http://springrts.com/dl/buildbot/defaul ... ync_dbg.7z
extract this archive, and make sure that gdb uses the file. i think you do it with the -s symbol-file cmd-line switch (or some gdb console command).

It's too hard to me :) I'm not strong in gdb debuging. But I got trace at last.
It looks like exception raised by "throw content_error()" in Option.cpp raise another uncaught exception. Or something else... )))

nice!
thanks, and well done!

it looks like this archive contains bad options:
28f1e3632fb713d232c8c75f2373f2bf.sdp
this is a an archive managed by rapid, and as much as i know, you should be able to delete the file by hand, or .. maybe try to do a rapid cleanup first, and see if that removes it already.

edit:
to det/Licho/anyone else who knows... how can we find out the rapid tag that belongs to this archive, so we can test ourselfs?
thanks to jk, i found out that it is thecursed:version:1.16, will now extract mod options...

So why it cause crash? In code content_error created and crash is caused exactly by throw. It's strange, because I think exception must be caught and try to log error.
Of cause I can delete this file but where I can get good mod file. And what to do with broken archive?

P.S. I downloaded that archive just now using rapid_gui (The Cursed 1.16)

(i edited my last post)

modoptions.lua from thecursed:version:1.16
indeed we should catch that error and log it in unitsync (it is a bug).
also the cursed should be fixed of course.

to uninstall:
rapid unpin thecursed:version:1.16

You are pretty fast