Leaderboard

A little something I've been working on to make the game a bit different than what I've been playing for years. http://www.mediafire.com/download/m4oryjsxcvxrevv/OGG_Project.rar I will also consider suggestions

happened around 1:30am server time, i was transfering pds to add percent to psycho raven. gmt +8 around 4:30 pm here. also my current 99pds from other banks. and i lost them there. please add them too when i get rolled back thank you. GC: 42150776 slot: 1 Name: Colossus lost items: Wedding dress not minimum ( not max either) Red Ring (max stat) Adept Centurion Battle Centurion Ability Dark Meteor 100 0 0 100 80 Psycho Raven 15 0 10 40 Geung-si 5 150 45 0 twins/dolphin/pilla Tellusis 5 171 24 0 dolphin/pilla Cure Freeze cant provide photos for the mag Tellusis 5 171 24 0 pb: dolphin and pilla here is what my inventory should have. lost items here's what my inventory has now...

I guess this will actually require a rollback... were you transferring?

Df field Greenil ep 1 ultimate So Dimenian 1/2949 Pinkal ep 1 ultimate So Dimenian 1/2949 Purplenum ep 1 ultimate Bulclaw 1/2294 Whitill ep 1 ultimate Bulclaw 1/2294 Redria ep 1 ultimate La Dimenain 1/1472 DF shield (not the armor, the shield which is used to make From The Depths) is the one that drops for christmas event.

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

:"L hope u get ur stuff back

Phantasmal world 3 seems to be a good mission to get it, if you use Yellowboze you can even find a yasminkov 7000v!

i was just transferring photon drops from other accounts... just to add percent to psycho raven.

Best drop is Yellowboze Sinow Zoa ep 1 ultimate. All other drops are Sinow Zele, which are much rarer to find. Seabed is a hard area, racast/racaseal have freeze traps which are very useful, frozen shooter, arrest needle, and good hell weapons also useful for other enemies in that area.

Ιs not pleasant, what is it going on but everything will go well don't worry pal.

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?

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!