25 Oct, 2007, Vladaar wrote in the 1st comment:
Votes: 0
Identify spell and even ostat seems to crash my mud every time the object sparkling gem is identified.

Crash report really gives no useful details, so did a gdb, and got the below results. Still can't seem to figure it out. If anyone has any ideas let me know. Thanks.

(gdb) bt
#0 0x00000037afe77160 in strlen () from /lib64/libc.so.6
#1 0x00000037afe460bb in vfprintf () from /lib64/libc.so.6
#2 0x00000037afe67d4a in vsnprintf () from /lib64/libc.so.6
#3 0x00000000004918e0 in ch_printf (ch=0x131f9a0, fmt=0x7fff62b0d0a8 "\001") at color.c:1361
#4 0x000000000042fbc2 in identify_object (ch=0x131f9a0, obj=0x13259e0) at act_obj.c:3804
#5 0x00000000004dae9f in spell_identify (sn=<value optimized out>, level=<value optimized out>, ch=0x131f9a0,
vo=<value optimized out>) at magic.c:3285
#6 0x00000000004e0794 in do_cast (ch=0x131f9a0, argument=<value optimized out>) at magic.c:1798
#7 0x00000000004d1caa in interpret (ch=0x131f9a0, argument=0x7fff62b11ac2 "'ident' 2.gem") at interp.c:538
#8 0x000000000049b15c in game_loop () at comm.c:1194
#9 0x000000000049d492 in main (argc=<value optimized out>, argv=<value optimized out>) at comm.c:756


(gdb) frame 0
#0 0x00000037afe77160 in strlen () from /lib64/libc.so.6
(gdb) frame 1
#1 0x00000037afe460bb in vfprintf () from /lib64/libc.so.6
(gdb) frame 2
#2 0x00000037afe67d4a in vsnprintf () from /lib64/libc.so.6
(gdb) frame 3
#3 0x00000000004918c0 in ch_printf (ch=0x1185d90, fmt=0x7fff6dcfe2c8 "\001") at color.c:1361
1361 vsnprintf(buf, MSL * 2, fmt, args);
(gdb) print fmt
$1 = 0x7fff6dcfe2c8 "\001"
(gdb) print ch
$2 = (CHAR_DATA *) 0x1185d90
(gdb) print args
$3 = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7fff6dcfe380, reg_save_area = 0x7fff6dcfe2b0}}
(gdb) print buf
$4 = "This item is worth about 1000 weight is 1 and level is
20.\n\r\000\000\000\001\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000@t/\001\000\000\000\000hj�7", '\0'
, "��������\220��m\031\000\000\000\200��7", '\0' ,
"\030��m�\177\000\000\000\000\000\000\006\000\000\000\v", '\0' , "\n", '\0' , "
\000\000\000\000\000\000\000$�M\000\000\000\000\000$n utters th"…
(gdb) frame 4
#4 0x000000000042fba7 in identify_object (ch=0x1185d90, obj=0x1193e90) at act_obj.c:3799
3799 ch_printf(ch, "This item is worth about %d %s coins.\n\r", obj->cost, curr_types[obj->currtype]);
(gdb) print ch
$5 = (CHAR_DATA *) 0x1185d90
(gdb) print obj
$6 = (OBJ_DATA *) 0x1193e90
(gdb) print currtype
No symbol "currtype" in current context.
(gdb) frame 5
#5 0x00000000004dae7f in spell_identify (sn=, level=, ch=0x1185d90,
vo=) at magic.c:3285
3285 identify_object(ch, obj);
(gdb) print obj
$7 = (OBJ_DATA *) 0x1193e90
(gdb) print vo
$8 =
(gdb)


Also, crash with ostat looks like

#2 0x00000037afe67d4a in vsnprintf () from /lib64/libc.so.6
(gdb) frame 3
#3 0x00000000004918d0 in ch_printf (ch=0x12fa0e0, fmt=0x7ffff0fcfe18 "\001") at color.c:1361
1361 vsnprintf(buf, MSL * 2, fmt, args);
(gdb) print buf
$1 = "&cCost: &w1000&c/\r\000ow\n\r\000ld\n\r\000sparkles here.\n\r\000\000\000 \017÷\000\000\000\000\000\001", '\0' <repeats 15 times>, "\023iO\000\000\000\000\000°)\222", '\0' <repeats 13 times>, "°4÷\000\000\000\000\000 \017÷\000\000\000\000\000°4÷\000\000\000\000\000Ú(L\000\000\000\000\000\220¨ô", '\0' <repeats 13 times>, "\220¨ô\000\000\000\000\000\230iO", '\0' <repeats 21 times>, "\220¨ô\000\000\000\000\0007ÕB\000\000\000\000\000©\215U\000\000\000\000\000`±Y\000\000\000\000\000ð\200¥\000\000\000\000\000\000\000\003\000\001", '\0' <repeats 19 times>…
(gdb) print args
$2 = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7ffff0fcfed0, reg_save_area = 0x7ffff0fcfe00}}
(gdb) frame 4
#4 0x000000000044638c in do_ostat (ch=0x12fa0e0, argument=0x7ffff0fd3fb6 "2.14015") at act_wiz.c:1702
1702 ch_printf(ch, "&cCost: &w%d&c/%s\n\r", obj->cost, curr_types[obj->currtype]);
(gdb) print ch
$3 = (CHAR_DATA *) 0x12fa0e0
(gdb) print argument
$4 = 0x7ffff0fd3fb6 "2.14015"
25 Oct, 2007, David Haley wrote in the 2nd comment:
Votes: 0
Why is your format string equal to just the 1-valued byte?

I'd suggest running this through valgrind to see what happens, it'll tell you what's wrong a lot quicker than any of us could from just that output.
25 Oct, 2007, Vladaar wrote in the 3rd comment:
Votes: 0
Whenever I run valgrind, it gives me results, but it stops running right after memory leak results. Maybe it's the command I use for valgrind not sure, but I thought valgrind is supposed to keep running until you shut down the mud. No way for me to do the identify spell in valgrind, cause it shuts down before you can.


valgrind -v –tool=memcheck –leak-check=yes –show-reachable=yes –db-attach=yes ../6dragons/6dragons 4000
25 Oct, 2007, David Haley wrote in the 4th comment:
Votes: 0
I wouldn't run it with leak checks; your immediate problem is a crash, not a leak. :smile:

That said, it's not normal that you can't get into the MUD when you start it under valgrind. If you were to start your MUD manually, what do you do?
25 Oct, 2007, Vladaar wrote in the 5th comment:
Votes: 0
I am on the mud when I use valgrind command in shell. Should I use valgrind command after mud is shutdown instead?

Vladaar
25 Oct, 2007, David Haley wrote in the 6th comment:
Votes: 0
Yup: you should start the MUD using valgrind, and not attach it to the running process.
25 Oct, 2007, Vladaar wrote in the 7th comment:
Votes: 0
Thu Oct 25 00:09:31 2007 :: Loading player data for Vladaar (18K)
==19870== Invalid read of size 1
==19870== at 0x4A06772: strlen (mc_replace_strmem.c:246)
==19870== by 0x37AFE460BA: vfprintf (in /lib64/libc-2.6.so)
==19870== by 0x37AFE67D49: vsnprintf (in /lib64/libc-2.6.so)
==19870== by 0x49193F: ch_printf (color.c:1361)
==19870== by 0x4463FB: do_ostat (act_wiz.c:1702)
==19870== by 0x4D1D09: interpret (interp.c:538)
==19870== by 0x49B1BB: game_loop (comm.c:1194)
==19870== by 0x49D4F1: main (comm.c:756)
==19870== Address 0x3E800000001 is not stack'd, malloc'd or (recently) free'd
==19870==
==19870== —- Attach to debugger ? — [Return/N/n/Y/y/C/c] —- Y
starting debugger
==19870== starting debugger with cmd: /usr/bin/gdb -nw /proc/19875/fd/1014 19875
GNU gdb Red Hat Linux (6.6-16.fc7rh)
Copyright (C) 2006 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 "x86_64-redhat-linux-gnu"…
Using host libthread_db library "/lib64/libthread_db.so.1".
Attaching to program: /proc/19875/fd/1014, process 19875
0x0000000004a06772 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb)
25 Oct, 2007, Vladaar wrote in the 8th comment:
Votes: 0
–20092– REDIR: 0x37AFE76860 (strcat) redirected to 0x4A07830 (strcat)
==20092== Invalid read of size 1
==20092== at 0x4A06772: strlen (mc_replace_strmem.c:246)
==20092== by 0x37AFE460BA: vfprintf (in /lib64/libc-2.6.so)
==20092== by 0x37AFE67D49: vsnprintf (in /lib64/libc-2.6.so)
==20092== by 0x49193F: ch_printf (color.c:1361)
==20092== by 0x42FBC1: identify_object (act_obj.c:3804)
==20092== by 0x4DAEFE: spell_identify (magic.c:3285)
==20092== by 0x4E07F3: do_cast (magic.c:1798)
==20092== by 0x4D1D09: interpret (interp.c:538)
==20092== by 0x49B1BB: game_loop (comm.c:1194)
==20092== by 0x49D4F1: main (comm.c:756)
==20092== Address 0x3E800000001 is not stack'd, malloc'd or (recently) free'd
==20092==
==20092== —- Attach to debugger ? — [Return/N/n/Y/y/C/c] —- y
starting debugger
==20092== starting debugger with cmd: /usr/bin/gdb -nw /proc/20116/fd/1014 20116
GNU gdb Red Hat Linux (6.6-16.fc7rh)
Copyright (C) 2006 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 "x86_64-redhat-linux-gnu"…
Using host libthread_db library "/lib64/libthread_db.so.1".
Attaching to program: /proc/20116/fd/1014, process 20116
0x0000000004a06772 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0 0x0000000004a06772 in _start () from /lib64/ld-linux-x86-64.so.2
#1 0x0000000038026568 in ?? ()
#2 0x0000000000000000 in ?? ()
(gdb) frame 0
#0 0x0000000004a06772 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) frame 1
#1 0x0000000038026568 in ?? ()
(gdb) frame 2
#2 0x0000000000000000 in ?? ()
(gdb) frame 3
#0 0x0000000000000000 in ?? ()
(gdb) frame 4
#0 0x0000000000000000 in ?? ()
(gdb) frame 5
#0 0x0000000000000000 in ?? ()
(gdb)

The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /proc/20116/fd/1014, process 20116
==20092==
==20092== Debugger has detached. Valgrind regains control. We continue.
==20092==
==20092== Process terminating with default action of signal 11 (SIGSEGV)
==20092== Access not within mapped region at address 0x3E800000001
==20092== at 0x4A06772: strlen (mc_replace_strmem.c:246)
==20092== by 0x37AFE460BA: vfprintf (in /lib64/libc-2.6.so)
==20092== by 0x37AFE67D49: vsnprintf (in /lib64/libc-2.6.so)
==20092== by 0x49193F: ch_printf (color.c:1361)
==20092== by 0x42FBC1: identify_object (act_obj.c:3804)
==20092== by 0x4DAEFE: spell_identify (magic.c:3285)
==20092== by 0x4E07F3: do_cast (magic.c:1798)
==20092== by 0x4D1D09: interpret (interp.c:538)
==20092== by 0x49B1BB: game_loop (comm.c:1194)
==20092== by 0x49D4F1: main (comm.c:756)
==20092==
==20092== —- Attach to debugger ? — [Return/N/n/Y/y/C/c] —- c
–20092– Discarding syms at 0x4D14000-0x4F1F000 in /lib64/libnss_files-2.6.so due to munmap()
–20092– Discarding syms at 0x4F1F000-0x5124000 in /lib64/libnss_dns-2.6.so due to munmap()
–20092– Discarding syms at 0x37B3200000-0x37B3415000 in /lib64/libresolv-2.6.so due to munmap()
==20092==
==20092== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 1)
==20092==
==20092== 1 errors in context 1 of 1:
==20092== Invalid read of size 1
==20092== at 0x4A06772: strlen (mc_replace_strmem.c:246)
==20092== by 0x37AFE460BA: vfprintf (in /lib64/libc-2.6.so)
==20092== by 0x37AFE67D49: vsnprintf (in /lib64/libc-2.6.so)
==20092== by 0x49193F: ch_printf (color.c:1361)
==20092== by 0x42FBC1: identify_object (act_obj.c:3804)
==20092== by 0x4DAEFE: spell_identify (magic.c:3285)
==20092== by 0x4E07F3: do_cast (magic.c:1798)
==20092== by 0x4D1D09: interpret (interp.c:538)
==20092== by 0x49B1BB: game_loop (comm.c:1194)
==20092== by 0x49D4F1: main (comm.c:756)
==20092== Address 0x3E800000001 is not stack'd, malloc'd or (recently) free'd
25 Oct, 2007, David Haley wrote in the 9th comment:
Votes: 0
Well, it looks like I was right that the problem is a bogus format string… where is your 'fmt' string coming from in the code?
25 Oct, 2007, Vladaar wrote in the 10th comment:
Votes: 0
Trying to figure that out.

Vladaar
25 Oct, 2007, Vladaar wrote in the 11th comment:
Votes: 0
In color.c 1361 I have this…

void ch_printf(CHAR_DATA * ch, char *fmt, …)
{
char buf[MSL * 2];
va_list args;

if(!fmt)
{
send_to_char("Invalid fmt, Bailing out!", ch);
return;
}

va_start(args, fmt);
vsnprintf(buf, MSL * 2, fmt, args); // line 1361 is here
va_end(args);
send_to_char_color(buf, ch);
}
25 Oct, 2007, David Haley wrote in the 12th comment:
Votes: 0
That looks more or less like stock to me. The problem is probably where you call ch_printf.
25 Oct, 2007, Vladaar wrote in the 13th comment:
Votes: 0
act_obj.c line 3804

if (obj->currtype)
{
if(obj->cost > 0)
ch_printf(ch, "This item is worth about %d %s coins.\n\r", obj->cost, curr_types[obj->currtype]); // line 3804
else
send_to_char( "It cannot be determined what this object is worth.\n\r", ch);
}
25 Oct, 2007, David Haley wrote in the 14th comment:
Votes: 0
Is curr_types[obj->currtype] a valid value?
25 Oct, 2007, Vladaar wrote in the 15th comment:
Votes: 0
Should be… It's used in my shops.c

Got my curr_type currency code from Garil long ago. I don't recall shops ever crashing us, but identify spell, and ostat will. Could it just be ch_printf not liking it?

In shops.c I have a line like

snprintf(buf, MSL, "Its weight is %d, value is %d %s, and level is %d", obj->weight, obj->cost, curr_types[obj->currtype], obj->level);

That works fine with snprintf

Vladaar
25 Oct, 2007, David Haley wrote in the 16th comment:
Votes: 0
You should probably double-check the value from within gdb, at this point we need to cover all of our bases… lest they all are belong to them!
25 Oct, 2007, Vladaar wrote in the 17th comment:
Votes: 0
(gdb) bt
#0 0x00000037afe77160 in strlen () from /lib64/libc.so.6
#1 0x00000037afe460bb in vfprintf () from /lib64/libc.so.6
#2 0x00000037afe67d4a in vsnprintf () from /lib64/libc.so.6
#3 0x00000037afe4bfa3 in snprintf () from /lib64/libc.so.6
#4 0x000000000042fbce in identify_object (ch=0x131c3e0, obj=0x131dbb0) at act_obj.c:3806
#5 0x00000000004daf2f in spell_identify (sn=<value optimized out>, level=<value optimized out>, ch=0x131c3e0,
vo=<value optimized out>) at magic.c:3285
#6 0x00000000004e0824 in do_cast (ch=0x131c3e0, argument=<value optimized out>) at magic.c:1798
#7 0x00000000004d1d3a in interpret (ch=0x131c3e0, argument=0x7fffb594a905 "identify gem") at interp.c:538
#8 0x000000000049b1ec in game_loop () at comm.c:1194
#9 0x000000000049d522 in main (argc=<value optimized out>, argv=<value optimized out>) at comm.c:756
(gdb) frame 4
#4 0x000000000042fbce in identify_object (ch=0x131c3e0, obj=0x131dbb0) at act_obj.c:3806
3806 snprintf(buf, MSL, "This item is worth about %d %s coins.\n\r", obj->cost, curr_types[obj->currtype]);
(gdb) print curr_types[obj->currtype]
$1 = 0x3e800000001 <Address 0x3e800000001 out of bounds>
(gdb)
25 Oct, 2007, David Haley wrote in the 18th comment:
Votes: 0
Well… there you go… chances are that obj->currtype is going out of bounds for curr_types.

Never make assumptions about what should and shouldn't be ok when you get inexplicable errors. :wink:
25 Oct, 2007, Vladaar wrote in the 19th comment:
Votes: 0
Thanks David, your the man. That was a great help, you taught me how to use gdb and valgrind working together to find a problem..

Vladaar
25 Oct, 2007, David Haley wrote in the 20th comment:
Votes: 0
No problem, glad I could help. :smile: (After this happens to you over and over and over again you start getting the hang of it… after losing some hair and sleep and all that.)
0.0/22