2019-10-16 11:54 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001966FSSCP---------public2009-07-22 11:23
ReporterFUBAR-BDHR 
Assigned Totaylor 
PrioritynormalSeverityblockReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.6.11 
Target VersionFixed in Version3.6.11 
Summary0001966: Recent builds totally break multiplayer for some total conversions
DescriptionThat pretty much says it. Multi is totally unusable for TBP and Diaspora in 3.6.11 at this point. Crashes as soon as it validating tables appears on the screen with the following:

Frame 0 too long!!: frametime = 0.417 (0.417)
Got event GS_EVENT_MULTI_JOIN_GAME (18) in state GS_STATE_PXO (49)
Frame 0 too long!!: frametime = 0.300 (0.300)
Got event GS_EVENT_MULTI_START_GAME (51) in state GS_STATE_MULTI_JOIN_GAME (14)
Frame 0 too long!!: frametime = 0.391 (0.391)
ASSERTION: "buffer_size+sizeof(uint) <= sizeof(buffer)" at tcp_client.cpp:705
ASSERTION: "buffer_size+strlen(Table_valid_status[i].name)+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(uint) <= sizeof(buffer)" at tcp_client.cpp:705
ASSERTION: "buffer_size+strlen(Table_valid_status[i].name)+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(uint) <= sizeof(buffer)" at tcp_client.cpp:705
ASSERTION: "buffer_size+strlen(Table_valid_status[i].name)+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(uint) <= sizeof(buffer)" at tcp_client.cpp:705
ASSERTION: "buffer_size+strlen(Table_valid_status[i].name)+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(int) <= sizeof(buffer)" at tcp_client.cpp:704
ASSERTION: "buffer_size+sizeof(uint) <= sizeof(buffer)" at tcp_client.cpp:705
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0011098

taylor (administrator)

Do things work with an older build with the exact same data? It's possible that this is just an issue of too many tables which need to be validated (looks like I forgot any sort of safety check there). If an older build with the same data works then this could be some issue related to the recent change to use SCP_vector.

~0011099

FUBAR-BDHR (developer)

I need to do some more testing but I think this was a combination of safe strings stuff and too many tables. This may already be fixed although I think that 1024 character limit for table validation is going to come back to bite us at some point.

~0011100

taylor (administrator)

Last edited: 2009-07-20 23:28

The 1024 buffer limit allows for about 24 tables (at least, more depending on filename lengths). It doesn't try to validate every table of course, just the important ones, but it would probably be pretty easy at this point to hit that with a lot of modular tables for ships/weapons. That buffer should probably be bumped to 4096, which would allow for about 99 tables minimum. If no one fixes it in the meantime I'll try and make the change later this week.

I have already started rewriting all of that code so that the buffer size can be dynamic. It just hasn't been a priority to get it done.

~0011101

portej05 (reporter)

SCP_vector only affected those using std::vector already, and the only change was to the allocator, so I'm going to suggest that this isn't the cause of your worries.
I didn't change any of the multi code to use safe_strings. The only code using safe_strings is those bits identified by *_s on either strcpy or strcat. (parselo.cpp and ship.cpp are the only ones changed so far)

~0011102

FUBAR-BDHR (developer)

Latest builds seem to work.
+Notes

-Issue History
Date Modified Username Field Change
2009-07-19 15:06 FUBAR-BDHR New Issue
2009-07-20 20:53 taylor Note Added: 0011098
2009-07-20 23:00 FUBAR-BDHR Note Added: 0011099
2009-07-20 23:28 taylor Note Added: 0011100
2009-07-20 23:28 taylor Note Edited: 0011100
2009-07-20 23:57 portej05 Note Added: 0011101
2009-07-21 04:45 FUBAR-BDHR Note Added: 0011102
2009-07-22 11:23 Echelon9 Status new => assigned
2009-07-22 11:23 Echelon9 Assigned To => taylor
2009-07-22 11:23 Echelon9 Status assigned => resolved
2009-07-22 11:23 Echelon9 Fixed in Version => 3.6.11
2009-07-22 11:23 Echelon9 Resolution open => fixed
+Issue History