01 Aug, 2009, triskaledia wrote in the 1st comment:
Votes: 0
Recently decided it'd be wise to check out some of the mud logs and found:
BUG: Attempt to recyle invalid memory of size 30.
It occurs several times due to the array I have defined to setup gems; which was discussed in earlier posts.
The db.c file shows:
if (*magic != MAGIC_NUM)
{
bug ("Attempt to recyle invalid memory of size %d.", sMem);
bug ((char *) pMem + sizeof (*magic), 0);
return;
}
:to display the error log. MAGIC_NUM is defined as a bit size; 50k something.
Any idea's as to what causes this error? I had it before when I wrote an embalming skill, but I cannot remember for the life of me what I changed in it to remove it.
Also, with this "bug" occuring, is it one of the thousands of nonsense bugs that were written into the original rom code?
As with all my issues, still using a ROM 2.4 QuickMUD style.
–Silence Tyire, of Reanimation
01 Aug, 2009, quixadhal wrote in the 2nd comment:
Votes: 0
I'm sure one of the ROM experts will clarify exactly, but my initial guess is that you have something that's stomping on allocated structures and corrupting the "magic" field in them.

When you allocate memory, your process is given a segment that only it is allowed to access. Attempts to read or write memory that's allocated to another process cause a segmentation fault. However, it's very common that multiple allocations end up adjacent to each other. If you allocate 3 objects, and write too much data into the first one, it will happily overwrite part of the second object without any kind of error – since it's still YOUR memory.

This usually causes a crash later on, when you try to access it and end up with bad pointers, but depending on how it got corrupted, it might simply change data without affecting any pointers at all. This leads to all kinds of issues, since your game may run just fine for hours, days, weeks before you notice data corruption, and by then you may have to resort to restoring very old weekly backups and having your players be annoyed at losing so much progress.

I'm gussing the "magic" value is a number that's defined as MAGIC_NUM, which the ROM recycling system checks when attempting to reuse an object. If the field doesn't match, it means that memory has been corrupted since it was put on the list of recycled objects, which in turn means you have another problem that this one is a symptom of.
01 Aug, 2009, triskaledia wrote in the 3rd comment:
Votes: 0
I'm thinking that my love for using the "number_range code" is my issue; after reading that.
Perhaps defining one object to have multiple names/short/long/weight/cost is causing the error out because it is actually looking for the item to have no name/short/long/weight/cost/etc?
Or perhaps my idea of using one object to define multiple gems, as defined in my array, is becoming the issue?
As for the players, I have a small pbase right now, so a backup will not hurt many.
Those that are there understand that I may run into issues in the code which may cause a revert.
Those who return from there "forever pause", will just have to assume the worst for their absence.
Anyway, more thoughts/actuality are appreciated.
Sorry for the slight ramble, very tired, agitated, and had a few beers.
–Silence Tyire
01 Aug, 2009, Kline wrote in the 4th comment:
Votes: 0
In any memory situation, Valgrind is your friend. Although to make it truly your friend, you will first need to write a cleanup_memory() type routine that runs on shutdown; this way the game properly frees all memory in use, and Valgrind can pinpoint the locations that weren't freed.

You can still make good use of it without that work, to catch invalid read/write attempts like quixadhal was referencing, but it will be most beneficial if you do cleanup your memory.
01 Aug, 2009, Runter wrote in the 5th comment:
Votes: 0
Kline said:
In any memory situation, Valgrind is your friend. Although to make it truly your friend, you will first need to write a cleanup_memory() type routine that runs on shutdown; this way the game properly frees all memory in use, and Valgrind can pinpoint the locations that weren't freed.

You can still make good use of it without that work, to catch invalid read/write attempts like quixadhal was referencing, but it will be most beneficial if you do cleanup your memory.


You shouldn't need the cleanup_memory() function. It should be able to track any memory leaks in any event through pointers that exist.
01 Aug, 2009, Guest wrote in the 6th comment:
Votes: 0
The cleanup_memory function is only necessary to remove known issues from the report during game shutdown. Valgrind will not report these leaks until you do so, and most Merc based codebases don't deallocate their memory prior to shutting down so Valgrind will assume they're all either leaks or blocks still in use.

The only thing it's going to monitor while the game is running are things like using uninitialized values, and memory overruns, things of that nature.
01 Aug, 2009, Runter wrote in the 7th comment:
Votes: 0
Samson said:
The cleanup_memory function is only necessary to remove known issues from the report during game shutdown. Valgrind will not report these leaks until you do so, and most Merc based codebases don't deallocate their memory prior to shutting down so Valgrind will assume they're all either leaks or blocks still in use.

The only thing it's going to monitor while the game is running are things like using uninitialized values, and memory overruns, things of that nature.


I think there's a few tool-faces you can use that change exactly what it will do—Some of which seemed to be better for certain profiling.
02 Aug, 2009, triskaledia wrote in the 8th comment:
Votes: 0
Should possibly do some of my own research, but at this time I'm intoxicated…
What is Valgrind? Is it a debugger similar to, well shit I can't even think of it… G-something?
Anyway. What's a good link to find something out about Valgrind?
–Silence Tyire, the "Thou Art Drunken"
It's truly sad when you've had 4 beers and a shot of 80proof drink and gone.
02 Aug, 2009, Kline wrote in the 9th comment:
Votes: 0
Valgrind has a few tools in it, but the primary use for most people is as a leak/memory checker. Valgrind.org is a good starting spot for info, FAQs, and a download link.
02 Aug, 2009, Tyche wrote in the 10th comment:
Votes: 0
triskaledia said:
Recently decided it'd be wise to check out some of the mud logs and found:
BUG: Attempt to recyle invalid memory of size 30.


You are calling either free_mem() or free_string() on memory you did not allocate via alloc_mem() or str_dup().
Check to see if you manually allocate the string with strdup() or malloc().
Valgrind is fairly useless with the way ROM manages its memory.
02 Aug, 2009, Bojack wrote in the 11th comment:
Votes: 0
Usually that error pops up when something doesnt meet the set magic_num, in other words if you added a skill and used str_dup and you wanted to zero it out somewhere, probably didnt use str_dup ("") or = NULL;
02 Aug, 2009, triskaledia wrote in the 12th comment:
Votes: 0
Alright got the bug resolved by freeing the string then dumping what I wanted in. Thanks for everyone's help.
–Silence Tyire
0.0/12