07 Oct, 2007, Vladaar wrote in the 1st comment:
Votes: 0
I'm getting killed from crashes involving this…

Anyone know what fixes that off hand?

Sun Oct 7 14:18:56 PDT 2007
^I'm getting killed from crashes involving this…

Anyone know what fixes that off hand?

Sun Oct 7 14:18:56 PDT 2007
^[[?1034hUsing host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./6dragons 4000'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000037afe77160 in strlen () from /lib64/libc.so.6

Then that crash is almost always followed by this…

Sun Oct 7 14:21:29 PDT 2007
^[[?1034hUsing host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./6dragons 4000'.
Program terminated with signal 7, Bus error.
#0 0x00000000004a440b in str_cmp (
astr=0x204c4c554e203a72 <Address 0x204c4c554e203a72 out of bounds>,
bstr=0x7fff703830bd "demon") at db.c:3952
3952 for(; *astr || *bstr; astr++, bstr++)
07 Oct, 2007, David Haley wrote in the 2nd comment:
Votes: 0
The astr pointer is an invalid pointer. You'd need to get more information like the backtrace for this to be debuggable. Try running your program in gdb. Another good thing to try would be to run the code in valgrind to identify when the pointer goes bad.
07 Oct, 2007, Vladaar wrote in the 3rd comment:
Votes: 0
–9797– Valgrind library directory: /usr/lib64/valgrind
–9797– Reading syms from /home/vladaar/6dragons/6dragons (0x400000)
–9797– Reading syms from /usr/lib64/valgrind/amd64-linux/memcheck (0x38000000)
–9797– object doesn't have a dynamic symbol table
–9797– Reading syms from /lib64/ld-2.6.so (0x37AFA00000)
–9797– Reading suppressions file: /usr/lib64/valgrind/default.supp
–9797– Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_core.so (0x4802000)
–9797– Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so (0x4A03000)
–9797– REDIR: 0x37AFA14460 (index) redirected to 0x4A06710 (index)
–9797– REDIR: 0x37AFA14610 (strcmp) redirected to 0x4A06880 (strcmp)
–9797– REDIR: 0x37AFA14640 (strlen) redirected to 0x4A067B0 (strlen)
–9797– Reading syms from /lib64/libz.so.1.2.3 (0x37B0E00000)
–9797– object doesn't have a symbol table
–9797– Reading syms from /lib64/libcrypt-2.6.so (0x37B1A00000)
–9797– Reading syms from /lib64/libc-2.6.so (0x37AFE00000)
–9797– REDIR: 0x37AFE77540 (rindex) redirected to 0x4A065C0 (rindex)
–9797– REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x38027B67 (???)
–9797– REDIR: 0xFFFFFFFFFF600400 (???) redirected to 0x38027B71 (???)
–9797– REDIR: 0x37AFE77150 (strlen) redirected to 0x4A06770 (strlen)
–9797– REDIR: 0x37AFE72470 (malloc) redirected to 0x4A05914 (malloc)
–9797– REDIR: 0x37AFE78F50 (memcpy) redirected to 0x4A074F0 (memcpy)
–9797– REDIR: 0x37AFE73A90 (free) redirected to 0x4A05524 (free)
–9797– REDIR: 0x37AFE76C10 (strcpy) redirected to 0x4A07750 (strcpy)
–9797– REDIR: 0x37AFE76BD0 (strcmp) redirected to 0x4A06840 (strcmp)
–9797– REDIR: 0x37AFE77240 (strnlen) redirected to 0x4A06740 (strnlen)
–9797– REDIR: 0x37AFE78550 (mempcpy) redirected to 0x4A06FD0 (mempcpy)
Sun Oct 7 14:34:31 2007 :: IMC: Loading IMC2 command table…
Sun Oct 7 14:34:31 2007 :: IMC: No command table found.
Sun Oct 7 14:34:31 2007 :: ***BUG*** IMC: imc_startup: Unable to load command table!
Sun Oct 7 14:34:31 2007 :: Booting Database
Sun Oct 7 14:34:31 2007 :: [*****] BOOT: ———————[ Boot Log ]——————–
Sun Oct 7 14:34:31 2007 :: Loading commands
Sun Oct 7 14:34:31 2007 :: [*****] BUG: Cannot open commands.dat
–9797– REDIR: 0x37AFE78440 (memset) redirected to 0x4A06A20 (memset)
==9797==
==9797== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
–9797–
–9797– supp: 4 dl-hack3
==9797== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9797== malloc/free: 12 allocs, 12 frees, 4,739 bytes allocated.
==9797==
==9797== All heap blocks were freed – no leaks are possible.
–9797– memcheck: sanity checks: 0 cheap, 1 expensive
–9797– memcheck: auxmaps: 127 auxmap entries (8128k, 7M) in use
–9797– memcheck: auxmaps: 85013 searches, 186990 comparisons
–9797– memcheck: SMs: n_issued = 20 (320k, 0M)
–9797– memcheck: SMs: n_deissued = 0 (0k, 0M)
–9797– memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M)
–9797– memcheck: SMs: max_undefined = 0 (0k, 0M)
–9797– memcheck: SMs: max_defined = 218 (3488k, 3M)
–9797– memcheck: SMs: max_non_DSM = 20 (320k, 0M)
–9797– memcheck: max sec V bit nodes: 0 (0k, 0M)
–9797– memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
–9797– memcheck: max shadow mem size: 4464k, 4M
–9797– translate: fast SP updates identified: 1,586 ( 85.7%)
–9797– translate: generic_known SP updates identified: 182 ( 9.8%)
–9797– translate: generic_unknown SP updates identified: 82 ( 4.4%)
–9797– tt/tc: 4,638 tt lookups requiring 4,716 probes
–9797– tt/tc: 4,638 fast-cache updates, 5 flushes
–9797– transtab: new 2,194 (50,778 -> 953,578; ratio 187:10) [0 scs]
–9797– transtab: dumped 0 (0 -> ??)
–9797– transtab: discarded 12 (257 -> ??)
–9797– scheduler: 40,723 jumps (bb entries).
–9797– scheduler: 0/2,553 major/minor sched events.
–9797– sanity: 1 cheap, 1 expensive checks.
–9797– exectx: 30,011 lists, 20 contexts (avg 0 per list)
–9797– exectx: 28 searches, 8 full compares (285 per 1000)
–9797– exectx: 0 cmp2, 6 cmp4, 0 cmpAll
07 Oct, 2007, kiasyn wrote in the 4th comment:
Votes: 0
you're doing it wrong.

edit: clarification: obviously not starting valgrind thingy in the right folder, preventing it from opening command tables, and shutting down.
07 Oct, 2007, Vladaar wrote in the 5th comment:
Votes: 0
Hrm,

been awhile since I used valgrind. I have my source executable compiling to the mud directory itself instead of src

from area directory this is what I tried

valgrind -v –tool=memcheck –leak-check=yes –show-reachable=yes –db-attach=yes –num-callers=10 –track-fds=yes –suppressions=../src/vg_suppress.supp ..6dragons 4000
07 Oct, 2007, David Haley wrote in the 6th comment:
Votes: 0
How would you start your MUD by hand, without using the startup script? e.g. which directory would you go to and what would you type? That is what you should do to run valgrind. The above output is indicating that it can't find the files it expects to find.
08 Oct, 2007, Vladaar wrote in the 7th comment:
Votes: 0
Got it now, thanks.

Vladaar
08 Oct, 2007, Vladaar wrote in the 8th comment:
Votes: 0
==16573== 11,776 bytes in 368 blocks are still reachable in loss record 40 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4AC3C2: load_objects (db.c:1841)
==16573== by 0x4AD2F2: load_area_file (db.c:5695)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 14,040 bytes in 27 blocks are still reachable in loss record 41 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x485E3B: load_mudchannels (channels.c:140)
==16573== by 0x4ADC43: boot_db (db.c:475)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 15,264 bytes in 477 blocks are still reachable in loss record 42 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4A6077: mprog_read_programs (db.c:4725)
==16573== by 0x4ACD4A: load_mobiles (db.c:1671)
==16573== by 0x4AD2CD: load_area_file (db.c:5693)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 15,360 bytes in 48 blocks are still reachable in loss record 43 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4A9513: load_area (db.c:1054)
==16573== by 0x4ACF2A: load_area_file (db.c:5651)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 19,381 bytes in 302 blocks are still reachable in loss record 44 of 64
==16573== at 0x4A05996: malloc (vg_replace_malloc.c:149)
==16573== by 0x37AFE76EC1: strdup (in /lib64/libc-2.6.so)
==16573== by 0x4072F6: imcfread_line (imc.c:1231)
==16573== by 0x41022F: imc_readcommand (imc.c:4334)
==16573== by 0x41039C: imc_load_commands (imc.c:4397)
==16573== by 0x41151D: imc_startup (imc.c:5138)
==16573== by 0x49DF18: main (comm.c:702)
==16573==
==16573==
==16573== 25,792 bytes in 806 blocks are still reachable in loss record 45 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4AB3A4: load_rooms (db.c:2315)
==16573== by 0x4AD33C: load_area_file (db.c:5699)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 25,792 bytes in 806 blocks are still reachable in loss record 46 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4A6214: mprog_read_programs (db.c:4765)
==16573== by 0x4ACD4A: load_mobiles (db.c:1671)
==16573== by 0x4AD2CD: load_area_file (db.c:5693)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 30,816 bytes in 428 blocks are still reachable in loss record 47 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x538622: fread_social (tables.c:710)
==16573== by 0x5388D5: load_socials (tables.c:793)
==16573== by 0x4ADE02: boot_db (db.c:538)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 32,936 bytes in 1 blocks are still reachable in loss record 48 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x40FA4E: imc_read_config (imc.c:4673)
==16573== by 0x41153C: imc_startup (imc.c:5148)
==16573== by 0x49DF18: main (comm.c:702)
==16573==
==16573==
==16573== 44,784 bytes in 933 blocks are still reachable in loss record 49 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x537F93: fread_cnv (tables.c:999)
==16573== by 0x538197: load_tongues (tables.c:1044)
==16573== by 0x4ADFA2: boot_db (db.c:574)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 51,376 bytes in 494 blocks are still reachable in loss record 50 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x538240: fread_command (tables.c:823)
==16573== by 0x5385A0: load_commands (tables.c:964)
==16573== by 0x4ADC39: boot_db (db.c:473)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 60,288 bytes in 1,256 blocks are still reachable in loss record 51 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4A7D77: load_helps (db.c:1361)
==16573== by 0x4AD2A8: load_area_file (db.c:5691)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 76,752 bytes in 1,599 blocks are still reachable in loss record 52 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4AC2CB: load_objects (db.c:1825)
==16573== by 0x4AD2F2: load_area_file (db.c:5695)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 123,504 bytes in 498 blocks are still reachable in loss record 53 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x5120AD: fread_obj (save.c:2022)
==16573== by 0x4A63BC: load_storage (db.c:6918)
==16573== by 0x4A64D4: load_storages (db.c:6872)
==16573== by 0x4B0F29: boot_db (db.c:989)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 190,400 bytes in 4,760 blocks are still reachable in loss record 54 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x50CF83: make_reset (reset.c:2148)
==16573== by 0x50D767: add_reset (reset.c:2172)
==16573== by 0x4ABDAA: load_resets (db.c:2130)
==16573== by 0x4AD317: load_area_file (db.c:5697)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 220,864 bytes in 493 blocks are still reachable in loss record 55 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x53895D: fread_skill (tables.c:338)
==16573== by 0x539582: load_skill_table (tables.c:627)
==16573== by 0x4ADE16: boot_db (db.c:541)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 272,934 bytes in 8,461 blocks are still reachable in loss record 56 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4A8226: str_dup (db.c:3489)
==16573== by 0x4A8759: fread_string_nohash (db.c:3585)
==16573== by 0x538439: fread_command (tables.c:875)
==16573== by 0x5385A0: load_commands (tables.c:964)
==16573== by 0x4ADC39: boot_db (db.c:473)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 314,304 bytes in 1,637 blocks are still reachable in loss record 57 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4ABF13: load_objects (db.c:1750)
==16573== by 0x4AD2F2: load_area_file (db.c:5695)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 336,336 bytes in 1,078 blocks are still reachable in loss record 58 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4AC6C6: load_mobiles (db.c:1466)
==16573== by 0x4AD2CD: load_area_file (db.c:5693)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 480,376 bytes in 1,937 blocks are still reachable in loss record 59 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4AA2F7: create_object (db.c:2928)
==16573== by 0x50F537: reset_area (reset.c:1538)
==16573== by 0x4ADB80: load_buildlist (db.c:5909)
==16573== by 0x4B0F01: boot_db (db.c:984)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 706,752 bytes in 9,816 blocks are still reachable in loss record 60 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4A1F9D: make_exit (db.c:5518)
==16573== by 0x4AB2A6: load_rooms (db.c:2283)
==16573== by 0x4AD33C: load_area_file (db.c:5699)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 976,144 bytes in 4,693 blocks are still reachable in loss record 61 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4AB000: load_rooms (db.c:2200)
==16573== by 0x4AD33C: load_area_file (db.c:5699)
==16573== by 0x4B0E89: boot_db (db.c:953)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 1,103,872 bytes in 88 blocks are still reachable in loss record 62 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4C142C: load_board (gboard.c:340)
==16573== by 0x4C1690: load_global_boards (gboard.c:400)
==16573== by 0x4B108C: boot_db (db.c:1033)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 1,798,752 bytes in 1,828 blocks are still reachable in loss record 63 of 64
==16573== at 0x4A04CBF: calloc (vg_replace_malloc.c:279)
==16573== by 0x4AA751: create_mobile (db.c:2824)
==16573== by 0x4F10A0: init_supermob (mud_prog.c:147)
==16573== by 0x4B0E9D: boot_db (db.c:962)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573==
==16573== 2,745,456 bytes in 20,485 blocks are still reachable in loss record 64 of 64
==16573== at 0x4A05996: malloc (vg_replace_malloc.c:149)
==16573== by 0x4E25F3: str_alloc (memory.c:72)
==16573== by 0x4A52C8: fread_string (db.c:3570)
==16573== by 0x485CCA: read_channel (channels.c:85)
==16573== by 0x485E7D: load_mudchannels (channels.c:141)
==16573== by 0x4ADC43: boot_db (db.c:475)
==16573== by 0x49DF2E: main (comm.c:706)
==16573==
==16573== LEAK SUMMARY:
==16573== definitely lost: 0 bytes in 0 blocks.
==16573== possibly lost: 0 bytes in 0 blocks.
==16573== still reachable: 9,771,291 bytes in 64,679 blocks.
==16573== suppressed: 0 bytes in 0 blocks.
–16573– memcheck: sanity checks: 1415 cheap, 57 expensive
–16573– memcheck: auxmaps: 161 auxmap entries (10304k, 10M) in use
–16573– memcheck: auxmaps: 66652995 searches, 70885199 comparisons
–16573– memcheck: SMs: n_issued = 228 (3648k, 3M)
–16573– memcheck: SMs: n_deissued = 0 (0k, 0M)
–16573– memcheck: SMs: max_noaccess = 524287 (8388592k, 8191M)
–16573– memcheck: SMs: max_undefined = 0 (0k, 0M)
–16573– memcheck: SMs: max_defined = 311 (4976k, 4M)
–16573– memcheck: SMs: max_non_DSM = 228 (3648k, 3M)
–16573– memcheck: max sec V bit nodes: 3 (0k, 0M)
–16573– memcheck: set_sec_vbits8 calls: 4 (new: 3, updates: 1)
–16573– memcheck: max shadow mem size: 7792k, 7M
–16573– translate: fast SP updates identified: 15,796 ( 93.3%)
–16573– translate: generic_known SP updates identified: 982 ( 5.8%)
–16573– translate: generic_unknown SP updates identified: 151 ( 0.8%)
–16573– tt/tc: 69,572 tt lookups requiring 73,598 probes
–16573– tt/tc: 69,572 fast-cache updates, 8 flushes
–16573– transtab: new 11,377 (272,223 -> 4,776,586; ratio 175:10) [0 scs]
–16573– transtab: dumped 0 (0 -> ??)
–16573– transtab: discarded 576 (12,531 -> ??)
–16573– scheduler: 141,509,981 jumps (bb entries).
–16573– scheduler: 1,415/129,799 major/minor sched events.
–16573– sanity: 1416 cheap, 57 expensive checks.
–16573– exectx: 30,011 lists, 571 contexts (avg 0 per list)
–16573– exectx: 66,901 searches, 66,338 full compares (991 per 1000)
–16573– exectx: 838,869 cmp2, 6 cmp4, 0 cmpAll
08 Oct, 2007, Zeno wrote in the 9th comment:
Votes: 0
You know a backtrace from gdb might have been a bit easier to start off with.
08 Oct, 2007, Vladaar wrote in the 10th comment:
Votes: 0
warning: exec file is newer than core file.
Core was generated by `./6dragons 4000'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000037afe77160 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0 0x00000037afe77160 in _start () from /lib64/ld-linux-x86-64.so.2
#1 0x00000037afe460bb in ?? ()
#2 0x000000000000000f in ?? ()
#3 0x00000000004c1aac in exp_class_level (ch=0x3e800000001, level=<value optimized out>, class_info=2248) at handler.c:137
#4 0x0000000000545721 in gain_exp (ch=0x7fffeb49c720, gain=<value optimized out>) at update.c:500
#5 0x00000000007ffec5 in buf.13091 ()
#6 0x00007fffeb4a221e in ?? ()
#7 0x0000000001286e00 in ?? ()
#8 0x0000000001286e00 in ?? ()
#9 0x00000037afe4bfa3 in ?? ()
#10 0x0000003000000020 in ?? ()
#11 0x0000000001142380 in ?? ()
#12 0x00007fffeb4a09a0 in ?? ()
#13 0x0000000001142380 in ?? ()
#14 0x00007fffeb4a4a66 in ?? ()
#15 0x00007fffeb4a3a00 in ?? ()
#16 0x00007fffeb4a4200 in ?? ()
#17 0x00000000004c8630 in get_obj_world (ch=0x3e800000001, argument=0x3 <Address 0x3 out of bounds>) at handler.c:2307
#18 0x00007fffeb4a2234 in ?? ()
#19 0x00007fffeb4a09a0 in ?? ()
#20 0x0000000001142380 in ?? ()
#21 0x00000000004c867f in get_obj_world (ch=0x7fffeb4a21b0, argument=0x1286e00 "Ы'\001") at handler.c:2314
#22 0x000000000044520c in do_ostat (ch=0x7fffeb4a4a66, argument=0x4791ee "\200") at act_wiz.c:1697
#23 0x00000000004d296a in interpret (ch=0x1142380, argument=0x1142380 "ÀV(\001") at interp.c:545
#24 0x000000000049bdf8 in game_loop () at comm.c:1087
#25 0x000000000049e128 in main (argc=<value optimized out>, argv=<value optimized out>) at comm.c:792
08 Oct, 2007, Zeno wrote in the 11th comment:
Votes: 0
Yeah you're not doing that right.
Quote
warning: exec file is newer than core file.

That needs to be fixed.

It also isn't the same data as your first post.
0.0/11