Zone.exe Crashing
 

Hello. im having a small problem. I used this server setup guide http://www.eqemulator.org/forums/showthread.php?t=32980
and everything worked fine, got my server up and running and no problems making a character and playing. but for some reason there is a character that keeps crashing the zone.exe, and their EQ crashes as well. I ran a log and this is the error I got.
[02.09. - 23:53:13] Starting Log: logs/eqemu_error_zone_4768.log
[02.09. - 23:53:13] Path File ./Maps/nexus.path not found.
[02.09. - 23:53:16] HandlePacket() Opcode error: Unexpected packet during CLIENT_CONNECTING: opcode: OP_Unknown (#0 eq=0x0000), size: 4
[02.09. - 23:53:21] HandlePacket() Opcode error: Unexpected packet during CLIENT_CONNECTING: opcode: OP_Unknown (#0 eq=0x0000), size: 1
any help would be a great. Thank you.

Ok, i've done some more poking around in the Database and whatnot, and found the problem to be summoned pets. When you summon them or if someone has one and zones with it, its an instant crash for them, and my zone.exe crashes as well. This only happens with permanent pets tho. the swarm pets and necro epic do not crash anything. any help would be great. thank you

I'm experiencing this too. Have you found a fix?

I also noticed that if the zone.exe already exists for that zone (aka static not dynamic) then it works fine. It only seems to be an issue if it has to allocate a dynamic zone, or set an unuzed zone.exe to the zone.

I'll throw my gauntlet into this fire as well. When I was running Morell-Thule on a linux box, I do not (actively) recall the zone binaries crashing, but now that I am on Windows, with VS2010 loaded, I see 2-3 zone.exe's a day throwing exceptions. My logging also shows minimal information, but I will take the info posted above and try a Pet Class tonight and see if I can get a zone to crash. If so, I might be able to debug it.

Meanwhile, since it's been years since I was involved with EQEmu, can someone remind me what Logging I can enable to get more details on zone and what it is doing? More logging might help identify this problem for all.

Thanks


PS: This is happening with current SVN code, as well as my ancient Abyss server running PEQ-Repack binaries from 11/8/2007, so I don't think it's anything new... just related to crappy Windows ;)

This will be good if you can find something definitive.

Playing on PEQ, with a mage and the Monster Summoning IV pet, it seems to cause zone crashes often. Switching to the Ward of Xegony air pet, I haven't seen a zone crash in weeks.
Similar problems have been reported by others that the Ixt (centaurish) mobs in the GoD zones sometimes cause crashes when their pets are up. Most often when someone dies or zones.

I am on crappy windows and cannot recreate this issue. Possible compile error?

I see this will probably get the same flood of interested responses as it has the last 6 years this problem has been brought up ;) aka, none.

Can anyone who runs a WINDOWS EQEmu server, confirm that zones crash when players log in under certain conditions? I'd like to know it's not just me, or maybe some missing SQL patch, or a bad compile, or config, or or or, anything >I< have done wrong.

I have 20 dynamic zones, and every couple days I check both servers, 1/2 of them are wiped out caught in a JIT error waiting for me to clear it so they can reboot. This is ridiculous.

I do not remember seeing this problem on Linux, but that may be because in Linux the zone simply reboots quietly. I think I'll be switching both my EQEmu servers BACK to linux this week... sigh. Just makes it harder to debug issues, which is why I moved to Windows in the first place.


So really, devs? experts? community gurus? You got nothing? :D

Ever run a memory test program like Memtest86+?

I am having the same issue with a character logging on but only after I updated my QUESTS folder to the most recent version. All of my characters login just fine if I remove the QUESTS folder...

What is this going to do? Not being a smarty pants, I seriously am asking. Since all my machines are Virtual Machines, I doubt there is anything wrong with my memory sticks ;)

I am 100% positive this is an EQEmu code issue, since it's been happening for 5+ years.


Vincire, if I can ever reproduce this crash myself, I'll have to try your suggestion. Maybe it is something Quest related?

You come across as a douchebag btw(the irony is not lost on me~).

Do I need to explain it further?

I love how stupid people's mind works... a repack from 2007 is crashing and so is the current code SO IT MUST BE EXACTLY THE SAME REASON!!!!!!

To be honest though, the one common factor is you so most likely you screwed something up(most windows ops do not experience 2-3 crashes a week let alone every day).

Attach the debugger to it and see where it crashes.

Just because they are on virtual machines doesn't mean you don't have bad hardware. But, I was offering help to eliminate the possiblity of it being hardware related. There are a lot of Windows servers with no problems, so I doubt it is a stock code problem.

Why is debugging issues harder on Linux? You can use GDB to evaluate core dumps on linux, which gives better insight into the cause of crashes than I know of from any Windows tools.

I am actually in the process of setting up a Windows server to see if it is more stable than my Linux server. I will still need to find a good debug tool that I can run full-time on a production server with players on it though.

On Linux, I run into a few different types of zone crashes that I haven't been able to pin down to any exact issue yet. One of them is during the Zone::ShutDown() process when it reloads quests. The other main crash I see is during the RemoveCurrent() process when a client is removed from a zone (zoning out or died).

I am not aware of any crashes related to zoning into a dynamic zone with a permanent pet. Though, it wouldn't surprise me if that was the cause of some of the crashes I see, since they are almost all during the zoning process somewhere.

I know many of the pet related crashes from the past have been resolved, but I think there are still some remaining that we just don't have a 100% way of reproducing so they can be isolated. That is just a theory though, based on my own suspicions on the crashes I currently get.

My other suspicion on my own crashes are that they are perl related. We have a wide variety of scripts and I am sure there are issues in some of them.

Thank you, to those that are attempting to be helpful by not being flaming, retarded noob trolls ;)


Trev, thanks for the tips. I do know how to debug using gdb, bt, and whatnot, but what I was getting at by using Windows and VS2010 was an attempt to use a GUI that I am familiar with to see exactly what's missing, causing the crashes.


The problem with spinning off 20 zones using VS2010 debug are simply the resources allocated to this one VM. That, and a horrid lack of interest in really solving someone elses bug (I have my own project to worry about ;))


By posting here, I was merely hoping to stir up interest in solving a problem that, regardless of the generalizations mentioned here, have been happening for years... on various databases, including the PEQ ones I used to run.


I will set up my Linux server once again, and this time try and pay attention of Zone (binary) crashes there too, or if it's just my crappy Windows environment(s).

Thanks again.

But, it isn't someone elses bug, it's yours. If zones were crashing as much as you say for everyone there would be more discussion about it. If you're not willing to narrow it down don't expect someone else to do it for you.

My zones don't crash. If they did I'd track it down and fix it.

That's the incredible irony though, isn't it? It does happen, probably to many servers, and, there is discussion about it. You know why there isn't more? Because of responses like the ones I am getting here... from people calling me "stupid", that I can't possibly know what I'm talking about, or that I haven't done enough on my own to warrant anyone else offering a constructive opinion.


Let me ask this; why is this my bug, because it is happening to me? Do you write software (seriously asking)? Because if you do, then you would comprehend that software should never "crash" for any reason. There is an anomaly in this code, code not written by me, that causes it to abnormally terminate (crash!) under a specific condition, and that, sir, is not MY BUG. If Zone.exe Crashes, then it is an issue within EQEmu code, not in John Adam's personal server.


If this makes me sound like a "stupid douche-bag", then sorry... fact is, I am reporting what others DO experience, and instead of getting helpful replies, I am getting lectured on proper debugging ethics. I do not have time to debug, or I would. And, EQEmu is not my project, so I am asking IT'S community for help -


And by "help" I do not mean solve MY problem, but instead, remind me (and others) what potential issues MIGHT be (spells.txt, quests, pets as a few have suggested). Any other replies about how poorly I debug my own problem are irrelevant.

All software crashes under a specific condition. Maybe you can narrow down what is causing your situation? What does the debug say for your crash?

Yes, I do write software for a living, but I am not clairvoyant, so I don't automatically know why your server is crashing. If you can't or won't take the effort to narrow it down to a set of repeatable steps then how is anyone else going to know what the cause is and fix it?

Considering every response was helpful except for mine I think you need to chill out. Yea you do sound like a douchebag for saying things like it has been happening for 5 years but I havent been involved for the last few years(how can you make a statement like that when you havent been around for all of the time) and also the way you were calling out the devs.

There is a way to ask for help without being a douchebag, you choose the douchebag way and a single person called you on it so you don't get to play the poor persecuted minority.

I also fail to see how your life is SO busy you cant debug it, dont get me wrong, Im sure the line up of super models to bang never ends but tell them to pleasure each other for 15 min so you can get it done.

Please keep the thread civil, or it will be locked.

John, I don't think everyone here knows your history around the emu's so you may not see the respect you are normally used to on the EQ2 forums. I know you have done a ton of work and been involved in EQ1 and EQ2 emus for many years now.

I think the thing that is getting to people is that you are reporting an issue that you claim is not your bug because you didn't write the code. Keep in mind that this project has been going on for about 10 years now and almost all of the people who have written for it prior to about 5 years ago are long gone. That means there are potential bugs that no one currently involved in the project wrote. So, since they weren't written by us, does that mean we should just wait for the original writers to come back and fix them? Yes, we have some devs now and we have resolved a huge number of bugs in the code over the past few years. We do still have limited resources though and rely on the skilled community members to help out when and where they can. If you are going to put a fair amount of time into something and there is something that "bugs" you about it, it makes sense to try to help to resolve that issue if it can be done in a reasonable amount of time. I am sure you have the skills to do so if you wanted.

I am all for reporting and discussing bugs, which is what this thread was created for. Maybe we can find enough details and information to pinpoint the issue. Unfortunately, without something to directly point the finger to, this bug (if there really is one) cannot be easily found.

I am pretty sure at least some of my crashes on Linux are due to the wrong version of libraries that I am running (more current ones).

I don't think PEQ sees nearly as many crashes as I see regularly. I have looked into it quite a bit, so it isn't like I am not trying. I just haven't found anything that really stands out as the possible cause for my own particular crashes. Some of them definitely seem to be heap corruption. I don't know, but there is probably more than 1 thing working against me here lol.

I always run user-mode crash dumps on windows. You can read about them here:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Keep in mind when you are debugging the executable via this form, the Program Debug dataBase (or .pdb) file must match the executable that generated it. That means making a clean build (or rebuild) as opposed to just hitting "build" in vs2010.

Minidumps will show you the relevant information to the crash, Full dumps will show you the irrelevant information (and the whole program in memory) from the time your application crashed. It will show line numbers and is very interactive.

PS: Welcome back, John!

You can also set up a symbol server to store the executables and pdb files when you build so you will always be able to debug your dumps without worrying about matching anything up. Just add a batch file with the appropriate commands as a post-build step.

http://entland.homelinux.com/blog/20...symbol-server/