archive by month
Skip to content

untraceable Steamhammer crash

Steamhammer has had its first crash loss on SSCAIT since May. Or it may have overstepped the time limit. Randomhammer protoss has sometimes broken the time limit, but this is the first for zerg in a long time.

The game is Steamhammer-UPStarcraftAI 2016 (a zerg rushbot), and it looked like a routine Steamhammer win until 5:19 in, when suddenly bam, the 0/0 supply that means crash. Steamhammer has won dozens of these rushbot games without incident.

  • SSCAIT did not record an exception log.
  • If it was a time limit loss, why did it happen in a short game with few units?
  • It didn’t seem like server maintenance either. The games before and after were closely spaced.

It’s a mystery, and there doesn’t seem to be any information to start from.

Steamhammer does still have crashing bugs despite my rigorous eradication campaign. AIIDE 2017 reported 4 crashes out of 2964 games, a rate of about one per 740 games. The current SSCAIT version now has 1 crash in 385 games, which is not statistically different. I found a crash yesterday with a stress test where I forced Steamhammer to play an opening that caused it to lose bases and struggle to recover. After many games, I got one crash. I think I fixed the cause, but the crash is rare and difficult to reproduce, so....

Trackbacks

No Trackbacks

Comments

McRave on :

SSCAIT has crashed McRave twice recently and Iron once, without reporting it as a crash. Watching the vod shows that something is causing instant closes of the game, not a crash.

Jay Scott on :

The SSCAIT results only sometimes label crashes, even in cases where a bot definitely crashed and an exception log was saved. At least that is my experience; I guess it could have changed. Anyway, without the exception log there is no foothold to debug it.

Antiga / Iruian on :

With Antiga on SSCAIT, it has a 18% timeout rate from my tracking. Due to the known pylon power issues. It's basically identical to the randomhammer P build with only minor changes right now.

Jay Scott on :

18% is higher than I thought. :-(

Antiga / Iruian on :

Yeah :( Unfortunately it really hurts the performance of the bot when it drops that many games outright on timeout. It's tracking pretty well around ~2110 Elo and has been as high as 2196 since the last update. But likely there is another 20-30 more elo on average there if it just was able to complete all of the games.

Long been a plague on all Protoss steamhammer / UAB bots variants. Me / several other people have tried to fix it, but the changes are so invasive that it no longer fundamentally resembles UAB / steamhammer internally afterwards. Likely making it almost impossible to include the new features / work that you have done as time goes forward.

I'd happily donate to a fund as a bounty for fixing this bug!

krasi0 on :

Yup, there have been some odd crashes (the starcraft instance suddenly closes just like what McRave has described) lately on SSCAIT. It's happened a few times to my bot as well. I mean those could be some genuine crashes, say, forced by BWAPI, but a client bot shouldn't in principle be able to crash the Starcraft instance...
Anyway, the server hadn't been restarted for many months so I asked Michal C. to restart it last night, right after nepeta's cast. Please let me know (via email) in case you observe any more such crashes.

MicroDK on :

I experience rare crashes with Microwave, sometimes early about 5 min and sometimes after 10-15 mins. With a SSCAIT crash log, will I be able to debug the crash? I do not know how to use the crash log.

Jay Scott on :

If the crash log is saved successfully (which I don’t count on), then it should tell you the routine the crash occurred in and the stack trace. It also tells you a bunch of low level details, but you can ignore those unless you’re using an assembly debugger! For me it has always provided enough information to debug crashes. You do have to know how to read it. For each Steamhammer build, I keep a copy of the link map (the .map output file from VS) so I can find out what routines different addresses are in.

MicroDK on :

So I find this in the crash log: Fault address: 6AB2A269 01:00069269 C:\TM\Starcraft\bwapi-data\AI\Microwave.dll. I can then use the address to find the routine in the .map?

Jay Scott on :

Yes, that’s the idea. SSCAIT sometimes saves 2 files for each crash, one with Error in its name and one with only the date in its name. The date one has a little less information but is easier to read.

MicroDK on :

Yes that is true... the one with the date in the name has this line: FAULT: 0x6AB2A269 Microwave.dll. I wonder how I translate that address to 01:00069269 which seems to be the format that the .map file uses.

Jay Scott on :

Ah, you have to convert the address the code was loaded at to the logical address recorded in the .map file. I wanted to say “physical address” but it is a virtual address, very confusing.... If you have it, the file with Error in its name includes the information for you (especially see the “call stack” section). Once you have the logical address, https://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file explains how to use it. The article is from 2003, but executable file formats are stable. And that is the extent of my expertise, which I built up just enough to solve my crashes!

MicroDK on :

Thanks! This is great and I think others also can use this for debugging. ;)

krasi0 on :

So have there been any suspicious crashes during the last few days? Anyone?

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Submitted comments will be subject to moderation before being displayed.