View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001486 | FSSCP | multiplayer | public | 2007-09-02 07:41 | 2009-03-17 20:13 |
| Reporter | Goober5000 | Assigned To | karajorma | ||
| Priority | high | Severity | crash | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.6.10 | ||||
| Summary | 0001486: Pressing F4 as a multiplayer client often causes FSO to freeze | ||||
| Description | It's happened a couple times now while I've been playing. Not all the time, but frequently. | ||||
| Tags | No tags attached. | ||||
|
|
I've seen this too. I'll look into it. |
|
|
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. |
|
|
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. |
|
|
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. |
|
2008-04-13 04:51
|
|
|
|
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. |
|
2008-10-14 04:24
|
|
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Has this ever been seen on the host side, or is it always just the client? |
|
|
I've only seen it on the client side. |
|
|
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. |
|
|
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. |
|
2008-10-20 07:06
|
|
|
|
Turns out there was something in the fs2_open.log. Not sure if it will help any but I attached it. |
|
|
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. |
|
|
Does this issue still occur? |
|
|
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. |
|
|
No replies on the forums or here that it happens, so I'm closing it. |
|
|
Apparently still happening. |
|
|
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. |
|
2009-02-10 04:20
|
|
|
|
Just had it happen. Attached the log. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
That makes sense. Plus, even if you could get keep in the ushort it would be a compatibility break either way. |
|
|
Committed to trunk |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-09-02 07:41 | Goober5000 | New Issue | |
| 2007-09-02 23:58 | Turey | Status | new => assigned |
| 2007-09-02 23:58 | Turey | Assigned To | => Turey |
| 2007-09-03 00:01 | Turey | Note Added: 0008467 | |
| 2007-09-03 00:01 | Turey | Status | assigned => confirmed |
| 2007-09-04 15:48 | ni1s | Note Added: 0008482 | |
| 2007-09-04 18:31 | Turey | Note Added: 0008486 | |
| 2008-04-13 04:51 | FUBAR-BDHR | Note Added: 0009216 | |
| 2008-04-13 04:51 | FUBAR-BDHR | File Added: fs2_open_04-12-08.log | |
| 2008-10-14 04:23 | chief1983 | Note Added: 0009965 | |
| 2008-10-14 04:23 | chief1983 | Priority | normal => high |
| 2008-10-14 04:23 | chief1983 | Severity | minor => crash |
| 2008-10-14 04:24 | chief1983 | File Added: fs2_open_20081013.log | |
| 2008-10-14 08:45 | taylor | Note Added: 0009971 | |
| 2008-10-18 18:59 | taylor | Note Added: 0010036 | |
| 2008-10-18 19:16 | FUBAR-BDHR | Note Added: 0010037 | |
| 2008-10-18 22:29 | chief1983 | Note Added: 0010040 | |
| 2008-10-19 03:48 | taylor | Note Added: 0010043 | |
| 2008-10-19 04:21 | FUBAR-BDHR | Note Added: 0010044 | |
| 2008-10-20 06:03 | FUBAR-BDHR | Note Added: 0010057 | |
| 2008-10-20 06:45 | taylor | Note Added: 0010062 | |
| 2008-10-20 07:06 | FUBAR-BDHR | File Added: fs2_open.log | |
| 2008-10-20 07:06 | FUBAR-BDHR | Note Added: 0010065 | |
| 2008-10-20 07:40 | taylor | Status | confirmed => assigned |
| 2008-10-20 07:40 | taylor | Assigned To | Turey => taylor |
| 2008-10-23 04:16 | taylor | Note Added: 0010099 | |
| 2008-11-18 15:37 | phreak | Note Added: 0010219 | |
| 2008-11-18 19:11 | FUBAR-BDHR | Note Added: 0010224 | |
| 2008-12-02 21:14 | chief1983 | Status | assigned => feedback |
| 2008-12-17 00:49 | taylor | Assigned To | taylor => |
| 2008-12-21 05:47 | chief1983 | Note Added: 0010450 | |
| 2008-12-21 05:47 | chief1983 | Status | feedback => resolved |
| 2008-12-21 05:47 | chief1983 | Resolution | open => fixed |
| 2008-12-21 21:39 | chief1983 | Note Added: 0010455 | |
| 2008-12-21 21:39 | chief1983 | Status | resolved => confirmed |
| 2008-12-21 21:39 | chief1983 | Resolution | fixed => reopened |
| 2008-12-22 08:42 | karajorma | Status | confirmed => assigned |
| 2008-12-22 08:42 | karajorma | Assigned To | => karajorma |
| 2008-12-22 08:48 | karajorma | Note Added: 0010457 | |
| 2009-02-10 04:20 | FUBAR-BDHR | File Added: fs2_open.f4 | |
| 2009-02-10 04:20 | FUBAR-BDHR | Note Added: 0010666 | |
| 2009-02-14 23:57 | karajorma | Note Added: 0010677 | |
| 2009-02-15 02:07 | taylor | Note Added: 0010678 | |
| 2009-02-15 08:31 | chief1983 | Note Added: 0010679 | |
| 2009-02-15 09:41 | karajorma | Note Added: 0010680 | |
| 2009-02-15 09:42 | karajorma | Note Edited: 0010680 | |
| 2009-02-15 15:23 | taylor | Note Added: 0010681 | |
| 2009-03-17 20:13 | karajorma | Status | assigned => resolved |
| 2009-03-17 20:13 | karajorma | Fixed in Version | => 3.6.10 |
| 2009-03-17 20:13 | karajorma | Resolution | reopened => fixed |
| 2009-03-17 20:13 | karajorma | Note Added: 0010750 |
