[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  SMAUG
. -> [Folder]  SMAUG coding
. . -> [Subject]  Valgrind results
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Valgrind results
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Wed 16 Feb 2005 01:36 AM (UTC)  [ quote  ]
Message
If the rest of the code in the snippet calls for using str_dup and DISPOSE on those values, then yes, you should be using fread_string_nohash to read them from files.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Wed 16 Feb 2005 01:04 AM (UTC)  [ quote  ]

Amended on Wed 16 Feb 2005 02:18 AM (UTC) by Zeno

Message
Yes that was an odd result. Didn't think the changes would do something, since it was a snippet and then upgraded from a friend.


        changes_table[i].change = fread_string( fp );
        changes_table[i].coder = fread_string( fp );
        changes_table[i].date = fread_string( fp );
        changes_table[i].mudtime = fread_number( fp );


So I suppose those should be nohash?
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Wed 16 Feb 2005 12:48 AM (UTC)  [ quote  ]

Amended on Wed 16 Feb 2005 12:49 AM (UTC) by Samson

Message
Based on the beginning of the log where you get the crashes with changes.c, I'd give very strong odds to mismatching STRALLOC or fread_string with a DISPOSE or some other line str_dup'ing one of those values.

If a value is supposed to be str_dup'd, you MUST ALWAYS remember to use fread_string_nohash on it. STRALLOC uses fread_string. I realize this may be repeating things you've heard before, but even the best of us still make this mistake time and time again with Smaug. It's far too easy to forget.

The Smaug hashing system is a nice idea but might well have been poorly executed which leads to seeing folks mix methods up all the time.

Also, once you've got a situation where you're mixing things improperly, all bets are off when Valgrind finally reports a problem - it may not be the correct information.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Wed 16 Feb 2005 12:38 AM (UTC)  [ quote  ]
Message
I ran valgrind again for 2 hours. Log of only valgrind results are here:
http://iyg.arthmoor.com/puttyc.log

Seems like polymorph is the mem leak cause?
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Fri 11 Feb 2005 01:18 AM (UTC)  [ quote  ]
Message
Perhaps you need to expand your scrollback then.

55008 bytes in 382 blocks are still reachable in loss record 62 of 71

There are still 61 other messages you didn't see yet :)

Quote:

==22332== LEAK SUMMARY:
==22332== definitely lost: 2453 bytes in 303 blocks.


Somewhere in those 61 messages it should have told you which ones caused this.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Thu 10 Feb 2005 03:33 PM (UTC)  [ quote  ]
Message
Quote:
You had one blurb of actual leaks, which you have yet to paste in.


I've already posted everything that valgrind sent back, except for the lines before the MUD was started, which I missed because it scrolled off beyond the scroll bar. I should have had it logged to a local file.

I'll check out cleanup_memory though, thanks.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Thu 10 Feb 2005 11:39 AM (UTC)  [ quote  ]
Message
Running a memory cleanup also has one other advantage even if you don't use Valgrind. If there is a problem with how you're freeing memory, or if it contains invalid data for some reason, chances are it will drop core during the cleanup and you can quickly isolate the problem and fix it.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Thu 10 Feb 2005 05:20 AM (UTC)  [ quote  ]
Message
I also went through this same process on Samson's advice, and it really helped.

For example, while printing out the contents of the hash table, it showed me that I was writing ch->pcdata->email twice, and allowed me to clear the problem right up. Even if your not using valgrind, this is a great idea.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Thu 10 Feb 2005 03:28 AM (UTC)  [ quote  ]
Message
I normally don't consider how long it's run for. A leak is a leak, regardless of if it's found in 5 seconds or 10 days. All but one block you've posted can be ignored. You had one blurb of actual leaks, which you have yet to paste in. The "still reachable" blocks mean nothing.

I found out quickly that the best way to get meaningful shutdown results is to have memory cleaned up in a controlled way based on what you know should be allocated. Fortunately someone else had been thinking along those same lines and wrote a cleanup_memory function to handle it. I used it in AFKMud and expanded it to cover everything we have. This way when the mud is brought down in a controlled manner only the actual leaked information will show up, thus making it easier to fix.

If you'd like to use the function in your base, feel free, but you'll probably need to do some fat trimming since several of the parts won't be relevant to you.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Wed 09 Feb 2005 03:20 AM (UTC)  [ quote  ]

Amended on Wed 09 Feb 2005 03:23 AM (UTC) by Zeno

Message
Well there was a lot of lines displayed before the MUD booted and before it shutdown. It's too large to post here, but here's some from when it shutdown.


==22332==
==22332== 55008 bytes in 382 blocks are still reachable in loss record 62 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x80C67E7: load_objects (db.c:1425)
==22332==    by 0x80CF723: load_area_file (db.c:5735)
==22332==    by 0x80C52B9: boot_db (db.c:720)
==22332==    by 0x80BB9A9: main (comm.c:286)
==22332==
==22332==
==22332== 61664 bytes in 376 blocks are still reachable in loss record 63 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x812500D: fread_obj (save.c:1973)
==22332==    by 0x80BF51D: nanny (comm.c:2564)
==22332==    by 0x80BC218: game_loop (comm.c:684)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332==
==22332== 72000 bytes in 12 blocks are still reachable in loss record 64 of 71
==22332==    at 0x1B9034FA: realloc (vg_replace_malloc.c:197)
==22332==    by 0x80BD520: write_to_buffer (comm.c:1472)
==22332==    by 0x80BB4AD: send_to_char_color (color.c:1252)
==22332==    by 0x80BB526: send_to_pager_color (color.c:1277)
==22332==    by 0x80BB606: send_to_pager (color.c:1313)
==22332==    by 0x80BB6CF: pager_printf_color (color.c:1366)
==22332==    by 0x81120C5: do_igscore (player.c:1933)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332==
==22332== 87248 bytes in 532 blocks are still reachable in loss record 65 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x80C8D83: create_object (db.c:2692)
==22332==    by 0x811D45F: reset_area (reset.c:1450)
==22332==    by 0x80AB6AA: do_loadarea (build.c:6783)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332==
==22332== 159068 bytes in 3059 blocks are still reachable in loss record 66 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x80CF214: make_exit (db.c:5584)
==22332==    by 0x80C798F: load_rooms (db.c:1973)
==22332==    by 0x80CF7A7: load_area_file (db.c:5738)
==22332==    by 0x80C52B9: boot_db (db.c:720)
==22332==    by 0x80BB9A9: main (comm.c:286)
==22332==
==22332==
==22332== 161820 bytes in 1305 blocks are still reachable in loss record 67 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x80C774F: load_rooms (db.c:1906)
==22332==    by 0x80CF7A7: load_area_file (db.c:5738)
==22332==    by 0x80C52B9: boot_db (db.c:720)
==22332==    by 0x80BB9A9: main (comm.c:286)
==22332==
==22332==
==22332== 165195 bytes in 8598 blocks are still reachable in loss record 68 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x80CA60D: str_dup (db.c:3260)
==22332==    by 0x80CA8FF: fread_string_nohash (db.c:3402)
==22332==    by 0x8147425: fread_command (tables.c:3004)
==22332==    by 0x81475A8: load_commands (tables.c:3075)
==22332==    by 0x80C3681: boot_db (db.c:380)
==22332==    by 0x80BB9A9: main (comm.c:286)
==22332==
==22332==
==22332== 230912 bytes in 328 blocks are still reachable in loss record 69 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x80C8914: create_mobile (db.c:2575)
==22332==    by 0x8104F2D: init_supermob (mud_prog.c:155)
==22332==    by 0x80C52CC: boot_db (db.c:736)
==22332==    by 0x80BB9A9: main (comm.c:286)
==22332==
==22332==
==22332== 613808 bytes in 227 blocks are still reachable in loss record 70 of 71
==22332==    at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==22332==    by 0x8160AF9: load_board (board.c:341)
==22332==    by 0x8160D4A: load_global_boards (board.c:414)
==22332==    by 0x80C5382: boot_db (db.c:768)
==22332==    by 0x80BB9A9: main (comm.c:286)
==22332==
==22332==


They seem all be reachable, so they shouldn't be important. More important, nothing related to this came up...
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=4568
I had to monitor valgrind, and if I let it run for too long logging to a file, the file would probably become too large. Plus I would have to watch and choose the gdb prompts.

For the leaks, you did consider how long valgrind ran for right?

For those dealing with valgrind, I found a good tutorial at:
http://www.cprogramming.com/debugging/valgrind.html
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Wed 09 Feb 2005 03:17 AM (UTC)  [ quote  ]
Message
The uninitialized value it's complaining about ( for whatever reason ) seem to be the xit->exit_info pointer. Perhaps when it was first created it was not given a default value and the particular exit has no flags set? You need to give it a default, probably 0, when the exit is created in the make_exit function.

As for the "still reachable" leaks, those are largely things you can ignore. They technically are not leaks since you intended for them to remain allocated. Valgrind is simply complaining since they were still allocated when the program exited. The ones you need to find are:

Quote:

definitely lost: 2453 bytes in 303 blocks.


Those are the actual leaks - which don't appear to be overly large in your case.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Wed 09 Feb 2005 02:40 AM (UTC)  [ quote  ]
Message
Bed time for me. It ran for at least 2 hours, here are the results.


==22332== 967626 bytes in 6189 blocks are still reachable in loss record 71 of 71
==22332==    at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==22332==    by 0x80E4148: str_alloc (hashstr.c:60)
==22332==    by 0x80CA6FE: fread_string (db.c:3297)
==22332==    by 0x80D0ECB: fread_sysdata (db.c:6317)
==22332==    by 0x80D156F: load_systemdata (db.c:6431)
==22332==    by 0x80C37BF: boot_db (db.c:419)
==22332==    by 0x80BB9A9: main (comm.c:286)
==22332==
==22332== LEAK SUMMARY:
==22332==    definitely lost: 2453 bytes in 303 blocks.
==22332==    possibly lost:   0 bytes in 0 blocks.
==22332==    still reachable: 2895494 bytes in 25542 blocks.
==22332==         suppressed: 0 bytes in 0 blocks.
--22332--     TT/TC: 0 tc sectors discarded.
--22332--            82221 tt_fast misses.
--22332-- translate: new     29996 (447520 -> 6416147; ratio 143:10)
--22332--            discard 140 (1687 -> 24144; ratio 143:10).
--22332-- chainings: 29831 chainings, 2 unchainings.
--22332--  dispatch: 156550000 jumps (bb entries); of them 55551965 (35%) unchained.
--22332--            241273/355309 major/minor sched events.
--22332-- reg-alloc: 2719 t-req-spill, 1141979+20965 orig+spill uis,
--22332--            145979 total-reg-rank
--22332--    sanity: 131257 cheap, 5251 expensive checks.
--22332--    ccalls: 127906 C calls, 62% saves+restores avoided (473788 bytes)
--22332--            169945 args, avg 0.91 setup instrs each (30044 bytes)
--22332--            0% clear the stack (383112 bytes)
--22332--            33711 retvals, 30% of reg-reg movs avoided (20028 bytes)
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Wed 09 Feb 2005 01:04 AM (UTC)  [ quote  ]

Amended on Wed 09 Feb 2005 02:31 AM (UTC) by Zeno

Message
I'm going to post the results of Valgrind being run with my MUD, just so I can get the most out of it. I don't understand some of it, either.

==22332== Use of uninitialised value of size 4
==22332==    at 0x8B2FF7: _itoa_word (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8B644A: _IO_vfprintf_internal (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8BC59E: fprintf (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x80AAFD4: fold_area (build.c:6534)
==22332==    by 0x80AB778: do_foldarea (build.c:6836)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- 
==22332== Conditional jump or move depends on uninitialised value(s)
==22332==    at 0x8B2FFF: _itoa_word (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8B644A: _IO_vfprintf_internal (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8BC59E: fprintf (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x80AAFD4: fold_area (build.c:6534)
==22332==    by 0x80AB778: do_foldarea (build.c:6836)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- 
==22332==
==22332== Conditional jump or move depends on uninitialised value(s)
==22332==    at 0x8B6B78: _IO_vfprintf_internal (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8BC59E: fprintf (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x80AAFD4: fold_area (build.c:6534)
==22332==    by 0x80AB778: do_foldarea (build.c:6836)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- 
==22332==
==22332== Conditional jump or move depends on uninitialised value(s)
==22332==    at 0x8B4309: _IO_vfprintf_internal (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8BC59E: fprintf (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x80AAFD4: fold_area (build.c:6534)
==22332==    by 0x80AB778: do_foldarea (build.c:6836)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----


Above is a Uninitialized variable?
Here's the lines. (6534 is bold)

             fprintf( fpout, "%d %d %d %d\n",   xit->exit_info & ~EX_BASHED,
                                                xit->key,
                                                xit->vnum,
                                                xit->keypad );



==22332==
==22332== Conditional jump or move depends on uninitialised value(s)
==22332==    at 0x8B6B78: _IO_vfprintf_internal (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8BC59E: fprintf (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x80AAFD4: fold_area (build.c:6534)
==22332==    by 0x80AB4EF: do_savearea (build.c:6715)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x8083239: do_force (act_wiz.c:4689)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==
==22332== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
starting debugger
==22332== starting debugger with cmd: /usr/bin/gdb -nw /proc/23410/fd/821 23410
GNU gdb Red Hat Linux (6.3.0.0-0.1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /proc/23410/fd/821, process 23410
0x008b6b78 in ?? ()
(gdb) bt
#0  0x008b6b78 in ?? ()
#1  0x00000000 in ?? ()
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /proc/23410/fd/821, process 23410
==22332==
==22332== Debugger has detached.  Valgrind regains control.  We continue.
==22332==
==22332== Conditional jump or move depends on uninitialised value(s)
==22332==    at 0x8B4309: _IO_vfprintf_internal (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x8BC59E: fprintf (in /lib/tls/libc-2.3.4.so)
==22332==    by 0x80AAFD4: fold_area (build.c:6534)
==22332==    by 0x80AB4EF: do_savearea (build.c:6715)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x8083239: do_force (act_wiz.c:4689)
==22332==    by 0x80E687B: interpret (interp.c:577)
==22332==    by 0x80BC229: game_loop (comm.c:687)
==22332==    by 0x80BBACB: main (comm.c:316)
==22332==


For the above, why did the gdb not have a stack or anything?

More shall be added. If anyone could explain these while I still valgrind, It'd help so much. The only valgrind tutorial I read over did not explain how to deal with results. (My old host wrote it up: http://www3.muddomain.com/articles/valgrind.php)

That's about it so far.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

1,681 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]