Merth
06-04-2003, 09:16 AM
I downloaded from CVS on 6/1 and have been running my server with this code for the last couple of days. I've been noticing that zone.exe crashes ... *a lot*. Has anyone else been seeing this? I compiled with VS.NET and run on XP Pro.
I normally run about 20 zone handlers per server, and after 12-16 hours of uptime, I see MOST of those crash. For half of these crashes, the zone.exe window simply disappears. For the other half, I get the Dr. Watson prompt, which allows me to debug. When I open up the debugger, the current statement will be on one of these two memcpy()'s:
client.cpp - Client::RepairInventory()
if(slotid == 0){
//Cursor
memcpy(&pp.invitemproperties[0],0,sizeof(ItemPrope rties_Struct));
client.cpp - Client::RepairInventory()
else if(slotid >= 22 && slotid <= 29){
//Main Inventory
pp.inventory[slotid] = 0xFFFF;
memcpy(&pp.invitemproperties[slotid],0,sizeof(Item Properties_Struct));
The crash is reported as an attempt to write to address 0x00000000.
It's entirely possible that the debugger is not showing the current statement to me correctly - but assuming the crash is occuring on that statement, it should be easy to put an if statement in there and catch a null pointer. I've tried this, but the crash still occurs. Here are the pointer comparisons i looked at for the main inventory crash:
pp.inventory == NULL
&(pp.inventory[slotid]) == NULL
pp.invitemproperties == NULL
&(pp.invitemproperties[slotid]) == NULL
(pp = PlayerProfile_Struct, not a ptr)
So any ideas on what's causing the crash? If I am the only one experiencing this, then I'd suspect the VS.NET compiler. If everyone else is experiencing it, then maybe we can compare reports on where the crash occurs.
Furthermore, why would a memcpy() fail if the above statements pass? It's got me curious. I'm setting up windbg at the moment so I can inspect this further.
I normally run about 20 zone handlers per server, and after 12-16 hours of uptime, I see MOST of those crash. For half of these crashes, the zone.exe window simply disappears. For the other half, I get the Dr. Watson prompt, which allows me to debug. When I open up the debugger, the current statement will be on one of these two memcpy()'s:
client.cpp - Client::RepairInventory()
if(slotid == 0){
//Cursor
memcpy(&pp.invitemproperties[0],0,sizeof(ItemPrope rties_Struct));
client.cpp - Client::RepairInventory()
else if(slotid >= 22 && slotid <= 29){
//Main Inventory
pp.inventory[slotid] = 0xFFFF;
memcpy(&pp.invitemproperties[slotid],0,sizeof(Item Properties_Struct));
The crash is reported as an attempt to write to address 0x00000000.
It's entirely possible that the debugger is not showing the current statement to me correctly - but assuming the crash is occuring on that statement, it should be easy to put an if statement in there and catch a null pointer. I've tried this, but the crash still occurs. Here are the pointer comparisons i looked at for the main inventory crash:
pp.inventory == NULL
&(pp.inventory[slotid]) == NULL
pp.invitemproperties == NULL
&(pp.invitemproperties[slotid]) == NULL
(pp = PlayerProfile_Struct, not a ptr)
So any ideas on what's causing the crash? If I am the only one experiencing this, then I'd suspect the VS.NET compiler. If everyone else is experiencing it, then maybe we can compare reports on where the crash occurs.
Furthermore, why would a memcpy() fail if the above statements pass? It's got me curious. I'm setting up windbg at the moment so I can inspect this further.