EQEmulator Forums - If you're running linux and would like to help!

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

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

- - If you're running linux and would like to help! (https://www.eqemulator.org/forums/showthread.php?t=10332)

Please read over what I typed before

Quote:

I think that LE has started updating CVS at the same time he makes changes to the dev only CVS, and that might be causing conflicts in my jobs..

I'll take a look tonight, I might have to rewrite the CVS jobs... They were originally written with the idea that I'd be the only one putting updates in CVS , so the method I used was very simple and primitive, and probably prone to problems when other people put changes directly into CVS.

So in a nutshell, no.. CVS ISNT UPDATED YET..

I just compiled the new (file dates of nov 19) with the -g option and ran one of my zone processes with LeakCheck and the first thing it did was create a 54MB leak.out file in the first 20 seconds
then settled down.

http://www.1amos.com/leak3.txt

No leaks there, just some dealloc hits..

To get really good data, the zone needs to run for quite a while and have various people doing random things in there. This ensures we are getting good code coverage execution....

Heres a short lesson in enterprise coding... skip this if you're not interested..
-----------------------------------------------------------------------------------
For those that are new to code coverage, here's a lesson on it and what it means and why its important...

In enterprise development (real world coding), you have what are called test cases or use cases that are intended to ensure that your code is executing as is designed. Say a course of behavior for a client using an application.

1) Client logs in.
2) Client checks his inventory and rearranges several items
3) Client goes to a merchant and buys something
4) Client logs out..

This series of steps indicates a specific 'test case' . Only certain parts of the code were executed, hence you can only verify that certain pieces are working. Combat could be completely shot, but you will never know until it is tested. This requires you to have a combat test case. And combat itself could be broken down into melee and nonmelee (spell casting) tests cases, which could be further broken down. to ensure good code coverage and testing means you need extensive test cases to adequetely test all the different pieces of the code...

This is where semi randomized testing comes in. Randomized testing doesnt cover true test causes, but it does give you a good idea of where the bugs are because of the rather random behavior of the users, and is often the best way to catch 'off the path errors'

Using this approach, allow the server to run for a long time and having multiple people randomly exercise pieces of the code that you dont normally test yourself gives you a good idea of whats working and whats not. In the case here, this semi random use will help us to determine problems in pieces of the code that we dont normally test ourselves.

Thats why bug reports are so important to eqemu. Without standardized regression tests and base test cases, it falls upon the users to find problems that we ourselves dont catch.

One of the problems with standard test cases is they are usually 'golden path' test cases, which means someone testing when someone did something right, but what if someone does something wrong, did you test for that? Someone accidently does something they didnt mean too, like target themselves instead of a mob for a spell.. Results could be unpredictable if someone hasnt taken that into account in the code! Thats one of the reason that defualts in switch statements are so important, you always need catch all rules when things dont behave as you expect they should......

Theres one too fix..

Code:

if (RunQuery(query, MakeAnyLenString(&amp;query, "SELECT loottable_id, lootdrop_id, multiplier, probability FROM loottable_entries WHERE loottable_id=%i", tmpid), errbuf, &amp;result2)) {

                                safe_delete_array(query);

                                tmpLT = (LootTable_Struct*) new uchar[sizeof(LootTable_Struct) + (sizeof(LootTableEntries_Struct) * mysql_num_rows(result2))];

                                memset(tmpLT, 0, sizeof(LootTable_Struct) + (sizeof(LootTableEntries_Struct) * mysql_num_rows(result2)));

                                tmpLT->NumEntries = mysql_num_rows(result2);

                                tmpLT->mincash = tmpmincash;

                                tmpLT->maxcash = tmpmaxcash;

                                tmpLT->avgcoin = tmpavgcoin;

                                i=0;

                                while ((row = mysql_fetch_row(result2))) {

                                        if (i >= tmpLT->NumEntries) {

                                                mysql_free_result(result);

                                                mysql_free_result(result2);

                                                cerr &lt;&lt; "Error in Database::DBLoadLoot, i >= NumEntries" &lt;&lt; endl;

                                                return false;

                                        }

                                        tmpLT->Entries[i].lootdrop_id = atoi(row[1]);

                                        tmpLT->Entries[i].multiplier = atoi(row[2]);

                                        tmpLT->Entries[i].probability = atoi(row[3]);

                                        i++;

                                }

                                if (!EMuShareMemDLL.Loot.cbAddLootTable(tmpid, tmpLT)) {

                                        mysql_free_result(result);

                                        mysql_free_result(result2);

                                        safe_delete(tmpLT);

                                        cout &lt;&lt; "Error in Database::DBLoadLoot: !cbAddLootTable(" &lt;&lt; tmpid &lt;&lt; ")" &lt;&lt; endl;

                                        return false;

                                }

                                safe_delete(tmpLT);

                                mysql_free_result(result2);

The problem is here..

tmpLT = (LootTable_Struct*) new uchar[sizeof(LootTable_Struct) + (sizeof(LootTableEntries_Struct) * mysql_num_rows(result2))];

and its dealloc'd with

safe_delete(tmpLT);

That delete should be a safe_delete_array since it's new'd as uchar[x]

The one in seperator confuses me.. This is the deconstructor

91 ~Seperator() {
92 for (int i=0; i<=maxargnum; i++)
93 safe_delete(arg[i]);
94 safe_delete_array(arg);
95 safe_delete_array(argplus);
96 }

If you have an array of new'd objects, do you need to delete each member of the array, do you need to dealloc each member of the array, and then the array itself ?

I've had at least one player who spends alot of time on my server report this each time he tried to zone:

[thu Nov 20 07:33:02 2003] Error: Asyncronous save of your character failed.

He would get disconnected and this was in the log file.

He was unable to get out of the zone he was in (arena) After trying to zone and getting disconnected he would log back in and not have zoned. SO he was stuck in the zone he happened to be in bfore I upgraded the server.

*** Edit***

Where there maybe changes to the DB structure? I have to admit I didn't check.

Yes, db changes... Look in your zone stndard out and you should see the failure, and look at your zone.log

Speaking of testing code, I read a while back about the program gcov put out by the gnu team.

Do you think this might help you?

Here is the url
http://gcc.gnu.org/onlinedocs/gcc-3.0/gcc_8.html

Quote:

8.1 Introduction to gcov
gcov is a test coverage program. Use it in concert with GNU CC to analyze your programs to help create more efficient, faster running code. You can use gcov as a profiling tool to help discover where your optimization efforts will best affect your code. You can also use gcov along with the other profiling tool, gprof, to assess which parts of your code use the greatest amount of computing time.

Profiling tools help you analyze your code's performance. Using a profiler such as gcov or gprof, you can find out some basic performance statistics, such as:

how often each line of code executes

what lines of code are actually executed

how much computing time each section of code uses
Once you know these things about how your code works when compiled, you can look at each module to see which modules should be optimized. gcov helps you determine where to work on optimization.

Software developers also use coverage testing in concert with testsuites, to make sure software is actually good enough for a release. Testsuites can verify that a program works as expected; a coverage program tests to see how much of the program is exercised by the testsuite. Developers can then determine what kinds of test cases need to be added to the testsuites to create both better testing and a better final product.

You should compile your code without optimization if you plan to use gcov because the optimization, by combining some lines of code into one function, may not give you as much information as you need to look for `hot spots' where the code is using a great deal of computer time. Likewise, because gcov accumulates statistics by line (at the lowest resolution), it works best with a programming style that places only one statement on each line. If you use complicated macros that expand to loops or to other control structures, the statistics are less helpful--they only report on the line where the macro call appears. If your complex macros behave like functions, you can replace them with inline functions to solve this problem.

gcov creates a logfile called `sourcefile.gcov' which indicates how many times each line of a source file `sourcefile.c' has executed. You can use these logfiles along with gprof to aid in fine-tuning the performance of your programs. gprof gives timing information you can use along with the information you get from gcov.

gcov works only on code compiled with GNU CC. It is not compatible with any other profiling or test coverage mechanism.

Ok I had a lok through db.sql and could not find the change in that character_ table then I checked the db.sql mod date and it's still from the 11th. What are the properties of the added column?

I've used gcov several times.. It will slow the heck out the program (have to compile with instrumentation options for your code) , but tells you that you've hit the code you're wanting to test..

Ive thought about it, but unless eqemu has a standardized release test team, and test cases, I really dont think it would help us a whole lot.

Ark, dont know, changes werent mine, but I'm guessing your issue is related to aa changes. Without the error message though thats only a guess... I think there was a 'time last on' field added in the code, but you might want to ask LE.

Yeah it's the timelaston column I'm missing. Should be an int I think.