Issue with Waypoints.
 

So we were setting up mobs to patrol and every time we used #wp add or #wp circular, zone crashed. This is the error.

Has nothing to do with waypoints, you have a NULL column in your items table causing a crash in your shared_memory:

I figured it was an item issue based on that when I saw the crash logs, it's just weird that literally the ONLY time it crashes is when we do anything with waypoints.

I'll figure out where the issue is in the item table and go from there.

Thanks.

So I rebuilt my items table, and redid the entire data tables, did #wpadd circular 40 and boom. Server crashed, same log.

I know it says items, but what in items is crashing, there is no custom items in my db at the moment.

The line number it's stating as the problem - common/shareddb.cpp line 894 - loads an item's Fire Resist from the database, so it sounds like some item's FR field is null, or otherwise not a number.

https://github.com/EQEmu/Server/blob...reddb.cpp#L894

Looking at my copy of the database, it looks like it's an int column that doesn't allow nulls, and I can't find any records that don't have a valid value of -128 to +127 for the field. Very weird...

Yeah I have no idea...

The only thing I'm finding with FR is -100 up to 127. Everything else is inbetween with no null value, only 0.

When searching filter FR = Null it populates all the FR fields with 0. I mean, I know null means 0, or nothing. But in the scheme of things, I thought null was a blank field? O.o could that be the issue?

Try using this query.

A null is a blank field. However, the default spells_new table definition in the peq database specifies that that field does not allow nulls, so any saves to the record that don't specify a value for FR get the default value, which is set to 0.

The error really is a headscratcher. I'm assuming you've tried rebooting the server and re-running everything, including shared_memory.

Just ran Shared_memory (and I do mean just) completed, 0 errors. Restarted server, hell even rebuilt server from ground up. However, I did just happen to notice this in my logs that was not there yesterday, so maybe this is something...

I'm still getting the shared_memory error with the items (it's the first thing that populates on the error list).

I still get the shared_memory crash even with the items not being a problem (picture below)

http://i59.tinypic.com/102ku91.png

So clearly, it's not the items... Plus, why would items crash a WP command? O.o

Looks like it's trying to translate a NULL result to an int on the "freeGridID = atoi(row[0]) + 1;" line:

https://github.com/EQEmu/Server/blob...ints.cpp#L1208

This query would return a NULL only if there are no grid entries for the specified zone in the database at all.

It looks like the code should be updated to check for NULL in row[0], and return 0 if it finds it.

A workaround would be to manually add a dummy grid entry to the table for that zone. Something like:

Replace <<YourZoneID>> with the id of whatever the zone you're seeing the crash in.

That would at least return a 0 to the function in the meantime, instead of a NULL.

Oops, I goofed. Bonehead. It's the grid table that it's querying, not grid_entries. Had the wrong table left open after visualizing and investigating the problem.

Here's the correct query to execute for the workaround.

Replace the 123 with the actual zoneid of the zone that doesn't have any grid entry records yet:

Alternatively, this would add all missing zone entries in the `grid` table so the code doesn't crash looking up the max(id) for them: