Servers never went down today, thankfully.
Servers never went down today, thankfully.
structvis.pl. All glory to ksmith.Originally Posted by fransick
getting 2 issues.
Crashes whenever the session being monitored, has a toon that levels up.
Will often get the following, if leave my toon at the char select over night:
Code:Warning: EQPacket: SessionRequest wanted a max packet size of 1277831310 which is above our sane max packet size of 25600. Using our max
The SessionRequest thing is more than likely just a non-EQ packet being detected as an EQ Packet because of the contents. Use Session Tracking if you don't. Otherwise just ignore it.
Crashing when you level is a bad opcode or a change in the levelUpUpdateStruct. Which it is would be evident by looking at packets.
I do have session tracking turned on. Still occurs.
I will see if I can get the error, when it crashes on a level up, next time.
I had to create a toon to capture a level up packet (all main toons are 95) but I didn't level again after setting the opcode so I'll take a look as well. My main crashes on every exp update but none of my alts do. I had to just set that opcode to "0000" to avoid constant crashes. I looked at the packet and everything looks to be in order so no idea why that barfs everytime, might be something similar with level up too.
Confirmed... level up caused me to CTD as well. The packet and struct look to be right:
Everquest.h:
Packet capture when level up:Code:/* ** Level Update ** Length: 12 Octets ** OpCode: LevelUpUpdateCode */ struct levelUpUpdateStruct { /*0000*/ uint32_t level; // New level /*0004*/ uint32_t levelOld; // Old level /*0008*/ uint32_t exp; // Current Experience /*0012*/ };
Code:Jul 30 2012 20:06:45:784 [Decoded] [Server->Client] [Size: 12] [OPCode: 0x221a] [Name: OP_LevelUpdate][Updated: 07/18/12][Type: levelUpUpdateStruct (12) ==] 000 | 03 00 00 00 02 00 00 00 00 00 00 00 | ............
My new level was 3 and old was 2 so that looks correct. Additionally, I had 0% into next level. I am beginning to think between this and expupdate causing CTD that perhaps the handling of exp and % of exp is not right for some reason. Anyone have any thoughts as to what could be up. I don't see anything obvious. Will try to backtrace the next CTD and see if that shows anything.
Well wouldn't you know it... dinged 4 and had gdm ready for a backtrace and didn't CTD. Will try to level again and see if I can replicate the CTD.
Well I dinged again and didn't CTD. Below is a backtrace from what I believe to be the offending ExpUpdate. If I zone with that opcode set to the correct value it CTD every time. The packet looks to match the struct so not sure why it is bombing, Maybe someone smarter can figure out what's up with Exp.
Code:(gdb) bt #0 0x0445c52d in QString::QString(QString const&) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #1 0x0447bcfb in QUType_QString::set(QUObject*, QString const&) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #2 0x080fa04a in Player::expGained (this=0x847d0d0, t0=..., t1=84, t2=45987979, t3=...) at player.moc:592 #3 0x080fa340 in Player::updateExp (this=0x847d0d0, data=0x885679d "\251") at player.cpp:669 #4 0x080fc99c in Player::qt_invoke (this=0x847d0d0, _id=15, _o=0xbfffc380) at player.moc:737 #5 0x04185642 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #6 0x080906cf in EQPacketDispatch::signal (this=0x8463a08, t0=0x885679d "\251", t1=8, t2=2 '\002') at packetinfo.moc:99 #7 0x08089e19 in EQPacketStream::dispatchPacket (this=0x8326620, data=0x885679d "\251", len=8, opCode=29163, opcodeEntry=0x843d238) at packetstream.cpp:435 #8 0x0808c16a in EQPacketStream::processPacket (this=0x8326620, packet=..., isSubpacket=true) at packetstream.cpp:717 #9 0x0808c44a in EQPacketStream::processPacket (this=0x8326620, packet=..., isSubpacket=false) at packetstream.cpp:805 #10 0x0808ccc8 in EQPacketStream::handlePacket (this=0x8326620, packet=...) at packetstream.cpp:570 #11 0x08093322 in EQPacket::dispatchPacket (this=0x847a078, packet=...) at packet.cpp:659 #12 0x08095bf5 in dispatchPacket (this=0x847a078) at packet.cpp:583 #13 EQPacket::processPackets (this=0x847a078) at packet.cpp:400 #14 0x08095ed0 in EQPacket::qt_invoke (this=0x847a078, _id=2, _o=0xbfffe788) at packet.moc:577 #15 0x04185642 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #16 0x04185724 in QObject::activate_signal(int) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #17 0x044ccc5a in QTimer::timeout() () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #18 0x041a5e3e in QTimer::event(QEvent*) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #19 0x04123ffd in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #20 0x0412418b in QApplication::notify(QObject*, QEvent*) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #21 0x0411823c in QEventLoop::activateTimers() () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #22 0x040d3182 in QEventLoop::processEvents(unsigned int) () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #23 0x04139b50 in QEventLoop::enterLoop() () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #24 0x04139ad7 in QEventLoop::exec() () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #25 0x04124d20 in QApplication::exec() () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #26 0x08067a8b in main (argc=1, argv=0xbffff414) at main.cpp:737
It's been forever since I've done work on seq, so ignore this if you want. But here's what went through my head for this.
Check expGained in player.cpp and you see:
This is a loose coupling setup by QT. You see how this gets hooked up in interface.cpp here:Code:emit expGained( m_lastSpawnKilledName, m_lastSpawnKilledLevel, expIncrement, m_zoneMgr->longZoneName());
So the expGained event ends up calling addExpRecord on the expWindow.addExpRecord(const QString&, int, long, QString).Code:connect(m_player, SIGNAL(expGained(const QString &, int, long, QString )), m_expWindow, SLOT(addExpRecord(const QString &, int, long,QString )));
In your backtrace, the issue is the generated code (moc) which is trying to marshall the parameters. it's trying to copy a QString based on a const QString reference. There is something wrong with the QString. You can always add in printf debugging in player.cpp right before the emit to check the values for m_lastSpawnKilledName and m_zoneMgr->longZoneName(), but it looks to me like it is the longZoneName that is messed up (because the backtrace is showing making a QString from a const QString reference and longZoneName is a const QString reference but the slot's last parm is a QString. You can always figure out how longZoneName gets set (a lookup from zones.h based on zone id from OP_ZoneEntry or OP_PlayerProfile?). But I'd just walk back all that stuff and try to figure out what is up.
Personally, I'd use tcpdump to record the crash too so that I didn't need the EQ Client to reproduce this anymore.
Never! Still learning and always eager for a little direction. On vacation this week but will play with your advice when I get back. Thanks so much for popping in and helping out even though you've long since moved on from EQ. Much appreciated!
So frustrating to not be able to help with this. I do almost all of my dev work offline with a emu server.
I glanced at seq code and didnt see anything obvious. But i only spent a few minutes looking. Tracking down bugs can be so frustrating.
Another 2 hour patch this morning. It looks like there's just a couple changes, fingers crossed for seq.
I'm guessing the Hero's Forge visible gear augs will cause some fairly massive changes...
Guessin they will use those extra bytes the added to the equipment structs awhile back. So maybe no major struct changes. Maybe.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote