Client freezes when using big maps on MacOS

[securmk]

Before creating an issue, please ensure:

• [ ] This is a bug in the software that resides in this repository, and not a support matter (use https://otland.net/forums/support.16/ for support)
• [ ] This issue is reproducible without changes to the code in this repository

Steps to reproduce (include any configuration/script required to reproduce)

1. Compile TFS
2. Replace map with global map
3. Travel to a city by /town or by sea ship.

Expected behaviour

Character goes to the city and everything goes as it should.

Actual behaviour

It sends me to the city but then freezes. I advance an SQM and the minimap doesn't show it (it doesn't move). It's strange because after going, for example, to venore, I can type "/town thais" and it debugs sending me this crash log:

Map.cpp 378: assertion failed (rx = -580), reason: In(rx,0,MAPSIZE_X-1)[bug0000013]

It doesn't throw any error on the console nor send me any error on the game. It just freezes and I can't move. If I relog it sends me to where I was prior to teleporting. I will explain it with an example because it sounds confusing:

I am in Thais temple. I do "/town venore" and appear in Venore temple. I can walk 1 sqm and then it freezes. The client minimap doesn't move or reacts to my movement. I relog and I appear in Thais. If I do "/town thais" it debugs me and gives me the error above.

I already tried with original map and doesn't happen, but when I try with any real map it just sends me the error. I also tried moving only the map, house and spawn files and loading it with the same default distribution (the one you get when you git clone) and it gives me the same error. Maybe it's something related to how server manages bigger map files. I need help please.

EDIT: It seems that the error happens everytime you teleport. For example if i do /goto demon it does the same weird thing. If I use use /goto x, y, z it does the same thing. If I use /a command and go far it does the same thing. I don't know why this is happening.

EDIT2: When I relog and appear in the previous position it sends this error to the console:

[Error - mysql_real_query] Query: INSERT INTO players_online` VALUES (1)

Message: Duplicate entry '1' for key 'PRIMARY'`

Environment

Latest TFS default downloaded with git clone.

[elderapo]

Upload that map somewhere so other people can test it aswell. Honeslty I never experienced something like this and never heard of similar thing happen to anyone else.

[securmk]

@elderapo One of the maps I tested was this: https://github.com/otxserver-new/master/raw/master/data/world/global.zip But I also tried with 2 or 3 more.

[ranisalt]

Couldn't reproduce with ORTS which is a pretty huge map.

[wgrr]

couldn't reproduce either, envroiment: orts map with latest release build from appveyor

[securmk]

Hiho, I noticed that the errors only happens when running the server on a Mac enviroment. I tested in Windows and it won't happen. Anyone has any idea of what could be causing this weird issue? I haven't tested on a Linux machine yet. I was running server on Mac (compiled it) and used parallels to run the client.

[djarek]

Perhaps this issue is caused by clang rather than Mac OS? Does anyone run TFS compiled with clang (on Linux or Windows)?

[hhennies]

I can confirm this issue, I've compiled tfs both using clang 4.0.1 and gcc 7.1.0 on my macos sierra machine. In both cases the client freezes when going after a certain x coordinate on the map.

[GoularPink]

same here https://imgur.com/a/3cwim

[GoularPink]

@DSpeichert hi, I'm don't using MacOS.. using linux (server) and to play the game (windows), but its related who using big maps? my is global map

[djseban]

I can elaborate, exactly the same thing happens on macOS Catalina

[ranisalt]

Does this happen with OTClient? Seems to be a bug on the client, not the server.

[djseban]

Does this happen with OTClient? Seems to be a bug on the client, not the server.

Yeah, it happens and nay, it's server sided. While connecting with mac-compiled otc to tfs in Linux VM everything works just fine.

[andreaslif]

I have the same issue when I compile on Mac OS, but not on Windows. I've found that it happens when the player reaches an x coordinate of 32 757 or higher, which is why it happens when you travel to Venore or Edron, but not to Carlin. If you walk towards Venore from Thais, you'll find that it always freezes at 32 757.

I'm guessing that this also loads 10 tiles more bringing the total up to 32 767, which is the max value of a short signed int. Since short unsigned ints are used to store each coordinate value, it seems like it's being converted to signed ints, which works fine up until that point, but at that point it breaks down. And that for some reason this only when it's been compiled on Mac OS?

I would really appreciate any help with this, as I'm having difficulty troubleshooting further.

[djseban]

Hey there, As running VM for TFS was a huge pain in the ass for me, I schooled myself a little in lldb and managed to get to the root cause of the problem, which is: int_fast16_t min_y = centerPos.y + minRangeY; int_fast16_t min_x = centerPos.x + minRangeX; int_fast16_t max_y = centerPos.y + maxRangeY; int_fast16_t max_x = centerPos.x + maxRangeX; in the first lines of function Map::getSpectatorsInternal in map.cpp. For some reason on Linux/Windows it seems to work (why? max of int16_t is 32767, so if we give a centerPos with x or y greater than 32767, e.g. 32768, it should be read as a value of -32768 [which is starting point of int16_t]). Anyway I changed these lines to that: #if defined(__APPLE__) int_fast32_t min_y = centerPos.y + minRangeY; int_fast32_t min_x = centerPos.x + minRangeX; int_fast32_t max_y = centerPos.y + maxRangeY; int_fast32_t max_x = centerPos.x + maxRangeX; #else int_fast16_t min_y = centerPos.y + minRangeY; int_fast16_t min_x = centerPos.x + minRangeX; int_fast16_t max_y = centerPos.y + maxRangeY; int_fast16_t max_x = centerPos.x + maxRangeX; #endif and problem disappeared. Enjoy. What's interesting, I recall compiling TFS with GCC on macOS and I remember the problem still occurred.

[DSpeichert]

@djseban A Pull Request would be much more helpful than this code snippet here in this issue.

[ranisalt]

why? max of int16_t is 32767, so if we give a centerPos with x or y greater than 32767, e.g. 32768, it should be read as a value of -32768 [which is starting point of int16_t]

Note: there is no guarantee that int_fast16_t is actually 16 bits wide. It's the fastest integer type with at least 16 bits.

[ramon-bernardo]

This was fixed with, no?

auto min_y = centerPos.y + minRangeY;
auto min_x = centerPos.x + minRangeX;
auto max_y = centerPos.y + maxRangeY;
auto max_x = centerPos.x + maxRangeX;