EQEmulator Forums - I got shmat issues...

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Support::Linux Servers (https://www.eqemulator.org/forums/forumdisplay.php?f=588)

- - I got shmat issues... (https://www.eqemulator.org/forums/showthread.php?t=23186)

I got shmat issues...

I took a stab at fixing the 13th Floor Item import script (by actually fixing the Items table itself). On my Windows test box, all went swimmingly - server booted, I was able to log in and see the nearly 6,000 new items.

Sourced the new items table over to my Linux server, and it sh*t the bed, so to speak. When "world" launches, it spits out this error message:

Code:

failed to get 0-length shared mem: Cannot allocate memory

shmat failed! Invalid argument

Upon investigating what "shmat failed!" is, I tracked it down to MMF.ccp, around line 210 in the current CVS. It's in an "#IFDEF... #else //else, NOT WINDOWS" section. Which is why Windows seems fine, but Linux craps out.

Code:

                            if(share_id == -1) {

                                    cerr << "failed to get 0-length shared mem: " << strerror(errno) << endl;

                            }

                            if ((lpvMem = shmat(share_id, NULL,SHM_RDONLY)) == (void *)-1) {

                                    cerr << "shmat failed! " << strerror(errno) << endl;

                            }

Now, I know little next to nothing about C++, let alone shared memory. If there is a dev around that sees this, can you please advise what can be done to (maybe) expand the limits of shared memory on Linux servers? This is on a Fedora Core 4 box, if it matters.

I'd love to release a patch to the Items table for others, but right now I am uncertain the current code can handle it (not that many of the items are usable anyway ;))

For anyone ambitious enough to try a newer items table, grab it here. This was updated using teh 13thFloor Items file dated 7/6/2007 (or thereabouts).

Be sure to backup your data, eh? This likely will not work as much as you'd hope.

Thank you!

I'll play with this on my dev server (it's running Ubuntu at the moment) and if I can duplicate this problem and solve it, I'll tell you what I did to do so :)

For one thing, what's with all the extra fields?

Not that they will get in the way, per se, but they are certainly not needed and make db merging a whole lot more difficult.

It is how you fix the 13th floor import .pl. Columns have to match 13th Floor data file. As for merging, that's an individuals problem. :) All I did was find a way to get the latest 13th Floor into a raw, non-customized Items table. The extra columns are new attribs for (maybe) the newer items from that data source.

Then, ran into problems with nearing the max item ID ceiling, and this thing on Linux which I have had no time to look into. If you can fix it, great!

Still working on this. It's not a max items thing... something else is strange.

Remember, it appears fine on Windows and is only in the "not win32" code. Not sure if that helps narrow the search...

Quote:

Originally Posted by John Adams (Post 137844)

Remember, it appears fine on Windows and is only in the "not win32" code. Not sure if that helps narrow the search...

Dunno if this helps but I got this fro ma old thread...

Too many items, edit
common/Items.h
and change the value of
#define MMF_EQMAX_ITEMS 85000
to find the number of items in your database, run the following query :
select max(id) from items;

Thanks sdabbs. The item id's are still a few thousand below the current max (100,000), so I don't think that's the issue on Linux. Especially because Windows emu doesn't seem to have the problem. I guess I need to learn what a shmat is. :)

Quote:

Originally Posted by John Adams (Post 138072)

I guess I need to learn what a shmat is. :)

Isn't it that monkey from buck rodgers?
http://man.he.net/man2/shmat

Crap, now I know _everything_! What will I do now?

Thanks man, that sheds a little more light on the problem.

JA are you still having this problem? I think I hit a problem simular to this about a week ago and fixed it....

Only when I source in the new 13th Floor items list on Linux, yes.

The PEQ Items table is fine.

I'll take a fix if ya got one. :)

Has anyone found a fix for this? I'm starting to look at this myself and am somewhat baffled by why the shmget function call is failing at line 205 of MMF.cpp.

The solution to this problem isnt in the server code. Its fixable by your distros configuration. You need to increase the value in your /proc/sys/kernel/shmmax file to some value greater than 32 MB. The value in that files in is bytes and its probably going to vary from distro to distro. I'm not sure what a good value is, but i can confirm setting it to 100 MB does allow us to import the current 13th floor items table.

Enjoy!

I also want to thank both Cavedude and FatherNitWit for assisting me in identifying this issue and testing the solution. I believe you can expect PEQ to have a current items table in the next few days now.

Here we are, a brand new items table consisting of the newest 13th floor dump as of this morning (62,000+ items) Stackable items work, and I made the appropriate changes to the columns so all the data got converted and merged in. I've been testing it all morning and had no issues (other than pre-existing ones in the Emu code of course) so it looks like we are good.

http://projecteq.net/items_102107.rar

As Wild said, Linux users will probably need to bump your /proc/sys/kernel/shmmax file a bit. Windows users need not do anything.