[FIXED]World Crash - Incompatible Version

[John Adams]

Jab,

Need your help on this. Something I noticed a while back but not sure if I mentioned, if Login and World allows version 57032 - 57032 (for example) but your client is 57031, the world crashes after receiving the Incompatible Version error message. I am not sure it's related as much to the version error as it is booting the client the moment a zone starts.

From linux:

08:50:56 I ZoneAuth : Access Key: 1371657053, Character Name: Hanta, Account ID : 150
08:50:56 D Player : Loading character for 'Hanta' (char_id: 1)
08:50:56 I Zone : Loading new Zone 'FrostfangSea'
08:50:56 D Recipes : Loaded 0 recipes for player: Hanta (1)
08:50:56 D Achievements: Loaded 0 player achievement updates
08:50:56 D Player : Loading character_details for 'Hanta' (char_id: 1)
08:50:56 E World : Incompatible version: 57031
08:50:56 I World : Removing client from ip: 68.98.218.5 port: 62264
08:50:56 I Spawn : Loaded for zone 'FrostfangSea' (470):
1836 NPC(s), 1234 Object(s), 59 Widget(s)
81 Sign(s), 1920 Ground Spawn(s), 1821 Spawn Group(s)
1158 Spawn Group Association(s), 0 Spawn Group Chance(s)
08:50:59 D Zone : Starting zone shutdown timers...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa44fdb70 (LWP 7976)]
0xb64003f0 in ?? ()
(gdb) bt
#0 0xb64003f0 in ?? ()
#1 0x0831d6c7 in ZoneServer::SpawnProcess (this=0xa44fd2d0) at zoneserver.cpp:9 73
#2 0x0831da8e in SpawnLoop (tmp=0xb23ceca0) at zoneserver.cpp:4933
#3 0xb7c6a96e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb7bd998e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

This occurs pretty much the same in Windows, so you should be able to reproduce it easily. Just connect your client using an unknown data version.

Thanks

[Jabantiz]

Odd, does this always happen now or is it rare? Added it to my todo list for when I get some free time.

[John Adams]

It appears 100% reproducible, at least for me. I can crash one of my servers whenever you wish and have time, if you cannot do it locally.

Could be a speed thing, too, both my servers are VMs but relatively fast. Not as fast as physical hardware though.

[Jabantiz]

I assume this is still an issue, I think I see a possible solution but I don't think I have an incompatible client, searching for one, gonna test my possible fix to make sure it doesn't break anything with working clients.

And the possible fix breaks stuff so not a solution...

[John Adams]

Yeah I dug around for a few days in the opcode loading code and that might as well be written in Chinese... the only thing I was able to change were fprintf()'s for LogWrites

Could we simply do a quick lookup for unique "client versions" we have opcodes for, compare it to what was sent and bounce the client? I mean, we do that already (the bouncing part) but we never crashed the world before.

[Jabantiz]

I assume this use to work before the version changes SOE made? I would like to figure out what changed to make this crash the world now but looks like it will require more time then I currently have. Still need to find an incompatible client to test with as well, preferably 2 one before the version changes and one from after.

[John Adams]

Actually, I believe it was happening to me when I had a 1195 client to a 1193 world, so no I do not think it's about the big numbers either.

You can always fake an invalid client by removing the opcode range of your client.