Linux crashing

[John Adams]

Never seen a backtrace that didn't work on Linux before... player logs in and immediately the world dies.

Code: Select all

[New Thread 0xa05fab70 (LWP 27095)]
[Thread 0xa05fab70 (LWP 27095) exited]
14:17:00 D Items     : Loading items for character 'Foof' (123)
14:17:00 D Guilds    : Updating Guild Member Info for Player: 123

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa0dfbb70 (LWP 27092)]
0xb7f7f5c4 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() ()
   from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0xb7f7f5c4 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() ()
   from /usr/lib/libstdc++.so.6
Cannot access memory at address 0xa0dfaecc
(gdb)

I see "char_traits" but I am unsure if that's some C++ thing or our own character traits data.

[John Adams]

Home now, so I logged into FFS and did some battle with a crab, leveled up and stood there. Talking with Foof, he planned to log in so I started running around and the server crashed. Got a bigger backtrace this time --

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa21fdb70 (LWP 28042)]
0xb7f7f5c4 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() ()
from /usr/lib/libstdc++.so.6
(gdb) bt
#0 0xb7f7f5c4 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() ()
from /usr/lib/libstdc++.so.6
#1 0x081cfa82 in ~EQ2_16BitString (this=0xb2e1bcd0, __in_chrg=<value optimized out>)
at Items/../../common/types.h:163
#2 ~Book_Info (this=0xb2e1bcd0, __in_chrg=<value optimized out>) at Items/Items.h:617
#3 ~Item (this=0xb2e1bcd0, __in_chrg=<value optimized out>) at Items/Items.cpp:768
#4 0x082424e1 in ~Quest (this=0xb2e1c9c0, __in_chrg=<value optimized out>) at Quests.cpp:350
#5 0x0822b5b8 in Player::CheckQuestFlag (this=0x84014d8, spawn=0x9e30fe8) at Player.cpp:2959
#6 0x082773f9 in Spawn::spawn_serialize (this=0x9e30fe8, spawn=0x84014d8, version=1199) at Spawn.cpp:202
#7 0x08218855 in NPC::serialize (this=0x9e30fe8, player=0x84014d8, version=<value optimized out>) at NPC.cpp:150
#8 0x082fdb4f in ZoneServer::CustomizeSpawn (this=0x9899368, spawn=0x9e30fe8, client=0x83e3120)
at zoneserver.cpp:2561
#9 0x08301b63 in ZoneServer::CheckSendSpawnToClient (this=0x9899368, client=0x83e3120, initial_login=false)
at zoneserver.cpp:907
#10 0x0830a02c in ZoneServer::CheckSendSpawnToClient (this=0x9899368) at zoneserver.cpp:922
#11 0x08323a23 in ZoneServer::SpawnProcess (this=0x9899368) at zoneserver.cpp:982
#12 0x08323d58 in SpawnLoop (tmp=0x9899368) at zoneserver.cpp:5070
#13 0xb7c6a96e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#14 0xb7bd998e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

I think this was all me, Foof's client didn't even hit the server yet.

[John Adams]

Wonder why struct Book_Info is being called in that stack? Any clues? We have no books. But maybe the EQ2 string is crashing.

Edit: Oh, it's just the last safe_delete in the ~Item deconstructor: safe_delete(book_info);

[John Adams]

And Foof, DB Project server is starting with a new error. Not sure if it's suspect, since the error doesn't tell me what file/quest it is.

Code: Select all

16:24:31 E LUA       : Error processing Quest: attempt to call a nil value

[thefoof]

Ah that's probably because I also took the quest script I was working on off after this started happening (again just to see if it was cause), I loaded it back on there so see if it still says that.

[John Adams]

This is not a fix, but I commented out the

Code: Select all

safe_delete(book_info);

in Items.cpp, and no more crashing.

[Scatman]

This is fixed. The problem was only for books as John suspected above. The problem was, when creating the `book_info' structure in Item::SetItemType, the structure was being memset()'d. It is a very bad idea to memset() C++ objects. The Book_Info struct contains two EQ2_16_Bit_Strings, (author and title) which contains an std::string. After a memset(), the entire object gets messed up and any attempt to set and/or get the object will result in undefined behavior. I also changed this in SetItem copy so it does not use memcpy(), and instead uses std::string oper== to copy the strings.

The reason this did not crash when world loaded was because there was a strlen() check around the author and title. So if the author or title was 0 length in the db, it did not get set. I believe this is the case with all the items currently in the database Fun stuff, huh? So that quest in FrostFang has that book as a reward or quest step or something, so it had to actually create a copy of the book from the master book in master_item_list, which internally copies the book_info structure using memcpy() which was already messed up previously from memset().

[thefoof]

This is fixed. The problem was only for books as John suspected above. The problem was, when creating the `book_info' structure in Item::SetItemType, the structure was being memset()'d. It is a very bad idea to memset() C++ objects. The Book_Info struct contains two EQ2_16_Bit_Strings, (author and title) which contains an std::string. After a memset(), the entire object gets messed up and any attempt to set and/or get the object will result in undefined behavior. I also changed this in SetItem copy so it does not use memcpy(), and instead uses std::string oper== to copy the strings.

The reason this did not crash when world loaded was because there was a strlen() check around the author and title. So if the author or title was 0 length in the db, it did not get set. I believe this is the case with all the items currently in the database Fun stuff, huh? So that quest in FrostFang has that book as a reward or quest step or something, so it had to actually create a copy of the book, which internally copies the book_info structure using memcpy() which was already messed up previously from memset().

Okay that makes much more sense why this started because I just fixed quest rewards loading.

[John Adams]

Okay that makes much more sense why this started because I just fixed quest rewards loading.

That sure would have been helpful to know

Scat, thanks for looking into the scary world of Linux (that actually had nothing to do with Linux I guess) and getting this massive show-stopper fixed. I noticed you commented out a lot of stuff, and in my quick review it's mostly initialized stuff that never gets used (warning cleanup?) Some of that code is stuff I started and ran out of intellect to finish. Maybe we can talk about those at some point.

Jabantiz, please review his changes in SpellProcess.cpp, specifically around "error_offset", which seemed to be set all over the place but never used. Maybe your new "spell_errors" implementation made that obsolete? Just double check, please.

And now we know 2 things; memset = bad, and int32 = good :p

[Scatman]

I spoked with jab about error_offset last night on IRC and he gave me the ok to remove it.

Memset is very good! Just not on classes. Only use it on primitive types (structs without any classes, int, float, etc)

[thefoof]

viewtopic.php?f=3&t=3562

Also I figured out why single item rewards were't showing - the queries in WorldDatabase.cpp were checking for subtype "Items", when we've always used it looks like (since milestone 1), "Item", so I fixed that.

But yeah sorry would have mentioned it but I'm clueless with most crashes hah.

[John Adams]

Oh, silly me! If only I had the Helm of You-Guessed-It, Mind-reading +200...

I should have mentioned Quests, Items, Books.

#2 ~Book_Info (this=0xb2e1bcd0, __in_chrg=<value optimized out>) at Items/Items.h:617
#3 ~Item (this=0xb2e1bcd0, __in_chrg=<value optimized out>) at Items/Items.cpp:768
#4 0x082424e1 in ~Quest (this=0xb2e1c9c0, __in_chrg=<value optimized out>) at Quests.cpp:350

Oh wait, I did