Valgrind Log

Page: « < 1 of 1 > »

07 Feb 2010 - 00:04	2311
rudeboyrave New Member Joined: 12 Nov 2007 Posts: 57	Valgrind Log anyone know anything about valgrind? A fellow imm ran it for 12 hrs and came up with this llog http://paste-it.net/public/b47c48a/ how bad is it? lol

07 Feb 2010 - 03:35	2313
Axanon New Member Joined: 12 Jan 2010 Posts: 27	Looks like a bunch of fail.. thats not tbamud is it? Perhaps their "Memcheck, a memory error detector" program is fail as well.

07 Feb 2010 - 13:19	2314
rudeboyrave New Member Joined: 12 Nov 2007 Posts: 57	/kill axanon Last edited by rudeboyrave (07 Feb 2010 - 13:36)

07 Feb 2010 - 17:10

2315

welcor
Regular Poster

Joined: 04 Jul 2007
Posts: 127

Thank you for the feedback. Some of the errors are in stock tba code, and some are in your own mudcode.

To sum up the findings of the log - we can't find the bugs based on the given data. A lot of the files have been changed in your current version, and the errors are hard to find without dorect access to the code.

Now, for a detailed look:

Feb  5 05:59:41 :: Sorting psionics and skills.
==27569== Invalid write of size 4
==27569==    at 0x4E66E8: sort_psionics (spec_procs.c:295)
==27569==    by 0x45C00F: boot_db (db.c:809)
==27569==    by 0x453C9A: init_game (comm.c:557)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Address 0x6c30b60 is 0 bytes after a block of size 368 alloc'd
==27569==    at 0x4C236F5: calloc (vg_replace_malloc.c:418)
==27569==    by 0x4E66D2: sort_psionics (spec_procs.c:290)
==27569==    by 0x45C00F: boot_db (db.c:809)
==27569==    by 0x453C9A: init_game (comm.c:557)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==
==27569== Invalid write of size 4
==27569==    at 0x4E6748: sort_skills (spec_procs.c:310)
==27569==    by 0x45C014: boot_db (db.c:810)
==27569==    by 0x453C9A: init_game (comm.c:557)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Address 0x6c30c28 is 0 bytes after a block of size 136 alloc'd
==27569==    at 0x4C236F5: calloc (vg_replace_malloc.c:418)
==27569==    by 0x4E6732: sort_skills (spec_procs.c:305)
==27569==    by 0x45C014: boot_db (db.c:810)
==27569==    by 0x453C9A: init_game (comm.c:557)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==

The line numbers don't match up, but apparently this is caused by array overruns in the sort_skills (and apparently sort_psionics) functions. This one might actually be a stock issue as well.

==27569== Use of uninitialised value of size 8
==27569==    at 0x470DAA: eval_op (dg_scripts.c:1390)
==27569==    by 0x4715B3: eval_lhs_op_rhs (dg_scripts.c:1573)
==27569==    by 0x47135D: eval_expr (dg_scripts.c:1503)
==27569==    by 0x471617: process_if (dg_scripts.c:1587)
==27569==    by 0x4739B6: script_driver (dg_scripts.c:2576)
==27569==    by 0x476DC9: wear_otrigger (dg_triggers.c:806)
==27569==    by 0x461772: reset_zone (db.c:2930)
==27569==    by 0x45C107: boot_db (db.c:864)
==27569==    by 0x453C9A: init_game (comm.c:557)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Uninitialised value was created by a stack allocation
==27569==    at 0x4713DD: eval_lhs_op_rhs (dg_scripts.c:1517)
==27569==

This one simply makes no sense with the given linenumbers. Please post dg_scripts.c, lines 1385-1395 for us to help on that one. This will still not be enough, but it will at least help pinpoint the buggy line.

==27569== Conditional jump or move depends on uninitialised value(s)
==27569==    at 0x45CF54: asciiflag_conv (db.c:1290)
==27569==    by 0x4B6496: objsave_parse_objects (objsave.c:1528)
==27569==    by 0x4B675A: Crash_load_objs (objsave.c:1667)
==27569==    by 0x499D88: enter_player_game (interpreter.c:1445)
==27569==    by 0x49B247: nanny (interpreter.c:2108)
==27569==    by 0x45467E: game_loop (comm.c:959)
==27569==    by 0x453CE5: init_game (comm.c:574)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Uninitialised value was created by a stack allocation
==27569==    at 0x4B5D5E: objsave_parse_objects (objsave.c:1325)
==27569==
==27569== Use of uninitialised value of size 8
==27569==    at 0x45CF94: asciiflag_conv (db.c:1292)
==27569==    by 0x4B6496: objsave_parse_objects (objsave.c:1528)
==27569==    by 0x4B675A: Crash_load_objs (objsave.c:1667)
==27569==    by 0x499D88: enter_player_game (interpreter.c:1445)
==27569==    by 0x49B247: nanny (interpreter.c:2108)
==27569==    by 0x45467E: game_loop (comm.c:959)
==27569==    by 0x453CE5: init_game (comm.c:574)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Uninitialised value was created by a stack allocation
==27569==    at 0x4B5D5E: objsave_parse_objects (objsave.c:1325)
==27569==

Again, the line number don't match up. db.c:1292 is nowhere near asciiflag_conv.

==27569== Use of uninitialised value of size 8
==27569==    at 0x50A2DAB: _itoa_word (in /lib/libc-2.7.so)
==27569==    by 0x50A56FE: vfprintf (in /lib/libc-2.7.so)
==27569==    by 0x50ACE37: fprintf (in /lib/libc-2.7.so)
==27569==    by 0x4B3142: objsave_save_obj_record (objsave.c:88)
==27569==    by 0x4B4014: Crash_save (objsave.c:701)
==27569==    by 0x4B3FEC: Crash_save (objsave.c:698)
==27569==    by 0x4B4337: Crash_crashsave (objsave.c:837)
==27569==    by 0x4B5CFB: Crash_save_all (objsave.c:1289)
==27569==    by 0x4549AD: heartbeat (comm.c:1117)
==27569==    by 0x45444A: game_loop (comm.c:1016)
==27569==    by 0x453CE5: init_game (comm.c:574)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Uninitialised value was created by a stack allocation
==27569==    at 0x4B5D5E: objsave_parse_objects (objsave.c:1325)
==27569==
==27569== Conditional jump or move depends on uninitialised value(s)
==27569==    at 0x50A2DB5: _itoa_word (in /lib/libc-2.7.so)
==27569==    by 0x50A56FE: vfprintf (in /lib/libc-2.7.so)
==27569==    by 0x50ACE37: fprintf (in /lib/libc-2.7.so)
==27569==    by 0x4B3142: objsave_save_obj_record (objsave.c:88)
==27569==    by 0x4B4014: Crash_save (objsave.c:701)
==27569==    by 0x4B3FEC: Crash_save (objsave.c:698)
==27569==    by 0x4B4337: Crash_crashsave (objsave.c:837)
==27569==    by 0x4B5CFB: Crash_save_all (objsave.c:1289)
==27569==    by 0x4549AD: heartbeat (comm.c:1117)
==27569==    by 0x45444A: game_loop (comm.c:1016)
==27569==    by 0x453CE5: init_game (comm.c:574)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Uninitialised value was created by a stack allocation
==27569==    at 0x4B5D5E: objsave_parse_objects (objsave.c:1325)

Once again, hard to pinpoint, as the line numbers don't match up.

==27569== Conditional jump or move depends on uninitialised value(s)
==27569==    at 0x465ADE: sub_write (dg_comm.c:142)
==27569==    by 0x47E03B: do_wsend (dg_wldcmd.c:123)
==27569==    by 0x47F001: wld_command_interpreter (dg_wldcmd.c:649)
==27569==    by 0x473753: script_driver (dg_scripts.c:2711)
==27569==    by 0x477893: enter_wtrigger (dg_triggers.c:1094)
==27569==    by 0x4216F5: do_simple_move (act.movement.c:334)
==27569==    by 0x4A7A5D: mobile_activity (mobact.c:94)
==27569==    by 0x454A69: heartbeat (comm.c:1063)
==27569==    by 0x45444A: game_loop (comm.c:1016)
==27569==    by 0x453CE5: init_game (comm.c:574)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Uninitialised value was created by a stack allocation
==27569==    at 0x4731C0: script_driver (dg_scripts.c:2499)
==27569==

sub_write (dg_comm.c:142) looks like this:

      case '*':

Not really depending on any unknowns... Perhaps they refer to the variable (*p), but that is set in the loop initialisor to "arg", which was passed into the function. But most definately wasn't allocated at dg_scripts.c:2499 as that is just a log statement.

==27569== Invalid read of size 4
==27569==    at 0x419A26: perform_get_from_room (act.item.c:326)
==27569==    by 0x419B15: get_from_room (act.item.c:369)
==27569==    by 0x41A046: do_get (act.item.c:405)
==27569==    by 0x498308: command_interpreter (interpreter.c:725)
==27569==    by 0x473778: script_driver (dg_scripts.c:2703)
==27569==    by 0x474885: random_mtrigger (dg_triggers.c:115)
==27569==    by 0x46EBC9: script_trigger_check (dg_scripts.c:628)
==27569==    by 0x454A87: heartbeat (comm.c:1053)
==27569==    by 0x45444A: game_loop (comm.c:1016)
==27569==    by 0x453CE5: init_game (comm.c:574)
==27569==    by 0x4536E2: main (comm.c:395)
==27569==  Address 0x815dea0 is 64 bytes inside a block of size 360 free'd
==27569==    at 0x4C22DB7: free (vg_replace_malloc.c:325)
==27569==    by 0x419224: get_check_money (act.item.c:215)
==27569==    by 0x419A25: perform_get_from_room (act.item.c:323)
==27569==    by 0x419B15: get_from_room (act.item.c:369)
==27569==    by 0x41A046: do_get (act.item.c:405)
==27569==    by 0x498308: command_interpreter (interpreter.c:725)
==27569==    by 0x473778: script_driver (dg_scripts.c:2703)
==27569==    by 0x474885: random_mtrigger (dg_triggers.c:115)
==27569==    by 0x46EBC9: script_trigger_check (dg_scripts.c:628)
==27569==    by 0x454A87: heartbeat (comm.c:1053)
==27569==    by 0x45444A: game_loop (comm.c:1016)
==27569==    by 0x453CE5: init_game (comm.c:574)
==27569==

Once again this might show a stock bug. What we see is that either one trigger tries to get the same object twice (which obviously should fail, but not in this way), or two triggers independently trying to get the same object (which again, should fail but not like this). Unfortunately, again, the line numbers don't match (stock get_check_money is around lines 180-195), so it's no simple fix.

So much for the "runtime" issues. Next up are memory leaks. See next post for a dissection.

__________________
You know who I am.

07 Feb 2010 - 17:49	2316
welcor Regular Poster Joined: 04 Jul 2007 Posts: 127	About the memory leak overview, it is more or less unusable. For valgrind to register a free(), the program needs to shut down using the proper "shutdown die" procedure, and not use the ctrl-c method applied here. Also, the code that usually handles cleanup is not run when sending a SIGINT, causing immense amounts of memory objects to be "still reachable". I'll start out with the leak summary: ==27569== LEAK SUMMARY: ==27569== definitely lost: 640 bytes in 20 blocks ==27569== indirectly lost: 2,516 bytes in 20 blocks ==27569== possibly lost: 5,776 bytes in 123 blocks ==27569== still reachable: 34,912,631 bytes in 139,248 blocks ==27569== suppressed: 0 bytes in 0 blocks As you see, it show some 34M as still reachable - a definate sign of something wrong. I suggest reading more on http://valgrind.org/gallery/linux_mag.html __________________ You know who I am.

Page: « < 1 of 1 > »

tbaMUD Continued development of the CircleMUD core

User login

Navigation

Who's online

Valgrind Log

Recent blog posts

Recent Forum Posts

Syndicate