Login Crashes

[Larva]

Bump.

We are still having the same problem, same error.same issue.

[leebo]

I don`t think the problem is within this function itself. It`s probably failing because the dest buffer is too small to hold the data that is being put into it. This could theoretically happen if a super long run was decompressed prior to copying the next character from src to dest (I`m referring to the line that causes the exception). Now, of course, this shouldn`t happen assuming the src buffer is properly encoded so it probably isn`t properly encoded.

If you haven`t done so already, I would just put a little piece of protective code in this function to prevent it from overflowing the dest buffer. Working backwards (in soda`s original server code), it looks like the size of the dest buffer is ultimately (ultima-tely (lol)) defined by TCP_BUFFER_SIZE which should be 65530 bytes by default which means the function knows it should never write more than TCP_BUFFER_SIZE bytes to the dest buffer. When it tries to do this, you could save a dump of the entire src buffer somewhere for later inspection. You should be able to apply the same reasoning to every method in the call stack until the problem is found and then you could remove the protective code afterwards if you choose to do so. By the way exceptions would be REALLY nice here but unfortunately C doesn`t support exceptions.

I`m not really familiar with the context for this code but if it`s trying to decompress a chunk of data that comes from the game client, the server shouldn`t expect it to be encoded properly. Unscrupulous individuals could theoretically hand-craft such a malicious piece of data to crash the server.

Anyways, putting in some protective code should help you to at least prevent the program from crashing even if you have to close a socket or something to keep it alive.That`s my 2 cents!

[chuk]

I don`t think the problem is within this function itself. It`s probably failing because the dest buffer is too small to hold the data that is being put into it. This could theoretically happen if a super long run was decompressed prior to copying the next character from src to dest (I`m referring to the line that causes the exception). Now, of course, this shouldn`t happen assuming the src buffer is properly encoded so it probably isn`t properly encoded.

If you haven`t done so already, I would just put a little piece of protective code in this function to prevent it from overflowing the dest buffer. Working backwards (in soda`s original server code), it looks like the size of the dest buffer is ultimately (ultima-tely (lol)) defined by TCP_BUFFER_SIZE which should be 65530 bytes by default which means the function knows it should never write more than TCP_BUFFER_SIZE bytes to the dest buffer. When it tries to do this, you could save a dump of the entire src buffer somewhere for later inspection. You should be able to apply the same reasoning to every method in the call stack until the problem is found and then you could remove the protective code afterwards if you choose to do so. By the way exceptions would be REALLY nice here but unfortunately C doesn`t support exceptions.

I`m not really familiar with the context for this code but if it`s trying to decompress a chunk of data that comes from the game client, the server shouldn`t expect it to be encoded properly. Unscrupulous individuals could theoretically hand-craft such a malicious piece of data to crash the server.

Anyways, putting in some protective code should help you to at least prevent the program from crashing even if you have to close a socket or something to keep it alive.That`s my 2 cents!

We took a look at it and are logging the values each time a crash happens. There is a way to simulate exceptions in C but you need to explicitly throw them... (See http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html).A for the dest, yeah it is initialized in the BANANA struct as an array of characters with the size of the TCP_BUFFER_SIZE, however we are talking about a pointer here to dest here, so the value is the address of where the destination is stored (And not always at the beginning). We are indeed assuming that message that is too long gets written to the destination but we are also considering it could be a hardware failure as well. Access violations can typically be caused by faulty RAM. Do you mind showing a code proposal where you add the protectory code around the exception throwing code?

[flanagak]

Hello all,

Im new to the server and saw the Login server crashed again today.
So I was reading the forums and found this.

Thought I might be able to help resolve this.

<quote>Unhandled exception at 0x0044cee2 in login_server.exe: 0xC0000005: Access violation writing location 0x04e04000.</quote>

1st thing to note: 0xC0000005 = Memory Heap Corruption.

This also means that most likley your stack is also going to be corrupted and may not point to the correct methods in your stack trace.

The key to debugging heap corruptions is that we need to get a memory dump just before it gets corrupted.

That way you can look at the stack at that point in time and see what is being called.

Here is a link that explains how to setup Application Verify as well as Debug Diag in order to generate a memory dump just prior to the exception.

http://blogs.msdn.com/b/lagdas/archive/2008/06/24/debugging-heap-corruption-with-application-verifier-and-debugdiag.aspx

Once you have the memory dump and App Verify data we can trace down the cause of the issue.

FYI: Running Debug Diag and App Verify on the process will cause it to consume a lot more memory during execution.

Hopefully you have plenty in the sever.

--flanagak--

In Game: Rune