Debloat 88 Posted February 17, 2022 Share Posted February 17, 2022 (edited) As the title says, that's the issue that I'm having a hard time with. There's no syserr in anything. Client, debug or server all clear. And the crash seems extremely random. Some teleport attempts succeed and some fail. Demo: VS Debug: Can someone help please? Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal Link to comment Share on other sites More sharing options...
Active Member Vaynz 1909 Posted February 17, 2022 Active Member Share Posted February 17, 2022 (edited) Debug and is simple. Marty tutorial This is the hidden content, please Sign In or Sign Up . Good luck ! Edited February 17, 2022 by Vaynz 44 2 1 2 1 9 1 16 Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 18, 2022 Author Share Posted February 18, 2022 (edited) 15 hours ago, Vaynz said: Debug and is simple. Marty tutorial This is the hidden content, please Sign In or Sign Up . Good luck ! Oh sir thank you so much! So this is the bugged part. However, this doesn't seem easy to understand to me... How can I trace this error in the actual code? P.s nevermind I applied the next step and it worked. Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal 1 1 Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 18, 2022 Author Share Posted February 18, 2022 Topic updated with more info, I am still seeking help... Link to comment Share on other sites More sharing options...
Contributor Amun 1921 Posted February 23, 2022 Contributor Share Posted February 23, 2022 (edited) I've had a similar problem in the past and it was because of a window that wasn't working properly(Either from some shop system or the inventory, I think). I can't remember exactly what I've done to fix it(because it was years ago), but you could take a look at this: However, be mindful about it and test it thoroughly. Edit: Now that I see the function, yes, I don't really understand why the loop is there, since vector.clear() should reset its size to 0, thus deleting everything(maybe for debugging?). What I would do is this: void CWindowManager::__ClearReserveDeleteWindowList() { for (TWindowContainer::iterator itor = m_ReserveDeleteWindowList.begin(); itor != m_ReserveDeleteWindowList.end(); ++itor) { CWindow* pWin = *itor; #ifdef __WINDOW_LEAK_CHECK__ gs_kSet_pkWnd.erase(pWin); #endif if (pWin->GetName()) { TraceError("Attempting to delete %s", pWin->GetName()); } else { auto parentName = pWin->GetParent() ? pWin->GetParent()->GetName() : 0; if (parentName) { TraceError("Attempting to delete unnamed window. Parent: %s, parent name: %s", pWin->GetParent(), parentName); } else { TraceError("Attempting to delete unnamed window. No parent. Any children? %i", pWin->GetChildCount()); } } delete pWin; TraceError("Window deleted."); } m_ReserveDeleteWindowList.clear(); } And then you'll know exactly if the problem is coming from a window or not, since you'll never see "Window deleted" after the window's(or parent's) name. Note: I have not tested the code, but it should work fine. Also, you can replace TraceError with Trancefn, if you want to use log.txt instead of syserr.txt Good luck! Edited March 2, 2022 by Amun + Tracen->Tracefn 1 1 Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 24, 2022 Author Share Posted February 24, 2022 (edited) 11 hours ago, Amun said: I've had a similar problem in the past and it was because of a window that wasn't working properly(Either from some shop system or the inventory, I think). I can't remember exactly what I've done to fix it(because it was years ago), but you could take a look at this: However, be mindful about it and test it thoroughly. Edit: Now that I see the function, yes, I don't really understand why the loop is there, since vector.clear() should reset its size to 0, thus deleting everything(maybe for debugging?). What I would do is this: void CWindowManager::__ClearReserveDeleteWindowList() { for (TWindowContainer::iterator itor = m_ReserveDeleteWindowList.begin(); itor != m_ReserveDeleteWindowList.end(); ++itor) { CWindow* pWin = *itor; #ifdef __WINDOW_LEAK_CHECK__ gs_kSet_pkWnd.erase(pWin); #endif if (pWin->GetName()) { TraceError("Attempting to delete %s", pWin->GetName()); } else { auto parentName = pWin->GetParent() ? pWin->GetParent()->GetName() : 0; if (parentName) { TraceError("Attempting to delete unnamed window. Parent: %s, parent name: %s", pWin->GetParent(), parentName); } else { TraceError("Attempting to delete unnamed window. No parent. Any children? %i", pWin->GetChildCount()); } } delete pWin; TraceError("Window deleted."); } m_ReserveDeleteWindowList.clear(); } And then you'll know exactly if the problem is coming from a window or not, since you'll never see "Window deleted" after the window's(or parent's) name. Note: I have not tested the code, but it should work fine. Also, you can replace TraceError with Trancen, if you want to use log.txt instead of syserr.txt Good luck! Thank you so much for the answer bud! I tried your code and it works fine. However, I think the problem is not with the window deletion, because it crashes after the deletion, and when the loading phase begins. This is the log: Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal Link to comment Share on other sites More sharing options...
Contributor Amun 1921 Posted February 24, 2022 Contributor Share Posted February 24, 2022 I don't have time look around and find out if miplevel can be 0(maybe I'll do it later, if it's not fixed), but you could try something like this: if (!m_pbCompBufferByLevels[miplevel]) { TraceError("No m_pbCompBufferByLevels[miplevel]"); // return false; } memcpy(pbDest, m_pbCompBufferByLevels[miplevel], m_lPitch >> (miplevel * 2)); If that's the last message you see in syserr, just uncomment return false and it should be ok. Let me know if that works, Cheers! 1 Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 24, 2022 Author Share Posted February 24, 2022 (edited) 17 minutes ago, Amun said: I don't have time look around and find out if miplevel can be 0(maybe I'll do it later, if it's not fixed), but you could try something like this: if (!m_pbCompBufferByLevels[miplevel]) { TraceError("No m_pbCompBufferByLevels[miplevel]"); // return false; } memcpy(pbDest, m_pbCompBufferByLevels[miplevel], m_lPitch >> (miplevel * 2)); If that's the last message you see in syserr, just uncomment return false and it should be ok. Let me know if that works, Cheers! Unfortunately, there's still no syserr and this is the last thing in log.txt: Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal Link to comment Share on other sites More sharing options...
Contributor Amun 1921 Posted February 24, 2022 Contributor Share Posted February 24, 2022 (edited) 13 minutes ago, Debloat said: Unfortunately, there's still no syserr and this is the last thing in log.txt: Ok, remove the if statement and leave only the TraceError, to make sure it's not failing because of that. Also, what about server-side? Any errors/logs? Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 24, 2022 Author Share Posted February 24, 2022 (edited) 2 hours ago, Amun said: Ok, remove the if statement and leave only the TraceError, to make sure it's not failing because of that. Also, what about server-side? Any errors/logs? The server side is completely clear of syserrs. Now when I removed the if statement and leave only the TraceError as such: I get this Syserr in log.txt Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal Link to comment Share on other sites More sharing options...
Contributor Amun 1921 Posted February 24, 2022 Contributor Share Posted February 24, 2022 From what I see, VS doesn't complain about it anymore(the warning) when I add the if statement so, maybe the destination is null? Try it like this: if (!pbDest || !m_pbCompBufferByLevels[miplevel]) { return false; } Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 24, 2022 Author Share Posted February 24, 2022 16 minutes ago, Amun said: From what I see, VS doesn't complain about it anymore(the warning) when I add the if statement so, maybe the destination is null? Try it like this: if (!pbDest || !m_pbCompBufferByLevels[miplevel]) { return false; } Unfortunately, no luck with this... Still crashing without any errors. Same as before, the last thing in the log is 0224 20:38:12373 :: PointWindow: BackGround 0224 20:38:12688 :: 0224 20:38:12689 :: ## Network - Loading Phase ## 0224 20:38:12690 :: Link to comment Share on other sites More sharing options...
Contributor Amun 1921 Posted February 24, 2022 Contributor Share Posted February 24, 2022 4 minutes ago, Debloat said: Unfortunately, no luck with this... Still crashing without any errors. Same as before, the last thing in the log is 0224 20:38:12373 :: PointWindow: BackGround 0224 20:38:12688 :: 0224 20:38:12689 :: ## Network - Loading Phase ## 0224 20:38:12690 :: Man, I swear it doesn't make any sense.. Run it in debug again and see if there's any changes in the breakpoints Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 24, 2022 Author Share Posted February 24, 2022 (edited) 9 minutes ago, Amun said: Man, I swear it doesn't make any sense.. Run it in debug again and see if there's any changes in the breakpoints Seems like the memory leak is in the same place, but notice that this is only the top of the call stack, there are many things in the Call Stack that I don't understand well. Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal Link to comment Share on other sites More sharing options...
Premium xTryhard 12 Posted February 24, 2022 Premium Share Posted February 24, 2022 (edited) 5 hours ago, Debloat said: Seems like the memory leak is in the same place, but notice that this is only the top of the call stack, there are many things in the Call Stack that I don't understand well. you are using 477MB Memory right now shown on your screenshot that means you are not out of memory even if there is a leak you still have memory and this is not the reason why your client close when you relog Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal 1 Link to comment Share on other sites More sharing options...
Debloat 88 Posted February 25, 2022 Author Share Posted February 25, 2022 10 hours ago, xTryhard said: you are using 477MB Memory right now shown on your screenshot that means you are not out of memory even if there is a leak you still have memory and this is not the reason why your client close when you relog what I don't understand is the code that crashes the client is exactly the same in other files. I'm really lost Link to comment Share on other sites More sharing options...
Premium xTryhard 12 Posted February 25, 2022 Premium Share Posted February 25, 2022 (edited) 4 hours ago, Debloat said: what I don't understand is the code that crashes the client is exactly the same in other files. I'm really lost the debugger dont show you in every case the position where it is crashing i mean he shows you but it is not always the position where the problem is you have to look into where the crash will happen in this case you have to look first into python what will happen if you press the "relog" button this will lead you into the client source and you have to debug from there every step i believe if you press the button you send a CMD command to the server maybe a Packet is wrong when the server answers you Edited February 25, 2022 by xTryhard Link to comment Share on other sites More sharing options...
PetePeter 36 Posted February 25, 2022 Share Posted February 25, 2022 (edited) 20 hours ago, Debloat said: Seems like the memory leak is in the same place, but notice that this is only the top of the call stack, there are many things in the Call Stack that I don't understand well. Use the call stack to see the older function called (CreateDDSTexture, CreateFromMemoryFile) you will see the image the game try to load, the problem must come from one texture badly loaded or something like that. The crash don't mean the code is bad, try to look deeper than the last call stack Edited August 17, 2022 by Metin2 Dev Core X - External 2 Internal 1 Link to comment Share on other sites More sharing options...
Debloat 88 Posted March 5, 2022 Author Share Posted March 5, 2022 Guys thank you so much! I have spotted the problem and found a fix. The client crashes because of an image file called fog.tga. YMIR did a poor job (as usual) in their code and this guide fixed it for me! Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now