View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001814 | FSSCP | multiplayer | public | 2008-11-11 01:53 | 2009-03-15 16:51 |
| Reporter | Shade | Assigned To | karajorma | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | unable to reproduce | ||
| Summary | 0001814: 3.6.10: Clients crash randomly during missions | ||||
| Description | At least two seperate crashes seem to occur when a person (possibly only the host - Host was the one using them during testing) uses mediaVPs while the rest go without. [Update] MediaVPs are not the issue. It was just luck that made it not crash when mediaVPs were unselected by the host. | ||||
| Additional Information | Host did not crash, only clients. All games had three players - host was using mediaVPs, both clients were not. One client was running Linux and one Windows, with host and windows client running the latest multi test build. Logs are only attached for the windows client, as the Linux build wasn't a debug version. Also included is a log from after the host turned off mediaVPs, with no other factors changed. [Update] Happens regardless of mediaVPs, and has also been seen to occur when running total conversions. Have also seen it happen across a wide variety of hardware. | ||||
| Tags | No tags attached. | ||||
|
2008-11-11 01:53
|
|
|
|
None of that looks even remotely MediaVP related. Having it work without MediaVPs seems purely coincidental. Crash_1 looks like the client was processing packets that it shouldn't have, which then would have led to a series of issues likely to result in a crash. Was this client on the same machine/network/NAT as the host? Such a situation could certainly cause the packets to come through incorrectly. If not then I have no idea how it could have gotten to such a point where a situation like that would even be possible. Crash_2 just looks like a docking bug in part, where it is trying to process some docking info on something that it doesn't believe is docked. The multi capabilities of the new docking would be the suspect here, since several other recent docking related issues look to be caused by the new docking code. But the actual crash here looks to be related to a missing network object (a ship, specifically), most likely due to a sync issue. The cause of this particular problem looks remarkably similar to Crash_1, and I'd bet that they are due to the same issue. If this client was on the same machine/network/NAT as the host then these problems would not only be explained by that, but it could easily explain the crash of the second client as well. |
|
|
Gah... I really should be in bed but better comment while things are still fresh in my memory. May be that we just got lucky after the mediaVPs were turned off. I didn't think it was related to them at first either, not after having seen the asserts in the debug log, but it seemed like it when suddenly everything worked fine without the mediaVP mismatch. Crash 1: Fubar was hosting, I was the windows client. No NAT involved. Might be worth noting that I experienced a very similar crash to this one yesterday when testing Diaspora multi (as did Ace, so it seems fairly universal across different hardware configurations - His system is far more up to date than mine), but unfortunately I wasn't running a debug build at the time so I can't be 100% sure it was the same. I *think* both this and the one yesterday occured seconds after opening fire for the first time in the mission, if that helps any. Crash 2: If it helps, the mission we were playing when the crashes (both 1 and 2) happened was Into the Lions Den. No docking taking place there as far as I know. |
|
|
Strange, I'll have to take a look into how else it would be possible for the communications to get screwed up like that. The knee-jerk reaction is to just put better checks in all of those functions to bail out nicely, but it if it actually gets to that point in the first place then the entire session is totally screwed. If these comm errors are something that you guys can reproduce repeatedly then I can get you a couple of builds with better logging in place to help track down the cause. If it can't be reproduced then lets just hope it was one-time fluke. Regarding the docking, there are cargo containers and freighters in that mission, so that would likely be the source of the problem (and the log seems to confirm that). I'll try and reproduce that particular problem and then get with Goober about a proper fix. |
|
|
Don't know what mission you are looking at but there are no cargo containers in this mission. M-ITLD is the mission we are talking about. This is the same mission that crashed the other day after someone targeted a fake Sath while in observer mode. |
|
|
Bleh, I was thinking of another mission. Sorry about that. I just double checked and all of the docking issues in the log were support ship related. Still, I'll try and replicate that this weekend and come up with some sort of fix. Did you already tell me about that observer crash? I don't remember anything about a crash that was observer related, but I may have just not read it that carefully. |
|
|
Yea I mentioned it in either an email or a PM. I might have even included a server side log. I just tried out that standalone Kopax has up. While I didn't crash it did kick me out of the mission and I got stuck on the please wait before the debrief pops up. I was able to escape out and reran the mission again. This time it worked but appeared to be on easy or medium instead of insane. It kicked me out right as I was using y to try to target the fake Sath. Can't say for sure that I actually targeted it. Attaching log. It's a long one since I played for quit awhile. You want to look at the last 2 missions loaded. Next to last was the kick out and the last was the successful play. Forgot to mention that according to his server it is using the 3.6.10 VPs and I had them turned off. That other log was sent to you vial email on 10/26 at 5:09PM |
|
2008-11-11 04:24
|
|
|
|
Since observer mode may be an issue, I should probably point out that I was an observer when the second crash happened. Didn't think to mention that before. |
|
|
One other thing I just remembered. There were targeting problems in another mission with a comm node. I know it was one of Cet's missions but I can't remember the name right now. It's the one with the real Sath at the end. Basically when the first 2 caps jumped in no one could target subsystems or turrets on them. After that the problem came and went. So I'm wondering if there is a targeting problem when comm nodes are present. That combined with those fake Saths resulting in a crash. |
|
|
Oh yeah, I remember that now that you mention it. Mission was Breaking the Seal, one of Cetanu's (can't remember the number, but only nine to pick from). |
|
|
I've seen this crop up many times now, when running retail data, when running mediaVPs and even when running TCs. Haven't found anything that directly triggers it though, but it seems that if you play long enough then it *will* happen eventually. So if the offer is still open, I'd like to try that build with extra logging if you think it'll help track it down. |
|
|
Has anyone seen this happen recently? |
|
|
Given that no one been able to reproduce this one for over a month, I'd say it's been fixed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-11-11 01:53 | Shade | New Issue | |
| 2008-11-11 01:53 | Shade | File Added: crashlogs.zip | |
| 2008-11-11 01:53 | Shade | Category | --------- => multiplayer |
| 2008-11-11 01:53 | Shade | Summary | Multi crashes when mixing mediaVPs and no mediaVPs => 3.6.10: Multi crashes when mixing mediaVPs and no mediaVPs |
| 2008-11-11 02:27 | taylor | Note Added: 0010170 | |
| 2008-11-11 02:42 | Shade | Note Added: 0010171 | |
| 2008-11-11 02:44 | Shade | Note Edited: 0010171 | |
| 2008-11-11 03:10 | taylor | Note Added: 0010172 | |
| 2008-11-11 03:40 | FUBAR-BDHR | Note Added: 0010173 | |
| 2008-11-11 04:14 | taylor | Note Added: 0010174 | |
| 2008-11-11 04:23 | FUBAR-BDHR | Note Added: 0010176 | |
| 2008-11-11 04:24 | FUBAR-BDHR | File Added: fs2_open.log | |
| 2008-11-11 04:26 | FUBAR-BDHR | Note Edited: 0010176 | |
| 2008-11-11 04:34 | FUBAR-BDHR | Note Edited: 0010176 | |
| 2008-11-11 13:05 | Shade | Note Added: 0010177 | |
| 2008-11-11 18:04 | FUBAR-BDHR | Note Added: 0010178 | |
| 2008-11-12 04:56 | Shade | Note Added: 0010181 | |
| 2008-12-01 19:47 | Shade | Note Added: 0010314 | |
| 2008-12-01 19:51 | Shade | Severity | minor => major |
| 2008-12-10 23:40 | Shade | Summary | 3.6.10: Multi crashes when mixing mediaVPs and no mediaVPs => 3.6.10: Clients crash randomly during missions |
| 2008-12-10 23:40 | Shade | Description Updated | |
| 2008-12-10 23:40 | Shade | Additional Information Updated | |
| 2009-03-02 20:46 | karajorma | Note Added: 0010702 | |
| 2009-03-15 16:51 | karajorma | Status | new => resolved |
| 2009-03-15 16:51 | karajorma | Resolution | open => unable to reproduce |
| 2009-03-15 16:51 | karajorma | Assigned To | => karajorma |
| 2009-03-15 16:51 | karajorma | Note Added: 0010738 |
