Compiling Error Part 2

Posted by Cyb Ercho Lin on Sat 15 Oct 2016 07:47 PM — 5 posts, 25,559 views.

Cyb Ercho Lin Argentina Sat 15 Oct 2016 07:47 PM #0

Hello
as the previous post was closed by inactivity, continued from the last post where Nick asked me the log gdb for smaug:

Previous Post:

http://www.gammon.com.au/forum/?id=13386

Quote:

When I run the command ../src/smaug 4000
end yields this:

Sat Oct 15 12:26:23 2016 :: Loading watches
Sat Oct 15 12:26:23 2016 :: Loading bans
Sat Oct 15 12:26:23 2016 :: Done.
Sat Oct 15 12:26:23 2016 :: Loading reserved names
Sat Oct 15 12:26:23 2016 :: Loading corpses
Sat Oct 15 12:26:23 2016 :: Loading Immortal Hosts
Sat Oct 15 12:26:23 2016 :: Done.
Sat Oct 15 12:26:23 2016 :: Loading Projects
*** Error in `../src/smaug': double free or corruption (!prev): 0x098fe520 ***

running the same command but with gdb the result is:

Quote:

Reading symbols from ../src/smaug...done.
(gdb) l
398 } /* cleanup memory */
399
400 #ifdef WIN32
401 int mainthread( int argc, char **argv )
402 #else
403 int main( int argc, char **argv )
404 #endif
405 {
406 struct timeval now_time;
407 bool fCopyOver = FALSE;
(gdb)

then the following command is:

(gdb) run 4000
Starting program: /home/src/smaug 4000
Sat Oct 15 12:27:32 2016 :: Initializing Lua
Mud-wide Lua module started up.
Sat Oct 15 12:27:32 2016 :: Booting Database
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Sat Oct 15 12:27:32 2016 :: [*****] BOOT: ---------------------[ Boot Log ]--------------------
Sat Oct 15 12:27:32 2016 :: Loading corpses
Sat Oct 15 12:27:32 2016 :: Loading Immortal Hosts
Sat Oct 15 12:27:32 2016 :: Done.
Sat Oct 15 12:27:32 2016 :: Loading Projects
*** Error in `/home/src/smaug': double free or corruption (!prev): 0x08752520 ***

Program received signal SIGABRT, Aborted.
0xb7fdccf9 in ?? ()
(gdb)

Just put the beginning and end of the run command because there was no more mistakes, only coming out in the end.

with list, after running the program:

Quote:

(gdb) l
408 #ifdef IMC
409 int imcsocket = -1;
410 #endif
411
412 DONT_UPPER = FALSE;
413 num_descriptors = 0;
414 first_descriptor = NULL;
415 last_descriptor = NULL;
416 sysdata.NO_NAME_RESOLVING = TRUE;
417 sysdata.WAIT_FOR_AUTH = TRUE;
(gdb)

Backtrace:

Quote:

(gdb) backtrace
#0 0xb7fdccf9 in ?? ()
#1 0xb7d2b4ba in malloc_printerr (action=<optimized out>, str=0xb7e1ddb0 "double free or corruption (!prev)", ptr=0x8752520)
at malloc.c:4996
#2 0xb7d2c12d in _int_free (av=0xb7e63420 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3840
#3 0xb7d1b63a in _IO_new_fclose (fp=0x8752520) at iofclose.c:85
#4 0x0814f8e9 in load_projects () at db.c:9194
#5 0x08133a3a in boot_db (fCopyOver=false) at db.c:771
#6 0x081235d5 in main (argc=2, argv=0xbffff764) at comm.c:525

after this, and to my knowledge is overcome by the problem. I've taken a few months to put this but I had to keep trying.

Nick Gammon Australia Forum Administrator Sat 15 Oct 2016 09:42 PM #1

Well, it's not a compile error any more, it's a runtime error.

You could look at my post about debugging:

http://www.gammon.com.au/gdb

Nick Gammon Australia Forum Administrator Sat 15 Oct 2016 10:55 PM #2

If you are running on Linux (or otherwise have access to valgrind) then you can use valgrind to find what is happening. It reports problems with memory allocation / freeing.

Cyb Ercho Lin Argentina Sun 16 Oct 2016 09:12 PM #3

using valgrind:
valgrind --leak-check = full --tool = memcheck ../src/smaug 6660

Quote:

Sun Oct 16 13:09:00 2016 :: Loading Projects
==5077== Invalid read of size 1
==5077== at 0x420B506: fclose@@GLIBC_2.1 (iofclose.c:49)
==5077== by 0x814F8E8: load_projects() (db.c:9194)
==5077== by 0x8133A39: boot_db(bool) (db.c:771)
==5077== by 0x81235D4: main (comm.c:525)
==5077== Address 0x4b1aaee is 70 bytes inside a block of size 352 free'd
==5077== at 0x402B3D8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5077== by 0x420B639: fclose@@GLIBC_2.1 (iofclose.c:85)
==5077== by 0x814F939: read_project(_IO_FILE*) (db.c:9213)
==5077== by 0x814F8B9: load_projects() (db.c:9188)
==5077== by 0x8133A39: boot_db(bool) (db.c:771)
==5077== by 0x81235D4: main (comm.c:525)
==5077==
==5077== Invalid read of size 4
==5077== at 0x420B510: fclose@@GLIBC_2.1 (iofclose.c:54)
==5077== by 0x814F8E8: load_projects() (db.c:9194)
==5077== by 0x8133A39: boot_db(bool) (db.c:771)
==5077== by 0x81235D4: main (comm.c:525)
==5077== Address 0x4b1aaa8 is 0 bytes inside a block of size 352 free'd
==5077== at 0x402B3D8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5077== by 0x420B639: fclose@@GLIBC_2.1 (iofclose.c:85)
==5077== by 0x814F939: read_project(_IO_FILE*) (db.c:9213)
==5077== by 0x814F8B9: load_projects() (db.c:9188)
==5077== by 0x8133A39: boot_db(bool) (db.c:771)
==5077== by 0x81235D4: main (comm.c:525)
==5077==

This is repeated several times.

Quote:

==5077== HEAP SUMMARY:
==5077== in use at exit: 3,684,707 bytes in 37,865 blocks
==5077== total heap usage: 40,847 allocs, 2,983 frees, 4,124,959 bytes allocated
==5077==
==5077== 36 bytes in 1 blocks are definitely lost in loss record 320 of 620
==5077== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5077== by 0x818389E: fread_liquid(_IO_FILE*) (liquids.c:125)
==5077== by 0x8183CA6: load_liquids() (liquids.c:224)
==5077== by 0x8131B3F: boot_db(bool) (db.c:441)
==5077== by 0x81235D4: main (comm.c:525)
==5077==
==5077== LEAK SUMMARY:
==5077== definitely lost: 36 bytes in 1 blocks
==5077== indirectly lost: 0 bytes in 0 blocks
==5077== possibly lost: 0 bytes in 0 blocks
==5077== still reachable: 3,684,671 bytes in 37,864 blocks
==5077== suppressed: 0 bytes in 0 blocks
==5077== Reachable blocks (those to which a pointer was found) are not shown.
==5077== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5077==
==5077== For counts of detected and suppressed errors, rerun with: -v
==5077== Use --track-origins=yes to see where uninitialised values come from
==5077== ERROR SUMMARY: 32 errors from 27 contexts (suppressed: 0 from 0)

I have no idea if the error is caused by fCopyOver in comm.c or if it will be something else.

Edit db.c in the line 9194
comment: /* fclose( fp ); */
resolved!

Nick Gammon Australia Forum Administrator Wed 19 Oct 2016 02:00 AM #4

Quote:

==5077== Address 0x4b1aaee is 70 bytes inside a block of size 352 free'd

I had something like that recently. I was incrementing a pointer to step through a block of memory, and then tried to free the pointer (which was inside the block, not at the start of the block).