seq crashes in death

[eqhunter]

Im getting

General: Unknown: 121
Player: Exp: New: 388, 388 (194/330) into level with 512 left [~1 kills]
Segmentation fault

was wondering if this has a fix

hunter :confused:

[purple]

Give a stack trace please. If you can reproduce this, instead of "showeq" run "gdb showeq" then at the (gdb) prompt, type run. Seq should start normally. Go about whatever you were doing and make it crash. When it crashes, go back to the window where you did gdb and type "bt" and it will give you a backtrace of where the crash was. Cut and paste that entire thing here.

Also, you may want to copy your eqstr_us.txt and spells_us.txt to your /usr/local/share/showeq folder.

[eqhunter]

heres what I got

(gdb) bt
#0 0x7c892404 in ?? ()
#1 0x0812a48d in GroupMgr::totalLevels (this=0x86544f8) at group.cpp:331
#2 0x08103b05 in ExperienceWindow::addExpRecord (this=0x86ba0b0,
mob_name=@0x8637ea8, mob_level=65, xp_gained=394) at zonemgr.h:46
#3 0x081061ae in ExperienceWindow::qt_invoke (this=0x86ba0b0,
_id=-1073779824, _o=0xbfff6c20) at qucom_p.h:449
#4 0x00366139 in QObject::activate_signal ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#5 0x081133c8 in Player::expGained (this=0x8756540, t0=@0x875712c, t1=65,
t2=394) at player.moc:596
#6 0x081102c0 in Player::updateExp (this=0x8756540,
data=0x38 <Address 0x38 out of bounds>) at zonemgr.h:44
#7 0x08113d1b in Player::qt_invoke (this=0x8756540, _id=14, _o=0xbfff6db0)
at qucom_p.h:312
#8 0x00366139 in QObject::activate_signal ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#9 0x0808e2d9 in EQPacketDispatch::signal (this=0x87c0c00, t0=0x88f8c72 "￿",
t1=8, t2=2 '\002') at packetinfo.moc:99
#10 0x08085e72 in EQPacketStream::dispatchPacket (this=0x86e9258,
data=0x88f8c72 "￿", len=8, opCode=18449, opcodeEntry=0x8642a00)
at packetstream.cpp:418
#11 0x080868d9 in EQPacketStream::processPacket (this=0x86e9258,
packet=@0xbfff6f70) at packetinfo.h:300
---Type <return> to continue, or q <return> to quit---run
#12 0x0808681f in EQPacketStream::processPacket (this=0x86e9258,
packet=@0xbfff6fe0) at packetstream.cpp:691
#13 0x08086649 in EQPacketStream::processPacket (this=0x86e9258,
packet=@0xbfff70c0) at packetstream.cpp:577
#14 0x0808637b in EQPacketStream::handlePacket (this=0x86e9258,
packet=@0xbfff70c0) at packetstream.cpp:508
#15 0x0809120c in EQPacket::dispatchPacket (this=0x5a14, packet=@0xbfff70c0)
at packet.cpp:751
#16 0x08090f30 in EQPacket::processPackets (this=0x87441d8) at packet.cpp:638
#17 0x08093429 in EQPacket::qt_invoke (this=0x87441d8, _id=2, _o=0xbfff91c0)
at packet.moc:553
#18 0x00366139 in QObject::activate_signal ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#19 0x00365fdd in QObject::activate_signal ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#20 0x0064753b in QTimer::timeout () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#21 0x003870f2 in QTimer::event () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#22 0x003085b4 in QApplication::internalNotify ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#23 0x00307d7b in QApplication::notify ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#24 0x002e3795 in QEventLoop::activateTimers ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
---Type <return> to continue, or q <return> to quit---bt
#25 0x002c10b8 in QEventLoop::processEvents ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#26 0x0031c306 in QEventLoop::enterLoop ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#27 0x0031c1a8 in QEventLoop::exec () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#28 0x003087e1 in QApplication::exec () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#29 0x08067f42 in main (argc=1, argv=0x86c3570) at main.cpp:702

[purple]

Stupid group manager. Were you in a group at the time or soloing? I didn't even know it was possible to use the group manager!

[eqhunter]

Stupid group manager. Were you in a group at the time or soloing? I didn't even know it was possible to use the group manager!

Been in a raid everytime. and it only crashes after Im rezzed.

[uRit1u2CBBA=]

raiding nightly here, dying most nights and rezzes to follow.

So far I've never had a problem.

No clue where to start looking as to why you are crashing.

[BlueAdept]

Been in a raid everytime. and it only crashes after Im rezzed.

Do you happen to be 2 boxing on the same machine?

[eqhunter]

Do you happen to be 2 boxing on the same machine?


Nope.. I have 3 comps at my desk. I am thinking of using Wine soon but running EQ on XP and SEQ on redhat WS 3

[purple]

I futzed around with the group manager a bit, but I couldn't reproduce your problem. If you just wanna wait and maybe I fixed something, that's fine. If you want a for sure fix, you'll need to get me a tcpdump that causes the crash. Note that doing this will send me your EQ character name and guild, so don't do this if you are not comfortable with that. You won't send me any passwords if you follow my instructions.

1) Log into EQ
2) At some point at or after character select, start tcpdump on your linux box like so:

tcpdump -i eth0 -s0 -w groupcrash.log '192.168.1.100 && udp'

NOTE: Replace eth0 with your network interface if needed. Replace 192.168.1.100 with the IP of your EQ client machine. As long as you start tcpdump _after_ you've logged in, the dump will not contain your password. I won't give anyone the dump and it will only be used by me to fix the crash in seq.

3) Zone in EQ so that the stream resets. This is important. You can't just start tcpdump in the middle of a zone. If you start at character select, initial logging in is the same as zoning.
4) Go about whatever it is you do to make it crash. It doesn't matter how long it takes or whatnot, though the longer it takes, the bigger the dump will be. That's really not a problem though. The important part is that you crash seq in the end.
5) Stop tcpdump by hitting control-C in its window
6) gzip groupcrash.log
7) Figure out a way to get me the log

If the log is small, you might be able to PM it to me using this board. Alternately, if you have web space, you can post it and PM me where I can download it. Alternately, you can email it to [email protected] and I'll pick it up from there. Again, only do this if you are comfortable with me knowing your EQ character name and information. I won't do anything with it, but if you aren't comfortable sending me that information, then by all means, don't do it.

[gruntsters]

I'm having the exact same problem. Only crashing when rezzed. If my fingers are fast, I can fire up SEQ again before the zoning info starts (gotta love the up_arrow_key), and SEQ works fine until I get rezzed again. This happens while I'm raiding almost every rezz. I'll have to look to see how often it occurs while grouping or not in a group tho. I'm running WinEQ on the EQ client machine, but it doesn't matter if I have one or multiple accounts running on it at the time.


Would it be alright if I follow your instructions to send you my dump ? Would take me a couple of days, but I could upload several dumps to one of my websites and provide the link to it.

[uRit1u2CBBA=]

It's best to have it running in advance. I imagine he'd want to see the zoning into the bound zone in addition to attempting to get rezzed and get zoned back to your corpse.

[purple]

Yep! The more dumps the better! I'll never argue with too much info. It's the not enough that is harder to deal with *grin*. It should be an easy fix once I have a dump of it.

[purple]

And I did futz around with the group manager code so who knows, maybe I've fixed it already. There's a patch this week, so probably a release too. If we can get this fixed before that, I'll be happy.

[elf]

Group management has been substantially reworked. You can now invite players to your group from other zones and from any distance in the same zone.
The bad news is that over on the test server, the group management system has been changed. Alot. Rumor mill says it's due for live servers the 22nd.

[purple]

I sure hope it makes it live this week. Having WoW-style grouping will be really useful.

[eqhunter]

what do you mean by " It's best to have it running in advance "?



It's best to have it running in advance.

[gruntsters]

Okies, I had to change the tcpdump command to make it work for me. I hope the below looks like it will work.

tcpdump -i eth0 -s0 -w groupcrash.log dst 192.169.1.100 && udp

changed the ip to my ip address on my eq client machine of course. Will dst give you the info that you need ? I couldn't get it to work with or without the quotes. I kept getting syntax errors.

Also, next question. Do I need to rename the log file for each instance? Or will it append the next tcpdump that I attempt?

Now that I think about it, it sounds like you need packets from my machine rather than just the ones it receives. If so, I'm stumped at getting tcpdump to work. I don't get any syntax errors if I leave off the ip address, but of course that won't get the data.

[uRit1u2CBBA=]

what do you mean by " It's best to have it running in advance "?

SEQ has to see you zone into a zone for any information in it to be meaningfull.

So if you start SEQ before you click yes on your rez box, and the crash happens as the one zone is leaving before the new zone is loading, it won't be seen since it didn't see you zone into the zone that you were trying to leave.

So if you start SEQ before you die, then when you die, it will get the zone into your bound zone getting the information possible, then when it crashes, it will have in memory or log file somewhere the information that caused it (then after that, it's a matter of tracking it down).

[purple]

Oops, my bad. I meant:

tcpdump -i eth0 -s0 -w groupcrash.log 'host 192.168.1.100 && udp'

You need to make new logs if you want to take multiple.

[gruntsters]

AH HA !

yeah, that works much better, thanks, will use tonight and gather some logs.

[OgerSEQ]

Just wanted to mention I've also had this happen when getting rezzed in same zone as corpse. Was in group but not raid when this happened as well.

[purple]

I got two logs from Gruntsters. One of them I no longer crash on, the other has dropped packets causing the crash. So hopefully I've fixed this group manager crash that the stack trace was showing up above. If you're seeing that crash, you may want to update from CVS (you can look at the Changelog to see what updates you'll get). I probably won't release until after the patch next week.

Crashes that have:
Warning: SEQ: Giving up on finding arq 0218 in stream zone-client cache, skipping!
Warning: SEQ: Giving up on finding arq 0219 in stream zone-client cache, skipping!
Warning: SEQ: Giving up on finding arq 021a in stream zone-client cache, skipping!
Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in new fragment to buffer with seq 034d on stream 3, opcode 04ed. Buffer is size 101905 and has been filled up to 101737, but tried to add 505 more!

... in them are dropped packets and not a seq problem. I'll start another thread explaining this yet again!

[purple]

Is this still happening?

[eqhunter]

dont know.. haven got SEQ to work.. still fighting the qt thing

[gruntsters]

still happens occasionally for me, but if I read and understood your last response, its from dropped packets. I'll just live with it, don't feel like jacking around with my linux box that much for an occasional problem. Oh yeah, running the .24 version now.

[purple]

If you see "giving up on" messages, it's dropped packets. Go read the FAQ file in your source directly, specifically #4. There's no reason to just live with it when you can mess with your kernel params and fix it.

If you don't see "giving up on" messages, then that's a seq problem that needs to be fixed.

[gruntsters]

Alright, I've been beaten into submission, hehe. I'll look into it this weekend.