Seg Fault in SEQ 5.0.0.4

[domesticbeer]

Got this when I went to save and exit



Debug: ==> EQInterface::savePrefs()
Debug: isVisible()
Finished saving preferences to file: /home/ckrull/.showeq/showeq.xml

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 5212)]
0x408a8241 in malloc_consolidate () from /lib/libc.so.6
(gdb) BT
#0 0x408a8241 in malloc_consolidate () from /lib/libc.so.6
#1 0x408a8145 in _int_free () from /lib/libc.so.6
#2 0x408a6efa in free () from /lib/libc.so.6
#3 0x4051e014 in QGArray::~QGArray() () from /usr/qt/3/lib/libqt-mt.so.3
#4 0x4052c13d in QRegExpEngine::~QRegExpEngine() () from /usr/qt/3/lib/libqt-mt.so.3
#5 0x40534e4f in QCache<QRegExpEngine>::deleteItem(void*) () from /usr/qt/3/lib/libqt-mt.so.3
#6 0x4051fada in QGCache::clear() () from /usr/qt/3/lib/libqt-mt.so.3
#7 0x40534d9d in QCache<QRegExpEngine>::~QCache() () from /usr/qt/3/lib/libqt-mt.so.3
#8 0x40534415 in QThreadStorage<QCache<QRegExpEngine>*>::deleteData(void*) () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x4050878f in QThreadStorageData::finish(void**) () from /usr/qt/3/lib/libqt-mt.so.3
#10 0x4021baf1 in QThreadInstance::finish(void*) () from /usr/qt/3/lib/libqt-mt.so.3
#11 0x4021bcdc in QThread::cleanup() () from /usr/qt/3/lib/libqt-mt.so.3
#12 0x401bc45d in qt_cleanup() () from /usr/qt/3/lib/libqt-mt.so.3
#13 0x40224644 in QApplication::~QApplication() () from /usr/qt/3/lib/libqt-mt.so.3
#14 0x0806801d in main (argc=1, argv=0xbffff310) at main.cpp:698
#15 0x4084990c in __libc_start_main () from /lib/libc.so.6


Am using QT 3.2.3 on Gentoo 1.4 with GCC 3.2.3-r3

[domesticbeer]

got a different on tonite



Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 535)]
0x408a4e31 in malloc_consolidate () from /lib/libc.so.6
(gdb) bt
#0 0x408a4e31 in malloc_consolidate () from /lib/libc.so.6
#1 0x408a4cef in _int_free () from /lib/libc.so.6
#2 0x408a3a8a in free () from /lib/libc.so.6
#3 0x40520014 in QGArray::~QGArray() () from /usr/qt/3/lib/libqt-mt.so.3
#4 0x4052e13d in QRegExpEngine::~QRegExpEngine() () from /usr/qt/3/lib/libqt-mt.so.3
#5 0x40536e4f in QCache<QRegExpEngine>::deleteItem(void*) () from /usr/qt/3/lib/libqt-mt.so.3
#6 0x40521ada in QGCache::clear() () from /usr/qt/3/lib/libqt-mt.so.3
#7 0x40536d9d in QCache<QRegExpEngine>::~QCache() () from /usr/qt/3/lib/libqt-mt.so.3
#8 0x40536415 in QThreadStorage<QCache<QRegExpEngine>*>::deleteData(void*) () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x4050a78f in QThreadStorageData::finish(void**) () from /usr/qt/3/lib/libqt-mt.so.3
#10 0x4021daf1 in QThreadInstance::finish(void*) () from /usr/qt/3/lib/libqt-mt.so.3
#11 0x4021dcdc in QThread::cleanup() () from /usr/qt/3/lib/libqt-mt.so.3
#12 0x401be45d in qt_cleanup() () from /usr/qt/3/lib/libqt-mt.so.3
#13 0x40226644 in QApplication::~QApplication() () from /usr/qt/3/lib/libqt-mt.so.3
#14 0x0806801d in main (argc=1, argv=0xbffff310) at main.cpp:698
#15 0x40848dcc in __libc_start_main () from /lib/libc.so.6

[Zaphod]

Actually the stack traces look identical... Well, the good news is it seems to be happening at shutdown and therefore isn't the worst problem in the world... The bad news is that this stack is indicative of a heap corruption occuring elsewhere and that could be a pain to track down...

Enjoy,
Zaphod (dohpaZ)

[domesticbeer]

OK i feel like a heel, posted wrong seg fault

Here is the other one



Zone: LogoutCode: Client logged out of server
Info: EQPacket: SEQClosing detected, awaiting next zone session, pcap filter: EQ Client 192.168.1.245

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1741)]
0x408a4e51 in malloc_consolidate () from /lib/libc.so.6
(gdb) bt
#0 0x408a4e51 in malloc_consolidate () from /lib/libc.so.6
#1 0x408a4cef in _int_free () from /lib/libc.so.6
#2 0x408a3a8a in free () from /lib/libc.so.6
#3 0x407e03f3 in operator delete(void*) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5
#4 0x4023d44c in QEventLoop::~QEventLoop() () from /usr/qt/3/lib/libqt-mt.so.3
#5 0x402821c2 in QObject::~QObject() () from /usr/qt/3/lib/libqt-mt.so.3
#6 0x40226817 in QApplication::~QApplication() () from /usr/qt/3/lib/libqt-mt.so.3
#7 0x0806801d in main (argc=1, argv=0xbffff310) at main.cpp:698
#8 0x40848dcc in __libc_start_main () from /lib/libc.so.6


granted this one was at shutdown too.

[mudtoe]

Can you tell me where to get the debug information? My copy of B4 is dying randomly while it's just sitting there (i.e. running but no EQ is running). Sometimes it dies within a minute of starting it, and other times it can sit there for hours with nothing to do before dying. I suspect it must be choking on some packet it's looking at from the EQ machine, trying to see if EQ has started. I launch it from a terminal window and all I see in the terminal window is a line with "Segmentation Fault", but no debug information.


mudtoe

[domesticbeer]

you need to run showeq from inside a debugger.

GDB is what i use

i start showeq like this

gdb /usr/local/bin/showeq

gdb starts then when it has a prompt
type r and press enter

Showeq will start up.

If it seg faults you can then debug it

by typing BT and hitting enter

to quit out of it type q

[mudtoe]

Thanks for the help. After sitting idle for over 12 hours B4 failed. No EQ game was in progress. Here's the information:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 16779)]
calcCRC32 (p=0xc0000000 <Address 0xc0000000 out of bounds>, length=4294951127)
at util.cpp:960
960 crc = crctab[(crc ^ *(p++)) & 0xFF] ^ (crc >> 8);
(gdb) BT
#0 calcCRC32 (p=0xc0000000 <Address 0xc0000000 out of bounds>,
length=4294951127) at util.cpp:960
#1 0x08091177 in EQPacket::dispatchPacket(int, unsigned char*) (
this=0x81e32c0, size=1402515811, buffer=0xbfffc0be "E")
at packetformat.h:255
#2 0x08090dc1 in EQPacket::processPackets() (this=0x8374300) at packet.cpp:474
#3 0x08092f8d in EQPacket::qt_invoke(int, QUObject*) (this=0x8374300, _id=2,
_o=0xbfffe170) at m_packet.cpp:518
#4 0x4027c3b5 in QObject::activate_signal(QConnectionList*, QUObject*) ()
from /usr/local/qt/lib/libqt-mt.so.3
#5 0x4027c1b5 in QObject::activate_signal(int) ()
from /usr/local/qt/lib/libqt-mt.so.3
#6 0x4059e17c in QTimer::timeout() () from /usr/local/qt/lib/libqt-mt.so.3
#7 0x4029cc3f in QTimer::event(QEvent*) ()
from /usr/local/qt/lib/libqt-mt.so.3
#8 0x4022349d in QApplication::internalNotify(QObject*, QEvent*) ()
from /usr/local/qt/lib/libqt-mt.so.3
#9 0x40222b80 in QApplication::notify(QObject*, QEvent*) ()
from /usr/local/qt/lib/libqt-mt.so.3
#10 0x4021230f in QEventLoop::activateTimers() ()
from /usr/local/qt/lib/libqt-mt.so.3
#11 0x401d44b4 in QEventLoop::processEvents(unsigned) ()
from /usr/local/qt/lib/libqt-mt.so.3
---Type <return> to continue, or q <return> to quit---
#12 0x40234bd7 in QEventLoop::enterLoop() ()
from /usr/local/qt/lib/libqt-mt.so.3
#13 0x40234a94 in QEventLoop::exec() () from /usr/local/qt/lib/libqt-mt.so.3
#14 0x402236fc in QApplication::exec() () from /usr/local/qt/lib/libqt-mt.so.3
#15 0x08067c07 in main (argc=1, argv=0xbffff274) at main.cpp:688
#16 0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6

[Zaphod]

Originally posted by mudtoe

#1 0x08091177 in EQPacket::dispatchPacket(int, unsigned char*) (
this=0x81e32c0, size=1402515811, buffer=0xbfffc0be "E")


This line troubles me. I have no idea how we could even possibly see a packet of that size since we limit the packet capture to UDP and that size is well outside of the maximum UDP packet size. I'm curious as to what could be running on your network that could cause this. Strange...

Enjoy,
Zaphod (dophaZ)

[ieatacid]

I found that downloading stuff on Kazaa (on my EQ machine) will cause SEQ to seg fault.

[Spaz]

OH NOS! The RIAA is punishing Kazaa users in a whole new way!

[mudtoe]

Are you sure that the bad length field isn't a result of an overlay?


mudtoe

[Zaphod]

Originally posted by mudtoe
Are you sure that the bad length field isn't a result of an overlay?


mudtoe

What I'm saying is that I'm unsure as to what would be causing that particular issue. I've got one instance of ShowEQ 5.0.0.4 that I've been running on my network since two days after I released it and it hasn't crashed regardless of the number of EQ sessions or other UDP activities I've had going on within my network. I do not however run Kazaa or any other file sharing software, so I'm unsure of how it might effect it. It could just be a case of memory getting walked over, but that size value is I believe the cause of the following crash, because that could cause a new to fail, which would then result in the stack trace:

calcCRC32 (p=0xc0000000 <Address 0xc0000000 out of bounds>, length=4294951127)
at util.cpp:960

From visual inspection that is the only way that I could find the EQPacketFormat::m_packet which is passed to calcCRC32 would be 0. I could of course be missing something and any help spotting it would be appreciated.

Enjoy,
Zaphod (dohpaZ)

[mudtoe]

I'm afraid I'm not a "C" programmer or a PC programmer, so the only thing I could help you with is gathering more information. My programming experience is with assembler on IBM mainframes, a far different animal. The only similarity is that when I'd see a wild value like that in a length field or address offet, I immediately smelled overlay, or something that had gone negative (I'm not sure how the integer representations work on the Intel platform, but on the mainframe it was all too easy in assembler to have a counter go negative on you if you took an overlay or didn't validate your incoming data properly).

I was thinking about what might be strange in my local network, and I could only think of one thing. I'm using the hub (Netgear DS108) for more than just the ShowEQ machine, and the EQ game machine. I've got one of the ports on the hub connected to a Netgear PE102 phoneline bridge that connects to an identical PE102 downstairs and it connects to a Netgear DS104 hub. On that hub is is SMC2655W wireless access point which services a Windows 2000 laptop, and a Sonicblue ReplayTV 4160. I had this stuff on the hub rather than the upstream Netgear MR314 router/switch because I was short of ports on the MR314, and the PE102 only runs at 10mb anyway, so the performance penalty of using a 100mb half duplex hub versus a 100mb full duplex router port wouldn't be noticable.

I seriously doubt any strange packets are coming from the Win2K laptop as it has no unusual software on it, but I'm wondering about the WAP and the ReplayTV unit. The WAP has it's own IP address so it could be sending packets, and although I thought the ReplayTV just looked like a web client, but perhaps it uses UDP to scan for other ReplayTVs on the local network.

Can you tell me if this problem is occurring before or after ShowEQ has done the IP address filtering (I have SEQ set to monitor a specific IP address, not to scan for the next client seen)? If it's after the filtering, then if a bad packet does exist it has to be coming from the EQ game machine. However, if the problem is happening before the filter is applied, then it's possible the WAP or ReplayTV is sending screwy packets across the network. If the latter is true, is there anyway when it fails under the debugger, to identify the IP address of the packet being inspected? If so, I could pinpoint the offending device.


mudtoe

[domesticbeer]

Here is another one got this when i exited SEQ before being logged out of game



#0 0x408a5c25 in _int_free () from /lib/libc.so.6
#1 0x408a4a8a in free () from /lib/libc.so.6
#2 0x407e13f3 in operator delete(void*) () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5
#3 0x402a6890 in QSingleShotTimer::~QSingleShotTimer() () from /usr/qt/3/lib/libqt-mt.so.3
#4 0x4028659e in QPtrList<QObject>::deleteItem(void*) () from /usr/qt/3/lib/libqt-mt.so.3
#5 0x40525d2e in QGList::clear() () from /usr/qt/3/lib/libqt-mt.so.3
#6 0x4028619d in QObjectList::~QObjectList() () from /usr/qt/3/lib/libqt-mt.so.3
#7 0x402a6588 in sst_cleanup() () from /usr/qt/3/lib/libqt-mt.so.3
#8 0x4022646b in QApplication::~QApplication() () from /usr/qt/3/lib/libqt-mt.so.3
#9 0x0806801d in main (argc=1, argv=0xbffff2f0) at main.cpp:698
#10 0x40849dcc in __libc_start_main () from /lib/libc.so.6

[Amadeus]

I'm not sure if these are helping or not...but here is another backtrace from a crash:



#0 0x4207494e in malloc_consolidate () from /lib/tls/libc.so.6
#1 0x42074838 in _int_free () from /lib/tls/libc.so.6
#2 0x420734d6 in free () from /lib/tls/libc.so.6
#3 0x404d00c4 in QGArray::~QGArray() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#4 0x404ddf49 in QRegExpEngine::~QRegExpEngine() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#5 0x404e678f in QCache<QRegExpEngine>::deleteItem(void*) () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#6 0x404d1b7a in QGCache::clear() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#7 0x404e673d in QCache<QRegExpEngine>::~QCache() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#8 0x404e5f50 in QRegExp::caretIndex(int, QRegExp::CaretMode) () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#9 0x404e5faa in QRegExp::caretIndex(int, QRegExp::CaretMode) () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#10 0x401aa36f in _init () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#11 0x40586c3a in _fini () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#12 0x4000c894 in _dl_fini () from /lib/ld-linux.so.2
#13 0x42029c20 in exit () from /lib/tls/libc.so.6
#14 0x420155d8 in __libc_start_main () from /lib/tls/libc.so.6

[elf]

Had 5 beta 5 giving me the same segfault after CRC errors. Upgraded to 5 beta 6, and Qt 3.3.0, and gcc 3.2.3-r3, running on Gentoo 1.4



#1 0x080945d6 in EQPacket::dispatchPacket(int, unsigned char*) (this=0x8455858, size=46, buffer=0x3d <Address 0x3d out of bounds>) at packetformat.h:255
#2 0x08094116 in EQPacket::processPackets() (this=0x58a5bddd) at packet.cpp:474
#3 0x08096a1c in EQPacket::qt_invoke(int, QUObject*) (this=0x8455858, _id=2, _o=0xbfffec30) at m_packet.cpp:518
#4 0x4029e916 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#5 0x4029e6e1 in QObject::activate_signal(int) () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#6 0x40640bdb in QTimer::timeout() () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#7 0x402c3f42 in QTimer::event(QEvent*) () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#8 0x4023c3f5 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#9 0x4023ba65 in QApplication::notify(QObject*, QEvent*) () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#10 0x40229e22 in QEventLoop::activateTimers() () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
---Type <return> to continue, or q <return> to quit---
#11 0x401e0a9a in QEventLoop::processEvents(unsigned) () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#12 0x4024e7f6 in QEventLoop::enterLoop() () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#13 0x4024e698 in QEventLoop::exec() () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#14 0x4023c671 in QApplication::exec() () from /usr/local/qt-x11-free-3.3.0/lib/libqt-mt.so.3
#15 0x0806856f in main (argc=1, argv=0x82fbe00) at main.cpp:688
#16 0x40d7490c in __libc_start_main () from /lib/libc.so.6
Hope this helps narrow down some problem. Other thing I noticed, the packets triggering the CRC errors aren't all from sony IP addresses. I'm wondering if something, like p2p packets on the network, could be triggering these errors?