13 Jul, 2010, woocifer wrote in the 1st comment:
Votes: 0
Hello all,

First time trying to implement my own MUD, have pretty decent/good *nix experience, just running into some issues as I am trying to become more accustomed to coding.

I am currently trying to run the Static Chaos flavor codebase.

Initially I ran into similar errors as this poster here

However, I solved the issues and was able to execute the startup script which is
#! /bin/csh -f
# Written by Furey.
# With additions from Tony.

# Set the port number.
set port = 1985
if ( "$1" != "" ) set port="$1"

# Change to area directory.
cd ../area

# Set limits.
nohup
nice
limit stack 1024k
if ( -e shutdown.txt ) rm -f shutdown.txt

while ( 1 )
# If you want to have logs in a different directory,
# change the 'set logfile' line to reflect the directory name.
set index = 1000
while ( 1 )
set logfile = ../log/$index.log
if ( ! -e $logfile ) break
@ index++
end

# Record starting time
date > $logfile

# Record initial charges
# charges >> $logfile

# Run Chaosium.
../src/chaosium $port >&! $logfile
# ../src/merc >>&! $logfile

# Record ending charges
# charges >> $logfile

# # Delete this out if no adb.
# if ( -e core ) then
# echo '$c' | adb ../src/merc
# endif

# Restart, giving old connections a chance to die.
if ( -e shutdown.txt ) then
rm -f shutdown.txt
exit 0
endif
sleep 10
end


However, I receive 'Segmentation Fault(core dumped)' ..usually I would debug this with GDB no? However I am not receiving a core dump or seeing anything suspicious in the log directory, unable to connect to the port at all also via telnet. Running FreeBSD, have this in my ipfw rule

00120 allow tcp from *my ip* to me dst-port 1985 in


Not really sure what to do next, really liked this codebase, I remember playing it back in the day, liked its theme a lot. Any help would be much appreciated.

Thank you very much.
Woocifer
13 Jul, 2010, David Haley wrote in the 2nd comment:
Votes: 0
You might need to check your ulimit settings to make sure that you can write out a sufficiently large core, and also that you have enough disk space to do so. I'm in a hurry unfortunately so can't look up more stuff or show you an example, but hopefully that should point you in the right direction.
13 Jul, 2010, woocifer wrote in the 3rd comment:
Votes: 0
hello,

thank you for taking the time to reply, however stack limit of core data was unlimited. also disk space and memory was more than sufficient.


please let me know if you have more suggestions :)
13 Jul, 2010, ralgith wrote in the 4th comment:
Votes: 0
Make sure you're looking in the right place for your core file. For example, CircleMUD places it's core dumps in the lib subdirectory of its tree. So I have to run like this: gdb bin/circle lib/stackdump (stackdump being the name of the output core file)

That being said, why can't you do it this way (using circle as an example again):
$ gdb bin/circle
(gdb) run 9900
<game running messages here>
Segmentation Fault
(gdb) backtrace
<backtrace info appears here>
13 Jul, 2010, David Haley wrote in the 5th comment:
Votes: 0
I would first make sure that any kind of core dump works. ulimit can report something somewhat misleading. See this, for example…

$ ulimit    
unlimited
$ ulimit -c
0
$ cat test.c

#include <assert.h>

int main()
{
int*i = 0;
*i = 2;
return 0;
}

$ gcc test.c
$ ./a.out
zsh: segmentation fault ./a.out
$ ls -l core
ls: cannot access core: No such file or directory
$ ulimit -c 1000000
$ ./a.out
zsh: segmentation fault (core dumped) ./a.out
$ ls -l core
-rw——- 1 david david 143360 2010-07-13 12:28 core
$


Note that the initial ulimit command said 'unlimited' – you need to specify -c to get the core size.

Quote
That being said, why can't you do it this way (using circle as an example again):

Because you sometimes can't easily reproduce the error, but you want to debug it when the core file is dumped.
13 Jul, 2010, ralgith wrote in the 6th comment:
Votes: 0
Right, sometimes you can't easily reproduce it. However, since this is every time he runs the MUD… or at least that was the impression I got.
14 Jul, 2010, woocifer wrote in the 7th comment:
Votes: 0
i tried this to the 'chaosium' binary that was also ran in the startup script,

i did this earlier and i thought this couldnt be an issue because all the area files are in a different directory, should i just try symlinking everything to the src directory or am i thinking wrong completely?

]# gdb chaosium 
GNU gdb 6.1.1 [FreeBSD]
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-marcel-freebsd"…
(gdb) run 9900
Starting program: /root/SC/src/chaosium 9900
Wed Dec 31 19:00:00 1969 :: Got into main.
Tue Jul 13 23:15:45 2010 :: Time has been initialized.
Tue Jul 13 23:15:45 2010 :: fpReserve opened.
Tue Jul 13 23:15:45 2010 :: About to boot_db().
Tue Jul 13 23:15:45 2010 :: Now in boot_db(). Initializing data space stuff.
Tue Jul 13 23:15:45 2010 :: Initializing RNG.
Tue Jul 13 23:15:45 2010 :: Setting time and weather.
Tue Jul 13 23:15:45 2010 :: Setting up auction and voting globals.
Tue Jul 13 23:15:45 2010 :: Assigning GSNs.
Tue Jul 13 23:15:45 2010 :: Reading in all area files.
Tue Jul 13 23:15:45 2010 :: Opening AREA_LIST.
Tue Jul 13 23:15:45 2010 :: Entering load For loop.
Tue Jul 13 23:15:45 2010 :: help.are
Tue Jul 13 23:15:45 2010 :: olc.hlp
Tue Jul 13 23:15:45 2010 :: newhelp.are
newhelp.are: No such file or directory

Program exited with code 01.
(gdb)



help.are, olc.hlp, and newhelp.are were symlinked in by me
14 Jul, 2010, David Haley wrote in the 8th comment:
Votes: 0
Can you confirm that a basic example like the one I provided produces a core dump? Let's try to isolate the problem first.
14 Jul, 2010, woocifer wrote in the 9th comment:
Votes: 0
-=[~/test]=- -=[Wed Jul 14]=- -=[01:11:39]=-
[root@ninja]# ulimit
unlimited
-=[~/test]=- -=[Wed Jul 14]=- -=[01:11:41]=-
[root@ninja]# ulimit -c
unlimited
-=[~/test]=- -=[Wed Jul 14]=- -=[01:11:43]=-
[root@ninja]# cat test.c
#include <assert.h>


int main()
{
int*i = 0;
*i = 2;
return 0;
}

-=[~/test]=- -=[Wed Jul 14]=- -=[01:11:46]=-
[root@ninja]# gcc test.c
-=[~/test]=- -=[Wed Jul 14]=- -=[01:11:54]=-
[root@ninja]# ./a.out
Segmentation fault: 11 (core dumped)
-=[~/test]=- -=[Wed Jul 14]=- -=[01:11:56]=-
[root@ninja]# ls -alh
total 332
drwxr-xr-x 2 root wheel 512B Jul 14 01:12 .
drwx—— 10 root wheel 1.0K Jul 14 01:11 ..
-rwxr-xr-x 1 root wheel 4.5K Jul 14 01:11 a.out
-rw——- 1 root wheel 300K Jul 14 01:11 a.out.core
-rw-r–r– 1 root wheel 80B Jul 14 01:11 test.c
-=[~/test]=- -=[Wed Jul 14]=- -=[01:12:02]=-
[root@ninja]# ls -alh *core*
-rw——- 1 root wheel 300K Jul 14 01:11 a.out.core
14 Jul, 2010, David Haley wrote in the 10th comment:
Votes: 0
OK, good, thanks.

First off, you should really not be running this stuff as root; that's a major security hole and if your MUD has any issues, an attacker could take over the entire machine or do Very Bad Things. :sad:

You should indeed be trying to run without the startup script for now (again, to isolate the problem). You need to run the program from within whatever directory the program expects to be in normally, which is usually the area directory. So, from src, cd ../area, then ../src/chaosium 9900.

Core files will be placed in the current directory of the program, so (with the above directory changes) you should find them in the 'area' directory. (But it's a good idea to confirm that the crashes show up in gdb as well.)
15 Jul, 2010, woocifer wrote in the 11th comment:
Votes: 0
Thanks, am getting this now:


[root@ninja]# ../src/chaosium 1985
Wed Dec 31 19:00:00 1969 :: Got into main.
Wed Jul 14 22:31:43 2010 :: Time has been initialized.
Wed Jul 14 22:31:43 2010 :: fpReserve opened.
Wed Jul 14 22:31:43 2010 :: About to boot_db().
Wed Jul 14 22:31:43 2010 :: Now in boot_db(). Initializing data space stuff.
Wed Jul 14 22:31:43 2010 :: Initializing RNG.
Wed Jul 14 22:31:43 2010 :: Setting time and weather.
Wed Jul 14 22:31:43 2010 :: Setting up auction and voting globals.
Wed Jul 14 22:31:43 2010 :: Assigning GSNs.
Wed Jul 14 22:31:43 2010 :: Reading in all area files.
Wed Jul 14 22:31:43 2010 :: Opening AREA_LIST.
Wed Jul 14 22:31:43 2010 :: Entering load For loop.
Wed Jul 14 22:31:43 2010 :: help.are
Wed Jul 14 22:31:43 2010 :: olc.hlp
Wed Jul 14 22:31:43 2010 :: newhelp.are
Wed Jul 14 22:31:43 2010 :: logout.are
Wed Jul 14 22:31:43 2010 :: greeting.are
Wed Jul 14 22:31:43 2010 :: limbo.are
Wed Jul 14 22:31:43 2010 :: plains.are
Wed Jul 14 22:31:43 2010 :: ofcol2.are
Wed Jul 14 22:31:43 2010 :: olympus.are
Wed Jul 14 22:31:43 2010 :: air.are
Wed Jul 14 22:31:43 2010 :: shire.are
Wed Jul 14 22:31:43 2010 :: midgaard.are
Wed Jul 14 22:31:43 2010 :: hitower.are
Wed Jul 14 22:31:43 2010 :: gnome.are
Wed Jul 14 22:31:43 2010 :: wyvern.are
Wed Jul 14 22:31:43 2010 :: haven.are
Wed Jul 14 22:31:43 2010 :: astral.are
Wed Jul 14 22:31:43 2010 :: catacomb.are
Wed Jul 14 22:31:43 2010 :: hood.are
Wed Jul 14 22:31:43 2010 :: draconia.are
Wed Jul 14 22:31:43 2010 :: mahntor.are
Wed Jul 14 22:31:43 2010 :: ultima.are
Wed Jul 14 22:31:43 2010 :: trollden.are
Wed Jul 14 22:31:43 2010 :: midennir.are
Wed Jul 14 22:31:43 2010 :: grave.are
Wed Jul 14 22:31:43 2010 :: school.are
Wed Jul 14 22:31:43 2010 :: rats.are
Wed Jul 14 22:31:43 2010 :: moria.are
Wed Jul 14 22:31:43 2010 :: eastern.are
Wed Jul 14 22:31:43 2010 :: drow.are
Wed Jul 14 22:31:43 2010 :: thalos.are
Wed Jul 14 22:31:43 2010 :: ofcol.are
Wed Jul 14 22:31:43 2010 :: haon.are
Wed Jul 14 22:31:43 2010 :: dwarven.are
Wed Jul 14 22:31:43 2010 :: sewer.are
Wed Jul 14 22:31:43 2010 :: valley.are
Wed Jul 14 22:31:43 2010 :: redferne.are
Wed Jul 14 22:31:43 2010 :: marsh.are
Wed Jul 14 22:31:43 2010 :: canyon.are
Wed Jul 14 22:31:43 2010 :: galaxy.are
Wed Jul 14 22:31:43 2010 :: mobfact.are
Wed Jul 14 22:31:43 2010 :: apoc.are
Wed Jul 14 22:31:43 2010 :: cithdeux.are
Wed Jul 14 22:31:43 2010 :: vacation.are
Wed Jul 14 22:31:43 2010 :: arena.are
Wed Jul 14 22:31:43 2010 :: mazoku.are
Wed Jul 14 22:31:43 2010 :: renegades.are
Wed Jul 14 22:31:43 2010 :: teikoku.are
Wed Jul 14 22:31:43 2010 :: cards.are
Wed Jul 14 22:31:43 2010 :: divergent.are
Wed Jul 14 22:31:43 2010 :: malokteri.are
Wed Jul 14 22:31:43 2010 :: zrollers.are
Wed Jul 14 22:31:43 2010 :: $
Wed Jul 14 22:31:43 2010 :: [*****] BUG: Fix_exits: 812:0 -> 904:2 -> 903.
Wed Jul 14 22:31:43 2010 :: [*****] BUG: Fix_exits: 813:2 -> 1312:0 -> 1313.
Wed Jul 14 22:31:43 2010 :: [*****] BUG: Fix_exits: 814:2 -> 3001:0 -> 3054.
Wed Jul 14 22:31:43 2010 :: [*****] BUG: Fix_exits: 5063:1 -> 5031:3 -> 5030.
Wed Jul 14 22:31:43 2010 :: Merc is ready to rock on port 1985.
Segmentation fault: 11 (core dumped)
-=[~/SC/area]=- -=[Wed Jul 14]=- -=[22:31:44]=-
[root@ninja]#
15 Jul, 2010, woocifer wrote in the 12th comment:
Votes: 0
Not really sure where to go from here


GNU gdb 6.1.1 [FreeBSD]
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-marcel-freebsd"…
Core was generated by `chaosium'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5…done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libcrypt.so.4…done.
Loaded symbols for /lib/libcrypt.so.4
Reading symbols from /lib/libc.so.7…done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1…done.
Loaded symbols for /libexec/ld-elf.so.1
#0 write_to_buffer (d=0xe8000003, txt=0xbfbf6834 "Mob Factory Storage Area",
length=24) at comm.c:1758
1758 if ( d->outtop == 0 && !d->fcommand )
(gdb) list
1753 length = strlen(txt);
1754
1755 /*
1756 * Initial \n\r if needed.
1757 */
1758 if ( d->outtop == 0 && !d->fcommand )
1759 {
1760 d->outbuf[0] = '\n';
1761 d->outbuf[1] = '\r';
1762 d->outtop = 2;
(gdb) print d
$1 = (DESCRIPTOR_DATA *) 0xe8000003
(gdb) info args
d = (DESCRIPTOR_DATA *) 0xe8000003
txt = 0xbfbf6834 "Mob Factory Storage Area"
length = 24
(gdb) list write_to_buffer
1743
1744 /*
1745 * Append onto an output buffer.
1746 */
1747 void write_to_buffer( DESCRIPTOR_DATA *d, const char *txt, int length )
1748 {
1749 /*
1750 * Find length in case caller didn't.
1751 */
1752 if ( length <= 0 )
(gdb) info local
No locals.
(gdb) bt
#0 write_to_buffer (d=0xe8000003, txt=0xbfbf6834 "Mob Factory Storage Area",
length=24) at comm.c:1758
#1 0x0806f013 in send_to_char (txt=0xbfbfa85c "`BMob Factory Storage Area`n",
ch=0x2874006d) at comm.c:2680
#2 0x08054284 in do_look (ch=0x2874a1ec, argument=0x80bdc6a "auto")
at act_info.c:459
#3 0x0805baf3 in move_char (ch=0x2874a1ec, door=3) at act_move.c:260
#4 0x080bd5f6 in mobile_update () at update.c:313
#5 0x080bd784 in update_handler () at update.c:1872
#6 0x08073063 in game_loop_unix (control=4) at comm.c:794
#7 0x080734ba in main (argc=Cannot access memory at address 0x19
) at comm.c:416
(gdb) frame 1
#1 0x0806f013 in send_to_char (txt=0xbfbfa85c "`BMob Factory Storage Area`n",
ch=0x2874006d) at comm.c:2680
2680 write_to_buffer( ch->desc, ctxt, 0 );
(gdb) i args
txt = 0xbfbfa85c "`BMob Factory Storage Area`n"
ch = (CHAR_DATA *) 0x2874006d
(gdb) i locals
ctxt = "Mob Factory Storage Area", '\0' <repeats 6040 times>, <Edited for Length>
(gdb) print *ch
$2 = {next = 0x4c3e73, next_in_room = 0x0, master = 0x0, leader = 0x10000000,
fighting = 0x1000000e, reply = 0xe800000e, spec_fun = 0xe8000003,
pIndexData = 0xe8000003, desc = 0xe8000003, affected = 0x3, carrying = 0x0,
in_room = 0x23000000, was_in_room = 0x2c000000, pcdata = 0x8000000,
name = 0xc000000 <Address 0xc000000 out of bounds>,
short_descr = 0x100 <Address 0x100 out of bounds>, long_descr = 0x0,
description = 0xfff400 <Address 0xfff400 out of bounds>, prompt = 0x0,
sex = 0, class = 0, race = 0, level = 0, trust = 0, wizbit = 0 '\0',
played = -1006632960, logon = 2651134, save_time = 0, last_note = 0,
timer = 0, wait = 4096, hit = 2651136, max_hit = 0, mana = 2080374784,
max_mana = 2647052, move = 1962934272, max_move = -2027407212,
gold = -1691862892, exp = 1277704340, act = 86537217, affected_by = 0,
position = 0, practice = 256, carry_weight = 4128, carry_number = 3072,
saving_throw = 0, hitroll = 2816, damroll = 0, armor = 3840, wimpy = 0,
deaf = 0, mpact = 0x4000000, mpactnum = 134217728, totalexp = 134217728,
language = 0}
(gdb) set print pretty
(gdb) print *ch
$3 = {
next = 0x4c3e73,
next_in_room = 0x0,
master = 0x0,
leader = 0x10000000,
fighting = 0x1000000e,
reply = 0xe800000e,
spec_fun = 0xe8000003,
pIndexData = 0xe8000003,
desc = 0xe8000003,
affected = 0x3,
carrying = 0x0,
in_room = 0x23000000,
was_in_room = 0x2c000000,
pcdata = 0x8000000,
name = 0xc000000 <Address 0xc000000 out of bounds>,
short_descr = 0x100 <Address 0x100 out of bounds>,
long_descr = 0x0,
description = 0xfff400 <Address 0xfff400 out of bounds>,
prompt = 0x0,
sex = 0,
class = 0,
race = 0,
—Type <return> to continue, or q <return> to quit—q
Quit
(gdb) print *d
No symbol "d" in current context.
(gdb) i locals
ctxt = "Mob Factory Storage Area", '\0' <repeats 6040 times>, <Edited for Length>
(gdb) i args
txt = 0xbfbfa85c "`BMob Factory Storage Area`n"
ch = (CHAR_DATA *) 0x2874006d
(gdb) print *d
No symbol "d" in current context.
(gdb) i locals
ctxt = "Mob Factory Storage Area", '\0' <repeats 6040 times>, <Edited for length>
(gdb) print *ctxt
$4 = 77 'M'
(gdb) f
#1 0x0806f013 in send_to_char (txt=0xbfbfa85c "`BMob Factory Storage Area`n",
ch=0x2874006d) at comm.c:2680
2680 write_to_buffer( ch->desc, ctxt, 0 );
(gdb) list send_to_char
2662
2663 /*
2664 * Write to one char.
2665 */
2666 void send_to_char( const char *txt, CHAR_DATA *ch )
2667 {
2668 char ctxt[MAX_STRING_LENGTH];
2669 // char *ctxt;
2670
2671 if ( !IS_NPC(ch) )
(gdb) list
2672 colorize( ctxt, txt, ch->pcdata->ansi );
2673 else if ( ch->desc != NULL )
2674 colorize( ctxt, txt, TRUE );
2675 else
2676 colorize( ctxt, txt, FALSE );
2677
2678 if ( ctxt == NULL || ch->desc == NULL )
2679 return;
2680 write_to_buffer( ch->desc, ctxt, 0 );
2681
(gdb) list
2682 /*
2683 ch->desc->showstr_head = alloc_mem( strlen( ctxt ) + 1 );
2684 strcpy( ch->desc->showstr_head, ctxt );
2685 ch->desc->showstr_point = ch->desc->showstr_head;
2686 show_string( ch->desc, "" );
2687 */
2688
2689 }
2690
2691 /* OLC, new pager for editing long descriptions. */
(gdb) list
2692 /* ========================================================================= */
2693 /* - The heart of the pager. Thanks to N'Atas-Ha, ThePrincedom for porting */
2694 /* this SillyMud code for MERC 2.0 and laying down the groundwork. */
2695 /* - Thanks to Blackstar, hopper.cs.uiowa.edu 4000 for which the improvements*/
2696 /* to the pager was modeled from. - Kahn */
2697 /* - Safer, allows very large pagelen now, and allows to page while switched */
2698 /* Zavod of jcowan.reslife.okstate.edu 4000. */
2699 /* ========================================================================= */
2700
2701 void show_string( DESCRIPTOR_DATA *d, char *input )
(gdb) ptype DESCRIPTOR_DATA
type = struct descriptor_data {
DESCRIPTOR_DATA *next;
DESCRIPTOR_DATA *snoop_by;
CHAR_DATA *character;
CHAR_DATA *original;
char *host;
sh_int descriptor;
sh_int connected;
bool fcommand;
char inbuf[1280];
char incomm[320];
char inlast[320];
int repeat;
char *showstr_head;
char *showstr_point;
char *outbuf;
int outsize;
int outtop;
void *pEdit;
char **pString;
int editor;
int timer;
}
(gdb) ptype d
No symbol "d" in current context.
(gdb)


If it is a bad value being passed to the function in multiple areas, what would be the best way of fixing? Just going one by one looking for where it was called?
Not really sure where to go from here, any advice would be greatly appreciated. I'm not amazing at C yet, a nudge in the right direction would be mucho appreciated! Thank you all so much for the continued help!
15 Jul, 2010, David Haley wrote in the 13th comment:
Votes: 0
It looks like a mob has a descriptor somehow when it shouldn't. Make sure that descriptors are being properly initialized to null.
15 Jul, 2010, woocifer wrote in the 14th comment:
Votes: 0
2666 void send_to_char( const char *txt, CHAR_DATA *ch )
2667 {
2668 char ctxt[MAX_STRING_LENGTH];
2669 // char *ctxt;
2670
2671 if ( !IS_NPC(ch) )
2672 colorize( ctxt, txt, ch->pcdata->ansi );
2673 else if ( ch->desc != NULL )
2674 colorize( ctxt, txt, TRUE );
2675 else
2676 colorize( ctxt, txt, FALSE );
2677
2678 if ( ctxt == NULL || ch->desc == NULL )
2679 return;
2680 write_to_buffer( ch->desc, ctxt, 0 );
2681
2682 /*
2683 ch->desc->showstr_head = alloc_mem( strlen( ctxt ) + 1 );
2684 strcpy( ch->desc->showstr_head, ctxt );
2685 ch->desc->showstr_point = ch->desc->showstr_head;
2686 show_string( ch->desc, "" );
2687 */
2688
2689 }
2690



Does that not take care of the null initializations for the descriptor?


in the global variables I am seeing

277 /*
278 * Global variables.
279 */
280 DESCRIPTOR_DATA * descriptor_free; /* Free list for descriptors */
281 DESCRIPTOR_DATA * descriptor_list; /* All open descriptors */
282 DESCRIPTOR_DATA * d_next; /* Next descriptor in loop */



I think I am a little lost in your reply, do you think you could dumb it down a bit? I'm not seeing the buffer overflow being caused by a mob having a descriptor when it shouldnt via lines 2678-2680.
15 Jul, 2010, David Haley wrote in the 15th comment:
Votes: 0
Quote
Does that not take care of the null initializations for the descriptor?

That says that if a descriptor is null, the code will stop. But that doesn't make sure that the descriptor is in fact null. When you have something like this:

int i;

i is uninitialized meaning that its contents are (basically) random. So the list of descriptors you have – descriptor_free, descriptor_list, d_next – those are all uninitialized meaning that if the code doesn't initialize them it will try to loop over bogus data and therefore crash.

If you have valgrind on your system, you can get a clearer idea of what's going on: just run your game normally (without the startup script) with 'valgrind' in front. This can even tell you which variable declared at which line was uninitialized. The problem with valgrind is that the output can be slightly overwhelming sometimes.
15 Jul, 2010, ralgith wrote in the 16th comment:
Votes: 0
Yeah, thats definitely a problem with Valgrind, I was using it last night to find a memory leak caused by a missing free()… and it spit out a LOT for that one single missing free()
0.0/16