I happened upon a segfault zoning into bazaar. Details look very similar to the previous post that mentioned it. Before I could do any real debugging on it the character causing the problem logged and the segfault stopped happening. . Here are the details I managed to get before he left:
Code:
Program received signal SIGSEGV, Segmentation fault.0xb7618fc0 in strcpy () from /lib/tls/i686/cmov/libc.so.6
#0 0xb7618fc0 in strcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0x08072cac in SpawnShell::fillSpawnStruct (this=0xb080cae8, spawn=0x0, data=0x850c7e4 "XXXXXXXX", len=446, checkLen=true) at /usr/include/bits/string3.h:107
#2 0x08076cd8 in SpawnShell::zoneEntry (this=0xb080cae8, data=0x850c7e4 "Deadrepp", len=446) at spawnshell.cpp:747
#3 0x08077228 in SpawnShell::qt_invoke (this=0xb080cae8, _id=8, _o=0xbfffc370) at spawnshell.moc:395
#4 0xb7b4c19a in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/libqt-mt.so.3
#5 0x08091f7f in EQPacketDispatch::signal (this=0x83c0dc8, t0=0x850c7e4 "Deadrepp", t1=446, t2=2 '\002') at packetinfo.moc:99
#6 0x0808dacd in EQPacketStream::dispatchPacket (this=0x83cdd18, data=0x850c7e4 "Deadrepp", len=446, opCode=24744, opcodeEntry=0x8324510) at packetstream.cpp:435
#7 0x0808fc03 in EQPacketStream::processPacket (this=0x83cdd18, packet=..., isSubpacket=true) at packetstream.cpp:754
#8 0x0808ff13 in EQPacketStream::processPacket (this=0x83cdd18, packet=..., isSubpacket=true) at packetstream.cpp:892
#9 0x0808fc70 in EQPacketStream::processPacket (this=0x83cdd18, packet=..., isSubpacket=false) at packetstream.cpp:659
#10 0x080905d8 in EQPacketStream::handlePacket (this=0x83cdd18, packet=...) at packetstream.cpp:572
#11 0x080997be in EQPacket::dispatchPacket (this=0x8395ef0, packet=...) at packet.cpp:659
#12 0x08099915 in EQPacket::dispatchPacket (this=0x8395ef0) at packet.cpp:583
#13 EQPacket::processPackets (this=0x8395ef0) at packet.cpp:400
#14 0x0809c7f8 in EQPacket::qt_invoke (this=0x8395ef0, _id=2, _o=0xbfffe7b8) at packet.moc:577
#15 0xb7b4c19a in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/lib/libqt-mt.so.3
#16 0xb7b4e168 in QObject::activate_signal(int) () from /usr/lib/libqt-mt.so.3
#17 0xb7eacd99 in QTimer::timeout() () from /usr/lib/libqt-mt.so.3
#18 0xb7b7066e in QTimer::event(QEvent*) () from /usr/lib/libqt-mt.so.3
#19 0xb7ae73d7 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3
#20 0xb7ae834b in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libqt-mt.so.3
#21 0xb7adce42 in QEventLoop::activateTimers() () from /usr/lib/libqt-mt.so.3
#22 0xb7a921b6 in QEventLoop::processEvents(unsigned int) () from /usr/lib/libqt-mt.so.3
#23 0xb7b003b0 in QEventLoop::enterLoop() () from /usr/lib/libqt-mt.so.3
#24 0xb7b00256 in QEventLoop::exec() () from /usr/lib/libqt-mt.so.3
#25 0xb7ae7a2f in QApplication::exec() () from /usr/lib/libqt-mt.so.3
#26 0x0806a33b in main (argc=1, argv=0xbffff444) at main.cpp:737
And here is the related entry from zone.log that caused the segfault:
Code:
Jan 27 2013 XX:XX:XX:XXX [Decoded] [Server->Client] [Size: 446]
[OPCode: 0x60a8]
[Name: OP_ZoneEntry][Updated: 01/16/13][Type: uint8_t (1) nc]
000 | XX XX XX XX XX XX XX XX 00 94 61 00 00 47 41 3a | XXXXXXXX..a..GA:
016 | b2 40 00 20 02 00 38 91 00 00 80 bf 00 00 00 00 | .@. ..8.........
032 | 01 01 00 00 00 64 ff ff 09 09 ff ff 00 00 00 00 | .....d..........
048 | 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 c0 40 | ...............@
064 | 03 1f 85 eb 3e 33 33 33 3f 80 00 00 00 00 cb 00 | ....>333?.......
080 | 00 00 54 01 00 00 05 00 00 00 0b 00 64 00 00 XX | ..T.........d..X
096 | XX XX XX XX XX 00 03 00 00 00 01 00 00 00 00 00 | XXXXX...........
112 | 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .@..............
128 | 00 ff ff ff ff ff ff ff ff 00 00 a0 ff 00 00 a0 | ................
144 | ff 00 14 c8 ff 00 00 a0 ff 00 00 a0 ff 00 14 c8 | ................
160 | ff 00 00 a0 ff 00 00 00 00 00 00 00 00 01 00 00 | ................
176 | 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 | ................
192 | 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
208 | 00 0a 00 00 00 01 00 00 00 00 00 00 00 00 00 00 | ................
224 | 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 | ................
240 | 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 | ................
256 | 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 | ................
272 | 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
288 | 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 | ................
304 | 00 00 00 00 00 01 00 00 00 5a 2b 00 00 00 00 00 | .........Z+.....
320 | 00 00 00 00 00 00 00 00 00 00 00 00 00 da 27 00 | ..............'.
336 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
352 | 00 00 00 00 00 42 84 83 00 dd 03 00 3a 00 c0 9c | .....B......:...
368 | 05 42 58 04 20 4c 69 63 68 20 4c 6f 72 64 00 00 | .BX. Lich Lord..
384 | 00 00 00 00 00 00 00 00 30 30 30 30 30 30 30 30 | ........00000000
400 | 30 30 30 30 30 30 30 30 00 ff ff ff ff ff ff ff | 00000000........
416 | ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
432 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ..............
**Update
Seems like the problem is with the decision on spawn->otherData. In this case the value is 0x91. if(spawn->otherData & 1). True in this case, and based on the comments in the source that means it's a chest or untargettable, which it isn't. Following the logic and the data read for the chest/untargetable block consumes the last name data before it should be read. This means that later in the code when the last name is read it's going to read something random.