Crash after receiving NewCorpseCode

[Zoolander]

I've been getting a crash with the latest version. I play on test mostly, but I've seen the warning on a production server. Not sure I've ever had the crash on a prod server though. I looked at newCorpseStruct in everquest.h and it is only 30 bytes long although from the comments it looks like it may have been 34 at some time. I assume the fields are incorrect now but I don't know enough about logging packets to figure it out.

Here's what I saw after zoning and a backtrace from gdb:

Zone: Entered: ShortName = 'NorthKarana' LongName = Northern Plains of Karana
Loading Complete... (Zone: 'NorthKarana')
No Zone Specific filter file '/usr/local/share/showeq/filters_northkarana.conf'.
Loading default '/usr/local/share/showeq/filters.conf'.
Zone: NewCode: Zone: NorthKarana (Northern Plains of Karana)
decoding 0x5229 with 0x45c1e0ba
clean uncompress on 0x1229:
decoding 0xf145 with 0xa5218149
clean uncompress on 0xb145:
decoding 0x71de with 0x67e5da5a
clean uncompress on 0x31de:
decoding 0x7144 with 0x4c1edb72
clean uncompress on 0x3144:
clean uncompress on 0x11e5:
Your player's id is 1187
clean uncompress on 0xb022:
clean uncompress on 0xb022:
WARNING: NewCorpseCode (0115) (dataLen:34 != sizeof(newCorpseStruct):30)!

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3147)]
0x404e8d13 in QString::deref() () from /usr/qt/3/lib/libqt-mt.so.3
(gdb) bt
#0 0x404e8d13 in QString::deref() () from /usr/qt/3/lib/libqt-mt.so.3
#1 0x404e8dfc in QString::operator=(QString const&) () from /usr/qt/3/lib/libqt-mt.so.3
#2 0x08114007 in Player::setLastKill(QString const&, unsigned char) (this=0x4066b164,
name=@0x83be7c8, level=4 '\004') at player.cpp:727
#3 0x0806fdba in SpawnShell::killSpawn(newCorpseStruct const*) (this=0x832c4a8,
deadspawn=0x83eb048) at spawnshell.cpp:896
#4 0x0808051d in SpawnShell::qt_invoke(int, QUObject*) (this=0x832c4a8, _id=19,
_o=0xbfffe620) at qucom_p.h:312
#5 0x4026b390 in QObject::activate_signal(QConnectionList*, QUObject*) ()
from /usr/qt/3/lib/libqt-mt.so.3
#6 0x080907dc in EQPacket::killSpawn(newCorpseStruct const*, unsigned, unsigned char) (
this=0x836bd10, t0=0x83be7c8, t1=34, t2=2 '\002') at m_packet.cpp:1315
#7 0x0808a666 in EQPacket::dispatchZoneData(unsigned, unsigned char*, unsigned char) (
this=0x836bd10, len=34, data=0x83eb048 "\025\001_\004", dir=2 '\002')
at packet.cpp:2107
#8 0x0808848c in EQPacket::dispatchPacket(int, unsigned char*) (this=0x836bd10,
size=83, buffer=0x83be7c8 "\003") at packet.h:429
#9 0x08087aee in EQPacket::processPackets() (this=0xadf) at packet.cpp:787
#10 0x0809489c in EQPacket::qt_invoke(int, QUObject*) (this=0x836bd10, _id=2,
_o=0xbfffef00) at m_packet.cpp:2177
#11 0x4026b419 in QObject::activate_signal(QConnectionList*, QUObject*) ()
from /usr/qt/3/lib/libqt-mt.so.3
#12 0x4026b2bd in QObject::activate_signal(int) () from /usr/qt/3/lib/libqt-mt.so.3
#13 0x4054dd0b in QTimer::timeout() () from /usr/qt/3/lib/libqt-mt.so.3
#14 0x4028c4e2 in QTimer::event(QEvent*) () from /usr/qt/3/lib/libqt-mt.so.3
#15 0x4020d544 in QApplication::internalNotify(QObject*, QEvent*) ()
from /usr/qt/3/lib/libqt-mt.so.3
#16 0x4020cabb in QApplication::notify(QObject*, QEvent*) ()
from /usr/qt/3/lib/libqt-mt.so.3
#17 0x401e80d5 in QEventLoop::activateTimers() () from /usr/qt/3/lib/libqt-mt.so.3
#18 0x401c58b8 in QEventLoop::processEvents(unsigned) () from /usr/qt/3/lib/libqt-mt.so.3
#19 0x40221386 in QEventLoop::enterLoop() () from /usr/qt/3/lib/libqt-mt.so.3
#20 0x40221228 in QEventLoop::exec() () from /usr/qt/3/lib/libqt-mt.so.3
#21 0x4020d771 in QApplication::exec() () from /usr/qt/3/lib/libqt-mt.so.3
#22 0x080654ca in main (argc=1, argv=0xbffff784) at main.cpp:930
#23 0x408137a7 in __libc_start_main () from /lib/libc.so.6

[fester]

Off hand I would try fixing the size of the structure in everquest.h to be the correct size.

WARNING: NewCorpseCode (0115) (dataLen:34 != sizeof(newCorpseStruct):30)!

struct newCorpseStruct
{
/*0000*/ uint8_t opCode; // 0x42
/*0001*/ uint8_t version; // 0x00
/*0002*/ uint32_t spawnId; // Id of spawn that died
/*0006*/ uint32_t killerId; // Killer
/*0010*/ uint8_t unknown0006[8]; // ***Placeholder
/*0018*/ uint32_t spellId; // ID of Spell
/*0022*/ int8_t type; // Spell, Bash, Hit, etc...
/*0023*/ uint32_t damage; // Damage
/*0027*/ uint8_t unknown0016[7]; // ***Placeholder
}; //34

to

struct newCorpseStruct
{
/*0000*/ uint8_t opCode; // 0x42
/*0001*/ uint8_t version; // 0x00
/*0002*/ uint32_t spawnId; // Id of spawn that died
/*0006*/ uint32_t killerId; // Killer
/*0010*/ uint8_t unknown0006[8]; // ***Placeholder
/*0018*/ uint32_t spellId; // ID of Spell
/*0022*/ int8_t type; // Spell, Bash, Hit, etc...
/*0023*/ uint32_t damage; // Damage
/*0027*/ uint8_t unknown0016[3]; // ***Placeholder
}; //30

This is untested and is a logical guess. Often when structures are different sizes (especially smaller) it can corrupt memory inside ShowEQ.

[Zoolander]

Hmm, the newCorpseStruct in my everquest.h isn't the same as that.

/*
** Spawn Death Blow
** Length: 18 Octets
** OpCode: NewCorpseCode
*/

struct newCorpseStruct
{
/*0000*/ uint8_t opCode; // 0x42
/*0001*/ uint8_t version; // 0x00
/*0002*/ uint16_t spawnId; // Id of spawn that died
/*0006*/ uint32_t killerId; // Killer
/*0010*/ uint8_t unknown0006[8]; // ***Placeholder
/*0018*/ uint16_t spellId; // ID of Spell
/*0022*/ int8_t type; // Spell, Bash, Hit, etc...
/*0023*/ uint32_t damage; // Damage
/*0027*/ uint8_t unknown0016[7]; // ***Placeholder
}; //34

I'll try it with what you posted and see what happens. It is looking for a 34 byte struct, not a 30 byte one.

[user387]

Fester,

the everquest.h in CVS still has uint16_t for spawnId and spellId.

that's where the problem is. you seem to have patched yours already.

[Ratt]

Fester,

the everquest.h in CVS still has uint16_t for spawnId and spellId.

that's where the problem is. you seem to have patched yours already.

Thought you said they were suppose to be uint16 ....

http://seq.sourceforge.net/forums/showthread.php?s=&threadid=3485

So should they be 16 or 32?

[Zoolander]

For what it's worth changing them to 32 bit values didn't stop my crash.

Only one of the characters I tried causes the crash. An interesting thing to note is that when the crash occurs the character name is offset by 3 bytes. Instead of something like "abcdef" it's shown as "def".

I'll fool with it some more after I do a fresh get.