Client closes after teleport / restart in town / change character

[Debloat 83]

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

[Vaynz 1794]

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

[Debloat 83]

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

[Debloat 83]

Topic updated with more info, I am still seeking help...

[Amun 1813]

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

[Debloat 83]

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

[Amun 1813]

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!

[Debloat 83]

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

[Amun 1813]

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

[Debloat 83]

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

[Amun 1813]

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;
	}

 

[Debloat 83]

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 :: 

 

[Amun 1813]

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

[Debloat 83]

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

[xTryhard 12]

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

[Debloat 83]

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 

[xTryhard 12]

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

[PetePeter 36]

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

[Debloat 83]

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!