2022-08-17 15:39 EDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001486FSSCPmultiplayerpublic2009-03-17 16:13
Assigned Tokarajorma 
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 Files




Turey (developer)

I've seen this too. I'll look into it.


ni1s (reporter)

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.


Turey (developer)

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.


FUBAR-BDHR (developer)

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.


chief1983 (administrator)

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.


taylor (administrator)

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.


taylor (administrator)

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.


FUBAR-BDHR (developer)

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.


chief1983 (administrator)

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.


taylor (administrator)

Has this ever been seen on the host side, or is it always just the client?


FUBAR-BDHR (developer)

I've only seen it on the client side.


FUBAR-BDHR (developer)

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.


taylor (administrator)

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.


FUBAR-BDHR (developer)

Turns out there was something in the fs2_open.log. Not sure if it will help any but I attached it.


taylor (administrator)

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:

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.


phreak (developer)

Does this issue still occur?


FUBAR-BDHR (developer)

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.


chief1983 (administrator)

No replies on the forums or here that it happens, so I'm closing it.


chief1983 (administrator)

Apparently still happening.


karajorma (administrator)

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.


FUBAR-BDHR (developer)

Just had it happen. Attached the log.


karajorma (administrator)

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.


taylor (administrator)

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.


chief1983 (administrator)

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.


karajorma (administrator)

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.


taylor (administrator)

That makes sense. Plus, even if you could get keep in the ushort it would be a compatibility break either way.


karajorma (administrator)

Committed to trunk

-Issue History
Date Modified Username Field Change
2007-09-02 03:41 Goober5000 New Issue
2007-09-02 19:58 Turey Status new => assigned
2007-09-02 19:58 Turey Assigned To => Turey
2007-09-02 20:01 Turey Note Added: 0008467
2007-09-02 20:01 Turey Status assigned => confirmed
2007-09-04 11:48 ni1s Note Added: 0008482
2007-09-04 14:31 Turey Note Added: 0008486
2008-04-13 00:51 FUBAR-BDHR Note Added: 0009216
2008-04-13 00:51 FUBAR-BDHR File Added: fs2_open_04-12-08.log
2008-10-14 00:23 chief1983 Note Added: 0009965
2008-10-14 00:23 chief1983 Priority normal => high
2008-10-14 00:23 chief1983 Severity minor => crash
2008-10-14 00:24 chief1983 File Added: fs2_open_20081013.log
2008-10-14 04:45 taylor Note Added: 0009971
2008-10-18 14:59 taylor Note Added: 0010036
2008-10-18 15:16 FUBAR-BDHR Note Added: 0010037
2008-10-18 18:29 chief1983 Note Added: 0010040
2008-10-18 23:48 taylor Note Added: 0010043
2008-10-19 00:21 FUBAR-BDHR Note Added: 0010044
2008-10-20 02:03 FUBAR-BDHR Note Added: 0010057
2008-10-20 02:45 taylor Note Added: 0010062
2008-10-20 03:06 FUBAR-BDHR File Added: fs2_open.log
2008-10-20 03:06 FUBAR-BDHR Note Added: 0010065
2008-10-20 03:40 taylor Status confirmed => assigned
2008-10-20 03:40 taylor Assigned To Turey => taylor
2008-10-23 00:16 taylor Note Added: 0010099
2008-11-18 10:37 phreak Note Added: 0010219
2008-11-18 14:11 FUBAR-BDHR Note Added: 0010224
2008-12-02 16:14 chief1983 Status assigned => feedback
2008-12-16 19:49 taylor Assigned To taylor =>
2008-12-21 00:47 chief1983 Note Added: 0010450
2008-12-21 00:47 chief1983 Status feedback => resolved
2008-12-21 00:47 chief1983 Resolution open => fixed
2008-12-21 16:39 chief1983 Note Added: 0010455
2008-12-21 16:39 chief1983 Status resolved => confirmed
2008-12-21 16:39 chief1983 Resolution fixed => reopened
2008-12-22 03:42 karajorma Status confirmed => assigned
2008-12-22 03:42 karajorma Assigned To => karajorma
2008-12-22 03:48 karajorma Note Added: 0010457
2009-02-09 23:20 FUBAR-BDHR File Added: fs2_open.f4
2009-02-09 23:20 FUBAR-BDHR Note Added: 0010666
2009-02-14 18:57 karajorma Note Added: 0010677
2009-02-14 21:07 taylor Note Added: 0010678
2009-02-15 03:31 chief1983 Note Added: 0010679
2009-02-15 04:41 karajorma Note Added: 0010680
2009-02-15 04:42 karajorma Note Edited: 0010680
2009-02-15 10:23 taylor Note Added: 0010681
2009-03-17 16:13 karajorma Status assigned => resolved
2009-03-17 16:13 karajorma Fixed in Version => 3.6.10
2009-03-17 16:13 karajorma Resolution reopened => fixed
2009-03-17 16:13 karajorma Note Added: 0010750
+Issue History