ryzom
Client crashes anywhere where it needs to load a lot of textures
Original report by Guillaume DUPUY (Bitbucket: [Guillaume DUPUY](https://bitbucket.org/Guillaume DUPUY), ).
I'm running the client under a debian sid (with gnome-shell) ; i often (not always) get a crashes when i enter the Canyon pass. It also happened once in Lucenthead pass (which is not that far away). This is a self compiled client using commit cf686e1 (incremental ID 2846), with standard option + debugging symbols. The attachment are 3 log record from gdb (though they are almost the same)
Original comment by Guillaume DUPUY (Bitbucket: [Guillaume DUPUY](https://bitbucket.org/Guillaume DUPUY), ).
Added a new gdb log, pretty much the same (this happened on canyon pass just before the bridge this time)
Original comment by Guillaume DUPUY (Bitbucket: [Guillaume DUPUY](https://bitbucket.org/Guillaume DUPUY), ).
Same crash, but different place (still in desert though). this time i was ~200meters west from Thesos.
Original comment by Jan Boon (Bitbucket: [Jan Boon](https://bitbucket.org/Jan Boon), ).
Please include client log files
Original comment by Cédric Ochs (Bitbucket: [Cédric OCHS](https://bitbucket.org/Cédric OCHS), ).
I think I got the same crash and it doesn't depend on sound driver like I thought first.
The think very strange is I was running the client from VC++ 2010 and it crashed without created a break point in code. It only left the client with return code 3.
I was using OpenAL driver and that's strange it didn't display anything about it :(
Here are last lines of my client.log :
2015/11/14 17:13:01 WRN 150c ryzom_client_d.exe streamable_ig.cpp 93 CStreamableIG::loadAsync : Loading async 00000000264F3C78
2015/11/14 17:13:01 WRN 150c ryzom_client_d.exe streamable_ig.cpp 93 CStreamableIG::loadAsync : Loading async 00000000264F3C78
2015/11/14 17:13:02 WRN 150c ryzom_client_d.exe streamable_ig.cpp 93 CStreamableIG::loadAsync : Loading async 00000000264F3C78
2015/11/14 17:13:02 WRN 150c ryzom_client_d.exe streamable_ig.cpp 93 CStreamableIG::loadAsync : Loading async 00000000264F3C78
2015/11/14 17:13:02 WRN 150c ryzom_client_d.exe streamable_ig.cpp 93 CStreamableIG::loadAsync : Loading async 00000000264F3C78
2015/11/14 17:13:02 WRN 150c ryzom_client_d.exe streamable_ig.cpp 93 CStreamableIG::loadAsync : Loading async 00000000264F3C78
2015/11/14 17:13:01 ryzom_client_d.exe AST 17b8 fixed_size_allocator.cpp 187 : "Chunk->NumFreeObjs > 0"
-------------------------------
User Crash Callback:
-------------------------------
UserId: 17536
HomeId: 101
ShardId: 101
On a Mainland Shard
Application: ryzom_live
Player Name: 'Xiombarg'
UserPosition: 4464.99 -3293.33 -11.82
ViewPosition: 4464.99 -3293.33 -11.82
Time in game: 0h 31min 49sec
LocalTime: 2015/11/14 17:13:01
ServerTick: 1110361423
ConnectState: Connected
LocalAddress: :63042 (192.168.1.2)
Language: Français
ClientVersion: 2.1.0
PatchVersion: 610
Client is online
NumServerHOP: 0
NumFarTP: 0
NumReselectPerso: 0
Connection Events:
Memory: 1432MB/8190MB
Process Virtual Memory: 1704MB
OS: Microsoft Windows 10 (Build 10240) (10.0 10240)
Processor: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz / Intel64 Family 6 Model 23 Stepping 10 / GenuineIntel / 2500MHz / 4 Processors found
CPUID: bfebfbff
HT: NO
CpuMask: f
NeL3D: OpenGL / (null) / (null) / (null)
Sound mixer:
Playing sources: 114
Playing simple sources: 17 / 84
Available tracks: 15
Used tracks: 17
Muted sources: 0
Sources waiting for play: 0
HighestPri: 0 / 2
HighPri: 0 / 4
MidPri: 17 / 6
LowPri: 0 / 8
FreeTracks: 15 / 32
Average update time: 0.000015 msec
Average create time: 0.000000 msec
Estimated CPU: 0.000046%%
Sound driver:
-------------------------------
Original comment by Jan Boon (Bitbucket: [Jan Boon](https://bitbucket.org/Jan Boon), ).
Nice timestamp order there.
My guess is on something violating the non-thread-safety of fixed_size_allocator.
Original comment by Cédric Ochs (Bitbucket: [Cédric OCHS](https://bitbucket.org/Cédric OCHS), ).
Yep, I'll try to force on one core to be sure it's not related to that. And if it doesn't works better, I'll use normal new/delete instead of fixed_size_allocator.
Original comment by Jan Boon (Bitbucket: [Jan Boon](https://bitbucket.org/Jan Boon), ).
Force one core won't make difference since threading works on one core too... :)
Original comment by Cédric Ochs (Bitbucket: [Cédric OCHS](https://bitbucket.org/Cédric OCHS), ).
Do you think it could occurs because to simultaneous access/write from different threads and so it'll need a mutex ?
I added a comment some years ago about that (a TODO in my TortoiseHg's shelve) :p
Original comment by Jan Boon (Bitbucket: [Jan Boon](https://bitbucket.org/Jan Boon), ).
I'd recommend putting a debug check in the fixed_size_allocator to verify that it's only being used by one thread at a time, and dump a callstack every time a different thread accesses it, to find out where it is being used in a conflicting manner.
Original comment by Cédric Ochs (Bitbucket: [Cédric OCHS](https://bitbucket.org/Cédric OCHS), ).
It's really strange, I played a lot today, I used several teleports and never crashed :p
Original comment by Jan Boon (Bitbucket: [Jan Boon](https://bitbucket.org/Jan Boon), ).
Maybe memory corruption caused by another bug then? :p
Original comment by Cédric Ochs (Bitbucket: [Cédric OCHS](https://bitbucket.org/Cédric OCHS), ).
Yep perhaps :)
Original comment by Cédric Ochs (Bitbucket: [Cédric OCHS](https://bitbucket.org/Cédric OCHS), ).
Got it again just after entering Zora :p
Original comment by Cédric Ochs (Bitbucket: [Cédric OCHS](https://bitbucket.org/Cédric OCHS), ).
Maybe related to c7af0f4733a29fc14f5ea4c7033beeedd8fe706d, closing because not enough recent info to reproduce.
