Occasional crashes -- normal?

[KaL]

Hey all. Longtime ShowEQ user (I used it before they implemented encryption, and I used it when we used to have to get libEQ.a) and I have a question.

My ShowEQ runs pretty good, except for the occasional unknown spawn, and the occasional crash. I know that during some periods, SEQ never crashed and never gave unknowns, but that was unpredictable, usually as a function of how recent the .exe had changed. Are there people out there who get absolutely perfect performance out of SEQ now or is this normal behavior?

Thanks.

[purple]

Backtraces or error messages will increase the quality of responses you might get to this!

[Cryonic]

unknowns can also be traced to other issues, such as dropped packets...

[KaL]

Backtraces or error messages will increase the quality of responses you might get to this!
Ok, I'll try to collect these. Usually, though, SEQ crashes at the worst time -- like I'm in a group and I'm trying to make my way through some dangerous zone or something.

I was just wondering if the crashes were a possible function of local factors, like OS, network condition, etc, or if it's a function of the network stream and the protocol isn't 100% figured out, or if SEQ just has bugs.


unknowns can also be traced to other issues, such as dropped packets...
Aye, I kinda figured that. They're rare, though.

[purple]

seq has bugs for sure, but nothing that I know of that causes a crash. Most crashes are caused by dropped packets which can be mitigated by intelligently setting networking kernel parameters. But without any sort of backtrace or error message, it's really hard to recommend anything.

Right now, auras can be flagged unknown pretty easily as of last patch but it's not that big of a deal. There's also a problem where sometimes when a pet zones out, it turns into an unknown. But again, it's kinda rare.

[Some1Else]

I've been a silent observer for a while now, using SEQ for maybe a year or so.

I've been experiencing similar crashing activity since the PoR expansion. The most common theme is a raid situation with one or more Auras running in the zone being zoned into. No relationship to whether I have an aura running or not.

There doesn't seem to be any correlation to the zone itself, as it happens in many zones, both old and new.

My linux knowledge is erratic, as I know a lot about some things and next to nothing about others. If someone can point me to some instructions or FAQ about the backtraces, or point out if there is an error/crash log created by SEQ, I'd be glad to post the error information and help out the community.

[purple]

To get a backtrace, instead of running showeq from the commandline, run "gdb showeq" and from the gdb prompt, type run. If you normally do "showeq -i eth0 --log-zone" or whatever, then do "gdb showeq" then "run -i eth0 --log-zone" from the (gdb) prompt.

This will slightly slow things down, but not really. I run under the debugger most of the time. Anyways, when you crash, the gdb prompt will come back. In that window, type "bt" and then cut and paste that gibberish into a post over here.

Alternately, you can also tcpdump crashes and get me tcpdumps.

To do this (especially useful if it is a reproducable crash), you need tcpdump. Then do tcpdump -i eth0 -s0 -w yousuckfixthis.log 'udp && 192.168.1.100' (where the ip is the ip of your EQ client). Then zone in EQ and then go reproduce your bug. Once you crash seq, control-C the tcpdump, gzip yousuckfixthis.log and then find some way to get me yousuckfixthis.log.gz. Either PM me an URL or email the dump to seqdump at gmail.com or get on #showeq and we'll figure something out. Don't start tcpdump until after you log in. I don't want your login password and you shouldn't want me to have it.

[KaL]

Thanks for the instructions, purple. I'm restarting showeq right now with gdb so I can provide the trace for next time. And of course, it hasn't crashed in a few days.

[Some1Else]

I started running with gdb last night and didn't get any backtraces. Each crash was a buffer overflow which looked like a cumulation of lost packets.

I've been running under ettercap for a few months so I tried switching back to the hub I was using before and SEQ hasn't crashed on me since. All the excess error logging traffic from the auras is probably too much for ettercap to handle and its losing excessive packets in the process.

I'll still be running under gdb and attempting a bt in the event of a crash, but at least I have much better stability this way, even if I have to have the extra hardware connected.

[SchwannyT]

I'm also getting occasional crashes, and I can never reproduce them. I was crashing constantly at one point and started watching my traffic better as was loosing a LOT of packets. New ISP and a new wireless G router later and the crashes have all but stopped. However I do still get buffer overflow errors when unzipping the packets (64 bit system) that only happens sporatically (it'll happen twice in 10 minutes and then run fine in the same zone for hours). My biggest problem was the old router/wireless and a really crappy ISP. Fixed 99% of my problems

[elf]

I've never seen the command line scroll like it does with Auras around. Each aura casting 8 times each time it wants to cast once, 15 auras on a raid, it gets bad fast. I have a real hub, and a relativly slow dsl pipe, so it hasn't done more to me then just bad lag.

Imagine what it's like trying to explain to an upset guild mate over IMs that, "really, auras are just casting way too much. No, just trust me, they are. I won't say how I know. Your dial up doesn't like that many things casting at once. Just imagine what 120 bards all singing different MGB aoes every 3 seconds."

[KaL]

Warning: SEQ: Giving up on finding arq 0196 in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 0197 in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 0198 in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 0199 in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 019a in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 019b in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 019c in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 019d in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 019e in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 019f in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 01a0 in stream client-zone cache, skipping!
Warning: SEQ: Giving up on finding arq 01a1 in stream client-zone cache, skipping!
Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in new fragment to buffer with seq 01ae on stream 2, opcode 44b1. Buffer is zie 4114 and has been filled up to 3926, but tried to add 505 more!

I used the sysctl command you posted on the eqitems site to increase the buffer size.

[purple]

Read the FAQ file that comes with seq. There's a couple more kernel params you can set to help.

[tanner]

The Link (http://faq.eqenchanters.org/index.php?action=artikel&cat=383683&id=40&artlang=en)

[KaL]

Ok, I've made the changes described in the FAQ. Shame on me for not searching, I know.

Anyway, SEQ crashed with a segfault last night, but I didn't catch it because I forgot to start it under the debugger.

[Quark]

Below is the backtrace from a segfault I had earlier, not sure if it will help or not since I don't have the associated packet stream. Fedora Core 5, btw.


#0 0x05037738 in QListViewItem::takeItem ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#1 0x05046412 in QListViewItem::~QListViewItem$base ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#2 0x08149066 in ~SpawnListItem (this=0xb60f91e0) at spawnlistcommon.cpp:47
#3 0x08078147 in QPtrList<QListViewItem>::deleteItem (this=0x19d, d=0x0)
at /usr/lib/qt-3.3/include/qptrlist.h:150
#4 0x052429dd in QGList::clear () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#5 0x0807809a in ~QPtrList (this=0xb70b8ac8)
at /usr/lib/qt-3.3/include/qptrlist.h:93
#6 0x08075a41 in SpawnList::delItem (this=0xa13ee68, item=0xb60d1170)
at spawnlist.cpp:488
#7 0x080779ae in SpawnList::qt_invoke (this=0xa13ee68, _id=86, _o=0xbfb26980)
at /usr/lib/qt-3.3/include/private/qucom_p.h:312
#8 0x04f45211 in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#9 0x08072daa in SpawnShell::delItem (this=0xa006a80, t0=0xb60d1170)
at spawnshell.moc:289
#10 0x0807044b in SpawnShell::deleteItem (this=0xa006a80, type=413, id=3731)
at spawnshell.cpp:257
#11 0x080735c1 in SpawnShell::qt_invoke (this=0xa006a80, _id=167799424,
_o=0xbfb26aa0) at spawnshell.cpp:1016
#12 0x04f452aa in QObject::activate_signal ()
---Type <return> to continue, or q <return> to quit---
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#13 0x0808f709 in EQPacketDispatch::signal (this=0xa1d2b08,
t0=0xb70eb8b7 "\223\016", t1=4, t2=2 '\002') at packetinfo.moc:99
#14 0x0808688a in EQPacketStream::dispatchPacket (this=0x9f95580,
data=0xb70eb8b7 "\223\016", len=4, opCode=13238, opcodeEntry=0xa0a8e30)
at packetstream.cpp:435
#15 0x08087723 in EQPacketStream::processPacket (this=0x9f95580,
packet=@0xbfb26c40) at packetstream.cpp:716
#16 0x0808763b in EQPacketStream::processPacket (this=0x9f95580,
packet=@0xbfb26d40) at packetstream.cpp:801
#17 0x08086f57 in EQPacketStream::handlePacket (this=0x9f95580,
packet=@0xbfb26d40) at packetstream.cpp:566
#18 0x0809215a in EQPacket::dispatchPacket (this=0x9fe63b0, packet=@0xbfb26d40)
at packet.cpp:658
#19 0x08091d90 in EQPacket::processPackets (this=0x9fe63b0) at packet.cpp:582
#20 0x080942a9 in EQPacket::qt_invoke (this=0x9fe63b0, _id=2, _o=0xbfb28e48)
at packet.moc:577
#21 0x04f452aa in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#22 0x04f45c3d in QObject::activate_signal ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#23 0x052d08f9 in QTimer::timeout () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#24 0x04f6c6bf in QTimer::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
---Type <return> to continue, or q <return> to quit---
#25 0x04edca1b in QApplication::internalNotify ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#26 0x04ede059 in QApplication::notify ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#27 0x04ed093c in QEventLoop::activateTimers ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#28 0x04e8510f in QEventLoop::processEvents ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#29 0x04ef6135 in QEventLoop::enterLoop ()
from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#30 0x04ef5fde in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#31 0x04edc65f in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#32 0x08068149 in main (argc=1, argv=0xbfb29230) at main.cpp:712

[purple]

That's a good backtrace. You use the old spawn list instead of the new(er) spawn list 2?

[Quark]

Yes, I use the old spawnlist. Got used to it years ago and never switched over to the new one.

[purple]

I don't understand enough of the convoluted qt code in the old spawn list to figure this out right now. I'll run with the old spawn list for a bit to see if I can reproduce it. I'm assuming this has to do with auras showing up sometimes without being in ZoneSpawns or getting a NewSpawn, but then still seeing a delete spawn for them.

[KaL]

[root@localhost ~]# gdb `showeq --ip-address=192.168.1.202 --restore-all`
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
bash: /usr/bin/gdb: Argument list too long
[root@localhost ~]#
FC4, SEQ compiled from src. This was a new one on me. Usually it's the "tried to add blah blah blah", or just a core dump.

[Cryonic]

reread the directions you were given for using gdb, KaL
http://showeq.net/forums/showpost.php?p=40592&postcount=7

[-Spoon-]

I get that same traceback rather often, also using Fedora Core 5, Test 2. I'm using the FC4 version of Pcap, but haven't reverted QT yet. It occurs with Spawnlist 2 also. I'm sure QT4 will be an even bigger mess. I'll see about building with the FC4 QT and see if that helps.

[purple]

You're not gonna get seq to build with qt4 I don't think.

KaL, you have to do "gdb showeq" and then "run --ip-address=192.168.1.202 --restore-all" to run inside gdb.

Can anyone get a packet dump of that backtrace? I ran all last night without problems. Did this start with auras?

[KaL]

Oops, sorry for the newbness.

[Quark]

I think most of my issues are directly related to qt-3.3.5. Since downgrading to 3.3.4 I havent had a crash in several days, where previously it was at least once an hour.

[purple]

I guess that's possible. The dumps are all in QT classes when they crash and I've poured over it and nothing is obviously wrong.

dropper ~ # equery list qt
[ Searching for package 'qt' in all categories among: ]
* installed packages
[I--] [ ] x11-libs/qt-3.3.4-r8 (3)

So I'm still on 3.3.4 as well. I haven't had any crashes.

[-Spoon-]

Likewise, downgrading to 3.3.4 has done the trick for me as well. I haven't tried 3.3.6 yet, but I'd assume that Quark is running it if he is on Core 5 release.

[CeleSEQ]

I'll install FC5 soon and see if I can spot something.

[Quark]

I upgraded to qt 3.3.6 last night from rawhide just to see if it works. So far so good. The one thing I noticed is that with FC5 I needed to compile with gcc32 to avoid some Spawnmonitor class error that I didn't feel like researching how to fix.