[PATCH] Crash when moving large masses of soldiers

[sireus]

The following happens ocasionally after 20 minutes or so of playing, with lots of soldiers (30-40) and few other units.

Now, if I select as many soldiers as I can (selection limit) and then try move them to another location, the game crashes. Remember, this does not happen every time (I'd say every tenth attempt, but that's just guessing) and is quite hard to reconstruct exactly. It just happens.

Judging from the crashlog, I'd say it's a bug in the sound manager, but I don't have any experience with the code, so don't listen to me :)

As far as I an tell, it doesn't matter on which map I'm playing, and I haven't yet found any other patterns.

[sireus]

crashlog

[sireus]

crashlog

[(none)]

Milestone Unclassified deleted

[sireus]

Debugging output

[Jan Wassenberg]

Bummer, that's not good. I've not been able to repro this on Windows (despite moving lots of troops around on the combat-demo-huge map).

Is there any chance you could add printfs to srcs_insert and srcs_remove to see if there's anything out of the ordinary? Knowing whether insert/remove are mismatched, or if random corruption is occurring would help a lot.

[sireus]

First of all, sorry for the late reply. Unfortunately I just changed OS (now using Arch instead of Ubuntu), so even I can't reproduce it any more. Until now everything works.

[Сергей]

combat-demo-huge map crashed every time I start it.

[Сергей]

all my logs

[Сергей]

0ad > 0adoutput.txt

[Kieran P]

Closing this as 'works for me' until you can reproduce it again. The path finding was altered a fair bit in Alpha 3, so this (hopefully) is no longer an issue.

[Сергей]

1)open combat demo (hudge) 2)atack 3)wait 7-15 seconds

it crash every time i try to do this. xmessage says: Assetrtion failed: "0" Location: snd_mgr.cpp:492 (srcs_remove)

Call stack:

(0x8285d72) /usr/games/pyrogenesis() [0x8285d72] (0x82570b8) /usr/games/pyrogenesis() [0x82570b8] (0x8257f93) /usr/games/pyrogenesis() [0x8257f93] (0x8258155) /usr/games/pyrogenesis() [0x8258155] (0x827a684) /usr/games/pyrogenesis() [0x827a684] (0x827ae4c) /usr/games/pyrogenesis() [0x827ae4c] (0x827018e) /usr/games/pyrogenesis() [0x827018e] (0x827a797) /usr/games/pyrogenesis() [0x827a797] (0x827b6ba) /usr/games/pyrogenesis() [0x827b6ba] (0x827baf4) /usr/games/pyrogenesis() [0x827baf4] (0x8055dd4) /usr/games/pyrogenesis() [0x8055dd4] (0x8056d4d) /usr/games/pyrogenesis() [0x8056d4d] (0xa3dce7) /lib/libc.so.6(libc_start_main+0xe7) [0xa3dce7] (0x80550d1) /usr/games/pyrogenesis() [0x80550d1]

errno = 0 (?) OS error = ?

OS Ubuntu 10.10, radeon hd2400(catalist 10.11) what can i do to give more information?

[Kieran P]

Is this using the just released Alpha 3 version? If not, please upgrade and try it on that.

Much has changed. I was not able to reproduce this problem.

[Сергей]

I use 8832 version.

[Kieran P]

Ok. Reopening for Alpha 4.

When you get this again, please post steps, and the crash logs.

[Сергей]

I can do this as many times as you need. It crashed every time I try to play this map and in some other maps.

I have already post steps and logs. What can I do to add more helpfull information?

[fabio]

I can confirm this happening. My backtrace is the same of what already attached here.

[Jan Wassenberg]

ImG: thanks for offering :) To understand this, we need more than the backtrace, since something is apparently going wrong before the actual crash. This is what my prinf request above was aimed at. Do you have a bit of dev experience and would you be able to tackle that?

@everyone: we can work around this bug by starting with -quickstart to disable sound.

[Philip Taylor]

#716 has a different way to reproduce this error.

[passerby]

Ok now I see my first assumptions were all wrong.

I also encounter the bug on ubuntu btw.

After some debugging it is obvious that the bug appears when the application tries to play exactly same sound with interval like 0.001 secs. I have a backtrace on it (attached).

I added check in al_init if there is less than 1.0 second interval between last usage of the same sound (similarity is checked by equation of al_src). I can't reproduce the error anymore. I do realise that the fix is dirty and probably only curing symptoms, but now I can play with many units at least.

P.S. I'm new here and in open source projects overall, so don't be too angry at me if smth is wrong please :3

[comp3820]

I just had this happen to me - at least it sounds just like it.

Attacking approximately 200 legionaries with about 100 mixed celts.

I tried the same situation again, but it did not crash.

[Badmadblacksad]

In snd_mgr.cpp the function snd_play() do "list_add(vs)" even if vsrc_grant() returns ERR::FAIL because it cannot allocate a source. Later al_src_free() try to free that source but can not find it in the al_srcs_used list, and the assert fail. I attached 2 patch, don't really know which one is the best.

[Badmadblacksad]

alt 1

[Badmadblacksad]

alt 2

[Jan Wassenberg]

Thanks for looking into this! I can't see why it would be a problem to add to the list even if vsrc_grant fails. The latter is just an attempt to reduce latency by starting the sound immediately instead of during the next update. Even if there is no source at hand, there should be no harm in inserting the VSrc into the list (there may be lots of VSrc in there that don't have a source - in fact that is the point of the VSrc abstraction layer). Wondering why the al_src would not be found, I came across ​http://opensource.creative.com/pipermail/openal/2006-May/009567.html And indeed, we were using 0 to indicate the source isn't valid. Instead, we now use a VS_HAS_AL_SRC flag. Does that fix the problem?

[Badmadblacksad]

Yes, problem fixed. well done.

[Jan Wassenberg]

Glad to hear it; thanks for the confirmation!

(Man, what an odyssey this ticket has been ;) It's hard to debug stuff that always works on the development machine. Unfortunately, OpenAL implementations differ significantly.)