- Status Closed
- Percent Complete
- Task Type Bug Report
- Category
-
Assigned To
Caarrie Thom Lanarel peeg Mario Rohkrämer Steven Schwartfeger Mrokii weltall - Operating System
- Severity Low
- Priority
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#2425 - Server crash when viewing container
Got this crash on trunk server when looking at other bugs. I make this a separate report since this is the same point (more or less) where Laanx is currently crashing every five minutes.
What I did:
- venge opened chest, put mug in
- with window open, venge dropped chest. Mug disappears from view immediately (so not possible to pick it out as suggested in bug 2333 )
- acraig presses eye-icon to view container. Server crashes, with this call stack:
> psserver.exe!csRef<iMeshWrapper>::operator iMeshWrapper *() Line 354 + 0xf bytes C++
psserver.exe!gemMesh::GetMesh() Line 110 C++
psserver.exe!gemObject::GetMeshWrapper() Line 814 C++
psserver.exe!gemObject::GetPosition(csVector3 & pos={...}, iSector * & sector=0x7ffdf000) Line 1140 + 0x8 bytes C++
psserver.exe!ProximityList::RangeTo(gemObject * object=0x032c6870, bool ignoreY=false) Line 445 C++
psserver.exe!gemObject::RangeTo(gemObject * obj=0x032c6870, bool ignoreY=false) Line 857 C++
psserver.exe!Client::CanTake(psItem * item=0x02832a4c) Line 524 + 0x14 bytes C++
psserver.exe!psItem::FillContainerMsg(Client * client=0x032ca028, psViewItemDescription & outgoing={...}) Line 2406 + 0xc bytes C++
psserver.exe!psItem::SendContainerContents(Client * client=0x032ca028, int containerID=-1) Line 2609 C++
psserver.exe!psItem::ViewItem(Client * client=0x032ca028, int containerID=10079, INVENTORY_SLOT_NUMBER slotID=PSCHARACTER_SLOT_NONE) Line 2828 + 0x10 bytes C++
psserver.exe!psServerCharManager::ViewItem(Client * client=0x032ca028, int containerID=10079, INVENTORY_SLOT_NUMBER slotID=PSCHARACTER_SLOT_NONE) Line 205 C++
psserver.exe!psServerCharManager::ViewItem(MsgEntry * me=0x032b8ec0) Line 152 C++
psserver.exe!psServerCharManager::HandleMessage(MsgEntry * me=0x032b8ec0, Client * client=0x032ca028) Line 367 C++
psserver.exe!MsgHandler::Publish(MsgEntry * me=0x032b8ec0) Line 71 C++
psserver.exe!EventManager::Run() Line 199 C++
psserver.exe!psServer::MainLoop() Line 555 C++
psserver.exe!main(int argc=2, char * * argv=0x003f5710) Line 81 C++
psserver.exe!__tmainCRTStartup() Line 597 + 0x19 bytes C
psserver.exe!mainCRTStartup() Line 414 C
kernel32.dll!7c817067()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
psserver.exe!com_exec(char * line=0x00720075) Line 1640 + 0x11 bytes C++
psserver.exe!psWorkManager::HandleProductionEvent(psWorkGameEvent * workEvent=0x00000000) Line 913 + 0x1c bytes C++
a845c704()
Crashes on Laanx are also in FillCOntainer, sometimes in CanTake (from FIllContainer), few times IsNPCOwned (from CanTake).
Closed by weltall
02.11.2008 16:00
Reason for closing:
Additional comments about closing:
02.11.2008 16:00
Reason for closing:
Additional comments about closing:
The improved patch was backported on
laanx and Mononoke wasn't able to crash
the server anymore so we can consider
this fixed. Reopen if laanx start
crashing again :P
I couldn't verify this, sorry.
Confirming.
- Look into a wooden crate containing items.
- Pick up and drop items in it.
- Pick up and drop the crate while the Examine window stays open
- Look into the crate again: Server crashes.
The items displayed in the Examine window do not disappear reliably after dropping a container. The content does not get updated on several other activities with the container or the content (e.g. trying to stack similar items in the container).
Ligh: you have the power to change the status, now
Now that I can, I have to look if I should…
I am not surprised if this would be a difficult to reproduce thing, so I think the first effort should be to find a recipy to reproduce this reliably. The crashes on Laanx in this part of the code (13 in the last 12 hours) incidicate that this may be something that only happens under certain circumstances, but with higher number of players often enough to make the server very unstable.
Managed to crash trunk server several times again (same stack, also exactly where Laanx crashed earlier today). I did not manage at once though. This is what I did:
- clean db
- venge /item-ed chest, put waybread recipy in.
- WIth container view open, dropped chest. View turns empty
- acraig logged in, was teleported to venge, viewed chest, saw recepy. Closed view again
- venge picked up chest. Waybread now re-appeared in still open view.
- venge dropped it again, and I immediately clicked in the view window again (no clue if that is important, but it is the only difference :) )
- acraig views container.
Crash
THings that may effect this: venge clicking in window, acraig keeping view open, ???
edit:
in the debugger, I see that in this case it crashes because a pcmesh is not valid
In function Client::CanTake(psItem* item), where guardingActor→RangeTo(gemitem) is called, gemitem looks ok, but:
gemitem→gemActiveObject→gemObject→pcmesh has a value that looks ok, but all its members are '???', resulting several
function calls deeper in gemitem→gemActiveObject→gemObject→pcmesh→mesh causing a crash.
Can someone who knows what he is doing check this patch:
http://psnopaste.byethost32.com/?NzI5OD
I think it is a similar ID problem as before (same place a change was made a few lines above). I tested and could no longer produce the crash. ALso, the code seemed to be ok, which is an even better sign :)
If this was the problem (a FindEntity instead of a FindObject), there may be similar problems in IsNPCOwned as well.
Better fix:
http://psnopaste.byethost32.com/?ODY0Zj
Seemed the FIndObject/FIndEntity mixup may be so wrong that it is right, and all it does it find a gemContainer pointer to the container, which is always known where CanTake is called. So this patch just passes that to the function.
Venge committed my patch. Setting ready to test.