Memory bug somewhere

Memory bug somewhere

[David Eduardo Gomez Noguera]

Hello.

I have been having a program crash in this function.
It basically recives a pointer to a structure 

typedef struct hufftree {
  HuffCode code;
  struct hufftree *l;
  struct hufftree *r;
}hufftree;

a code, a size (of the code) and a data asigned to that huffman code.

This function inserts the data at the end of the path marked by the code
and the size of the code.

It segfaults after some asignments (some calls to ins_code), always at
the same point.

Can anybody here see what is wrong with this?

compilation like is just 

gcc -g -lm file.c -o file

and its glibc-2.3.2-4.80 (know if there is any issue with malloc there?)

-------------------------CUT HERE-----------------------------

int
ins_code (hufftree * tree, unsigned short code, unsigned char size,
	  unsigned char dato)
{
	hufftree *tree2;
	unsigned short i, k;

	tree2 = tree;

	for (i = size; i > 0; i--)
	{

		if (code & ((unsigned short) 1 << (i - 1)))
		{
			if (tree2->l == NULL)
			{
				printf ("before\n");
				tree2->l = malloc (sizeof (hufftree));
				printf ("after\n");
				tree2->l->l = NULL;
				tree2->l->r = NULL;
			}
			tree2 = tree2->l;
		}
		else
		{
			if (tree2->r == NULL)
			{
				printf ("before\n");
				tree2->r = malloc (sizeof (hufftree));
				printf ("after\n");
				tree2->r->l = NULL;
				tree2->r->r = NULL;
			}
			tree2 = tree2->r;
		}
	}
	tree2->code.used = dato;
	tree2->code.code = code;
	return 0;
}
----------------------CUT HERE------------------------------

Re: Memory bug somewhere

[Glynn Clements]

David Eduardo Gomez Noguera wrote:

> I have been having a program crash in this function.
> It basically recives a pointer to a structure 
> 
> typedef struct hufftree {
>   HuffCode code;
>   struct hufftree *l;
>   struct hufftree *r;
> }hufftree;
> 
> a code, a size (of the code) and a data asigned to that huffman code.
> 
> This function inserts the data at the end of the path marked by the code
> and the size of the code.
> 
> It segfaults after some asignments (some calls to ins_code), always at
> the same point.
> 
> Can anybody here see what is wrong with this?

I can't see any errors here. However, if you corrupt the heap, you
normally get a segfault during some subsequent call to malloc/free,
not at the point that the corruption occurs.

One option is to use mcheck(), e.g. by linking against libmcheck. This
is mentioned in the libc Info file.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: Memory bug somewhere

[David Eduardo Gomez Noguera]

On Sat, 2003-05-24 at 13:08, Glynn Clements wrote:
> David Eduardo Gomez Noguera wrote:
> 
> > I have been having a program crash in this function.
> > It basically recives a pointer to a structure 
> > 
> > typedef struct hufftree {
> >   HuffCode code;
> >   struct hufftree *l;
> >   struct hufftree *r;
> > }hufftree;
> > 
> > a code, a size (of the code) and a data asigned to that huffman code.
> > 
> > This function inserts the data at the end of the path marked by the code
> > and the size of the code.
> > 
> > It segfaults after some asignments (some calls to ins_code), always at
> > the same point.
> > 
> > Can anybody here see what is wrong with this?
> 
> I can't see any errors here. However, if you corrupt the heap, you
> normally get a segfault during some subsequent call to malloc/free,
> not at the point that the corruption occurs.
> 
> One option is to use mcheck(), e.g. by linking against libmcheck. This
> is mentioned in the libc Info file.

Thank you. I have just tried that, with the result that it went very
slow, and seemed to swap all memory (because after the program ends,
with the message "Killed", the output for free mem from `free` is all
the memory)
I called mcheck at the megening of main, with a NULL argument.

on other side, after reading a bit, I tried with 
MALLOC_CHECK_ set to 1, but it dropped me only one message at the
beginig of all the output:

malloc: using debugging hooks
malloc: top chunk is corrupt
./sagem

I think that is before I use malloc even once.

have read a bit, but I think its not related to my problem.
With the printf statemens, I found the segfault was in the malloc call,
gdb's backtrace says that too:

Program received signal SIGSEGV, Segmentation fault.
0x400b682e in _int_malloc () from /lib/libc.so.6
(gdb) backtrace
#0  0x400b682e in _int_malloc () from /lib/libc.so.6
#1  0x400b5830 in malloc () from /lib/libc.so.6
#2  0x400b9aac in mallochook () from /lib/libc.so.6
#3  0x400b57cc in malloc () from /lib/libc.so.6
#4  0x08049c36 in ins_code (tree=0x804c3d0, code=78, size=7 '\a',
dato=161 '?')
    at sagem.c:532
#5  0x08049ae1 in hs (hf=0xbfffdca0) at sagem.c:469
#6  0x08049618 in main (argc=2, argv=0xbfffde74) at sagem.c:258
#7  0x4005e5cd in __libc_start_main () from /lib/libc.so.6

Why I think it might be a problem with glibc is because it doesnt
segfaults on a mandrake 9.1, but it does crash on rh 8 and 9.

how could I be corrupting the heap if that is the problem?

Re: Memory bug somewhere

[Glynn Clements]

David Eduardo Gomez Noguera wrote:

> have read a bit, but I think its not related to my problem.
> With the printf statemens, I found the segfault was in the malloc call,
> gdb's backtrace says that too:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x400b682e in _int_malloc () from /lib/libc.so.6
> (gdb) backtrace
> #0  0x400b682e in _int_malloc () from /lib/libc.so.6
> #1  0x400b5830 in malloc () from /lib/libc.so.6
> #2  0x400b9aac in mallochook () from /lib/libc.so.6
> #3  0x400b57cc in malloc () from /lib/libc.so.6
> #4  0x08049c36 in ins_code (tree=0x804c3d0, code=78, size=7 '\a',
> dato=161 '?')
>     at sagem.c:532
> #5  0x08049ae1 in hs (hf=0xbfffdca0) at sagem.c:469
> #6  0x08049618 in main (argc=2, argv=0xbfffde74) at sagem.c:258
> #7  0x4005e5cd in __libc_start_main () from /lib/libc.so.6

This backtrace (segfault inside malloc) is typical for heap
corruption.

> Why I think it might be a problem with glibc is because it doesnt
> segfaults on a mandrake 9.1, but it does crash on rh 8 and 9.

Corrupting the heap isn't guaranteed to cause a segfault, it just
makes it likely. This is what the term "undefined behaviour" means;
maybe your program will crash, maybe it will just behave incorrectly,
maybe it will actually work.

> how could I be corrupting the heap if that is the problem?

You can't tell you how you're corrupting the heap by looking at a
backtrace. If a segfault occurs, it will occur within a subsequent
call to malloc/free, not at the point in your program where the bug
is.

To locate the bug, you can either manually inspect your code, or use
dedicated memory debugging tools such as Bounds Checker or Electric
Fence.

-- 
Glynn Clements <glynn.clements@virgin.net>