Strange Issues with our new 64 Bit Server

[KingMort]

Well ok some of you are already aware of the 3rd augment being deleted off everyone's gear on Raid Addicts which sadly lead to a 2 day Inventory rollback...

We are now having a weird issue where anything Tradeable/Stackable is being made no drop when zoning... But for me in my case it's only stacks of 20.. If I summon a stack of 19 and zone then it's still tradeable

Anyway has anyone upgrading to 64 bit had this type of issue.. If so how did you fix it...

There is other strange things as well Helmet graphics not working suddenly and some of our Rules aren't being loaded either..

Also zoning into certain zones you end up under the world.. and mob's agro radius seems larger ect

King

[gaeorn]

I have a test server running 64bit and I have seen stackable items become nodrop. However, I never got around to investigating it. It probably is another type casting issue (or, rather, lack of type casting).

I'll see if I can take a look at it later.

[KingMort]

Thanks a ton... Really messes up our economy lol

[trevius]

If 64bit Linux is giving you a lot of issues, is there any reason why you couldn't simply go down to a 32bit kernel? I don't think you would see much performance difference between the 2 kernels. The only reason to even go 64bit as far as I am concerned is if your server has more than 4GBs of RAM. Even then, you could just use the big-mem kernels to still utilize the RAM, just a bit less efficiently (that is what I do).

Not that it would be a bad thing to have the code corrected to work with 64bit properly, but if it is causing you a headache, maybe it would be an easier route for you. Changing a kernel out on Debian is very easy using apt-get install.

[KingMort]

Yeah would like to stay 64 we have 6 gigs atm and raising that to 12 gigs soon...

But yeah if all else fails we may have too..

Thanks for the info Trev

[gaeorn]

Ok, I can consistently duplicate this bug. If I put 20 stackable items items in the first slot of the bag in the first bag slot, it becomes no drop after zoning. If I split that stack into 19 in the first slot of the bag and 1 in the last main inventory slot, upon zoning the 19 stay no drop but the 1 changes back to droppable.

I also tried combining the stacks to see what kind of results I got. If I drop a partial stack of no drop onto the droppable version, they all become droppable. If I drop a partial stack of the droppable onto the no drop version, they all become no drop.

I also found that if I start with the 19 and 1 in the locations I stated in the first paragraph with them all droppable, they all stay droppable.

From what I am seeing, it appears this is a problem with the data being sent to the client about the item. This could be caused by corrupting the data when it is read from the DB or later when it is being sent to the client. I'll see what I can find.

[gaeorn]

The following code changes to trunk appear to fix both the disappearing augments and the nodrop appearing on some items after zoning for 64bit machines. I have not tested this extensively but I no longer am able to reproduce the nodrop problems I saw before this change. I also highly doubt this could break anything since it simply type casts the values to the same as the vsnprintf format in MakeAnyLenString is expecting.

Index: common/shareddb.cpp
===================================================================
--- common/shareddb.cpp (revision 6)
+++ common/shareddb.cpp (working copy)
@@ -254,8 +254,8 @@
                                "       augslot1,augslot2,augslot3,augslot4,augslot5)"
                                " VALUES(%lu,%lu,%lu,%lu,"
                                "       %lu,%lu,%lu,%lu,%lu)",
-                               account_id, slot_id, inst->GetItem()->ID, charges ,
-                               augslot[0],augslot[1],augslot[2],augslot[3],augslot[4]);
+                               (unsigned long)account_id, (unsigned long)slot_id, (unsigned long)inst->GetItem()->ID, (unsigned long)charges ,
+                               (unsigned long)augslot[0],(unsigned long)augslot[1],(unsigned long)augslot[2],(unsigned long)augslot[3],(unsigned long)augslot[4]);


                        ret = RunQuery(query, len_query, errbuf);
@@ -290,8 +290,8 @@
                                "       augslot1,augslot2,augslot3,augslot4,augslot5)"
                                " VALUES(%lu,%lu,%lu,%lu,%lu,%lu,"
                                "       %lu,%lu,%lu,%lu,%lu)",
-                               char_id, slot_id, inst->GetItem()->ID, charges, inst->IsInstNoDrop() ? 1:0,inst->GetColor(),
-                               augslot[0],augslot[1],augslot[2],augslot[3],augslot[4] );
+                               (unsigned long)char_id, (unsigned long)slot_id, (unsigned long)inst->GetItem()->ID, (unsigned long)charges, (unsigned long)(inst->IsInstNoDrop() ? 1:0),(unsigned long)inst->GetColor(),
+                               (unsigned long)augslot[0],(unsigned long)augslot[1],(unsigned long)augslot[2],(unsigned long)augslot[3],(unsigned long)augslot[4] );

                        ret = RunQuery(query, len_query, errbuf);
                }