Source Code Project Mantis - FSSCP
View Issue Details
0001486FSSCPmultiplayerpublic2007-09-02 03:412009-03-17 16:13
ReporterGoober5000 
Assigned Tokarajorma 
PriorityhighSeveritycrashReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.6.10 
Summary0001486: Pressing F4 as a multiplayer client often causes FSO to freeze
DescriptionIt's happened a couple times now while I've been playing. Not all the time, but frequently.
TagsNo tags attached.
Attached Fileslog fs2_open_04-12-08.log (163,675) 2008-04-13 00:51
http://scp.indiegames.us/mantis/file_download.php?file_id=1015&type=bug
log fs2_open_20081013.log (127,295) 2008-10-14 00:24
http://scp.indiegames.us/mantis/file_download.php?file_id=1109&type=bug
log fs2_open.log (86,608) 2008-10-20 03:06
http://scp.indiegames.us/mantis/file_download.php?file_id=1118&type=bug
? fs2_open.f4 (137,688) 2009-02-09 23:20
http://scp.indiegames.us/mantis/file_download.php?file_id=1238&type=bug

Notes
(0008467)
Turey   
2007-09-02 20:01   
I've seen this too. I'll look into it.
(0008482)
ni1s   
2007-09-04 11:48   
I've rigorously tried to reproduce this in FS2(with and without the mediavps) and BtRL but I can't reproduce it. Could someone please add the steps(hints even) to reproduce?

Tested on a Linux build from 040907 rolled from the fs2_open_3_6_9 branch.
(0008486)
Turey   
2007-09-04 14:31   
I haven't been able to reproduce either, but I'm just going to leave MSVC2005 open every time I play multi, and see if I can grab a debug.
(0009216)
FUBAR-BDHR   
2008-04-13 00:51   
I just had this happen tonight with the 3.6.10 3/14 XT build. Was running debug at the time. I'll upload the log. It was a freeze not a crash so there probably isn't an error message.
(0009965)
chief1983   
2008-10-14 00:23   
This just happened to me while playing a game with Fubar. Using one of Taylor's recent multi_test builds, from a few days ago I think. Don't know much else, I don't even know what mission it was but I was just flying along and I pressed a couple other function keys, went back into the game, hit F4 and then it hard froze. Had to hit the X and tell it to End Now. I think I'm going to bump this to crash and high priority. I was running debug as well now that I think about it. Also uploading my fs2_open.log.
(0009971)
taylor   
2008-10-14 04:45   
I think that this might be caused by an endless loop somewhere. Next time please make sure that "+missionlog" is in your debug_filter.cfg (create it if it doesn't exist, just add "-parse" in that case) and we'll see if it's in the mission log code or not.
(0010036)
taylor   
2008-10-18 14:59   
I've been trying to reproduce this on a client for 2 days without success. This is with Linux and OS X clients though, so if there is some sort of Windows specific thing going on then that would explain why I can't reproduce it. I'm going to try adding a Windows box to the mix when I test it some more tomorrow.
(0010037)
FUBAR-BDHR   
2008-10-18 15:16   
It was working for me the other day as well when testing over the LAN. Maybe another one of those lag related things? Something like hitting F4 right when an update to the log is being sent from the host. If so your best bet to reproduce it might be right at mission start. I think that was when it happened to Chief. He hit it at mission start to see the objectives.
(0010040)
chief1983   
2008-10-18 18:29   
The mission started, I forgot what I was supposed to do, and I started flying through the F* menus. I hit F2 and F3 first, escaping back each time, and then hitting F4 crashed me. I was going through them pretty quickly too. So that may have hastened the crash along. And I was on Windows as well.
(0010043)
taylor   
2008-10-18 23:48   
Has this ever been seen on the host side, or is it always just the client?
(0010044)
FUBAR-BDHR   
2008-10-19 00:21   
I've only seen it on the client side.
(0010057)
FUBAR-BDHR   
2008-10-20 02:03   
Just got this while hosting on my standalone. I hit pause then F4 and it locked up solid. Nothing in the errorlog since I had to alt-ctrl-del and end task.
(0010062)
taylor   
2008-10-20 02:45   
I just tried it and couldn't get it to happen. This is on Linux though, and I'm thinking that this is Windows specific.

I still haven't gotten a Windows box to test with but I'll try and do that tomorrow. It's much harder to debug for me, so I can't promise to find the exact problem, but I should be able to narrow it down a bit. After going through the code today I think that it might be some issue with it looking for system events (key presses, etc), because not much else in there can result in an endless loop.
(0010065)
FUBAR-BDHR   
2008-10-20 03:06   
Turns out there was something in the fs2_open.log. Not sure if it will help any but I attached it.
(0010099)
taylor   
2008-10-23 00:16   
I already told FUBAR about this, but I really should mention it here as well...

Grab this build and try to reproduce this bug again:
http://icculus.org/~taylor/fso/testing/multi_test.rar

I tried for 2 days to replicate this on a Windows box and still wasn't able to do so. As an alternative I just put a bunch of debugging messages in the build to try and narrow down where the hang is located. So run the debug build, and if you get the hang then attach your fs2_open.log file here for me to look at. That should contain enough info to point to one particular part of the code, or at least rule some stuff out.
(0010219)
phreak   
2008-11-18 10:37   
Does this issue still occur?
(0010224)
FUBAR-BDHR   
2008-11-18 14:11   
Have not seen it in quite awhile but I can't say I've tried it much as a regular client just hosting on a standalone. Probably just going to have to wait and see on this one.
(0010450)
chief1983   
2008-12-21 00:47   
No replies on the forums or here that it happens, so I'm closing it.
(0010455)
chief1983   
2008-12-21 16:39   
Apparently still happening.
(0010457)
karajorma   
2008-12-22 03:48   
Yep. I've seen this one in Diaspora and fortunately I was running a debug build so I could keep breaking into the code and indentify which loop it was stuck inside of.

The problem is that the wrong subsystem is being passed in message_log_init_scrollback() when dealing with destroyed turrets, apparently because entry->index holds the wrong value. message_log_add_segs() then enters a loop it can't break out of. But the problem is with the data being passed to it not in the function itself most likely.
(0010666)
FUBAR-BDHR   
2009-02-09 23:20   
Just had it happen. Attached the log.
(0010677)
karajorma   
2009-02-14 18:57   
Fixed this one in my branch. I won't submit the fix to trunk just yet as it breaks multiplayer compatibility.

To be honest though I'm mystified as to how this could ever have worked in Retail.
(0010678)
taylor   
2009-02-14 21:07   
So, what exactly was wrong that a type change messed it up? The only thing that I can think of is that it ended up < 0, but I think that can probably be detected and properly handled without causing a compatibility break.

But I don't know exactly what the bug is so I could be talking out of my ass.
(0010679)
chief1983   
2009-02-15 03:31   
OMG, I haven't been keeping a terribly close eye on the recent Mantis bugs, but if this really gets fixed I think we might be ready for 3.6.10 release candidates. Might.
(0010680)
karajorma   
2009-02-15 04:41   
(Last edited: 2009-02-15 04:42)
The problem is that for destroyed turrets you need to pass two pieces of information. The index of the ship class and the index of the subsystem that was destroyed. If you look at do_subobj_destroyed_stuff() in shiphit.cpp you can see that V solved the problem by sticking both indexes in the high and low bits of an integer and passing that as the info_index parameter in mission_log_add_entry().

That means that when you cast the int to a short you trim off ship_info index completely. I did consider trying to do the same trick of sticking the ship_info index in the first byte and the model index in the second so as to not break compatibility but if we ever go above 255 for either we're going to be right back here again.

(0010681)
taylor   
2009-02-15 10:23   
That makes sense. Plus, even if you could get keep in the ushort it would be a compatibility break either way.
(0010750)
karajorma   
2009-03-17 16:13   
Committed to trunk

Issue History
2007-09-02 03:41Goober5000New Issue
2007-09-02 19:58TureyStatusnew => assigned
2007-09-02 19:58TureyAssigned To => Turey
2007-09-02 20:01TureyNote Added: 0008467
2007-09-02 20:01TureyStatusassigned => confirmed
2007-09-04 11:48ni1sNote Added: 0008482
2007-09-04 14:31TureyNote Added: 0008486
2008-04-13 00:51FUBAR-BDHRNote Added: 0009216
2008-04-13 00:51FUBAR-BDHRFile Added: fs2_open_04-12-08.log
2008-10-14 00:23chief1983Note Added: 0009965
2008-10-14 00:23chief1983Prioritynormal => high
2008-10-14 00:23chief1983Severityminor => crash
2008-10-14 00:24chief1983File Added: fs2_open_20081013.log
2008-10-14 04:45taylorNote Added: 0009971
2008-10-18 14:59taylorNote Added: 0010036
2008-10-18 15:16FUBAR-BDHRNote Added: 0010037
2008-10-18 18:29chief1983Note Added: 0010040
2008-10-18 23:48taylorNote Added: 0010043
2008-10-19 00:21FUBAR-BDHRNote Added: 0010044
2008-10-20 02:03FUBAR-BDHRNote Added: 0010057
2008-10-20 02:45taylorNote Added: 0010062
2008-10-20 03:06FUBAR-BDHRFile Added: fs2_open.log
2008-10-20 03:06FUBAR-BDHRNote Added: 0010065
2008-10-20 03:40taylorStatusconfirmed => assigned
2008-10-20 03:40taylorAssigned ToTurey => taylor
2008-10-23 00:16taylorNote Added: 0010099
2008-11-18 10:37phreakNote Added: 0010219
2008-11-18 14:11FUBAR-BDHRNote Added: 0010224
2008-12-02 16:14chief1983Statusassigned => feedback
2008-12-16 19:49taylorAssigned Totaylor =>
2008-12-21 00:47chief1983Note Added: 0010450
2008-12-21 00:47chief1983Statusfeedback => resolved
2008-12-21 00:47chief1983Resolutionopen => fixed
2008-12-21 16:39chief1983Note Added: 0010455
2008-12-21 16:39chief1983Statusresolved => confirmed
2008-12-21 16:39chief1983Resolutionfixed => reopened
2008-12-22 03:42karajormaStatusconfirmed => assigned
2008-12-22 03:42karajormaAssigned To => karajorma
2008-12-22 03:48karajormaNote Added: 0010457
2009-02-09 23:20FUBAR-BDHRFile Added: fs2_open.f4
2009-02-09 23:20FUBAR-BDHRNote Added: 0010666
2009-02-14 18:57karajormaNote Added: 0010677
2009-02-14 21:07taylorNote Added: 0010678
2009-02-15 03:31chief1983Note Added: 0010679
2009-02-15 04:41karajormaNote Added: 0010680
2009-02-15 04:42karajormaNote Edited: 0010680
2009-02-15 10:23taylorNote Added: 0010681
2009-03-17 16:13karajormaStatusassigned => resolved
2009-03-17 16:13karajormaFixed in Version => 3.6.10
2009-03-17 16:13karajormaResolutionreopened => fixed
2009-03-17 16:13karajormaNote Added: 0010750