List of lists - memory overwritten (I think)

Hi all,

I use a network simulator based around C. In one of my C files I have a global linked list (called obstacle_list saved in a header file) which contains smaller lists (not global). In another C file at another point I try to access this global linked list. I can see it hold 380 items but when I try to access the inner linked lists, they’re empty.

It must be a memory allocation oversight when I am populating the lists first day (as I read them back at the time to check and all seems fine).

Does anyone have any advice based on the below code?

Many thanks.

Code:

fgets(line, sizeof(line), obstaclePositions_traj_file);
	
obstacle_list = op_prg_list_create();
tg = 0;
	
while ((line != OPC_NIL) && (chk <380))
{
	//read the first \t into id, read the remaining into a global obstacle list
	token = strtok(line, "\t\n"); //Pull the string apart into tokens using the commas
	input = op_prg_list_create();
		
	while (token != NULL)
         {
          	  test_token = strdup(token);
			
	if (op_prg_list_size(input) == 0)
		op_prg_list_insert(input,test_token,OPC_LISTPOS_HEAD);
	else
		op_prg_list_insert(input,test_token,OPC_LISTPOS_TAIL);
		token = strtok (NULL, "\t\n");
          }		
	
           if (op_prg_list_size(obstacle_list) == 0)
		op_prg_list_insert(obstacle_list,input,OPC_LISTPOS_HEAD);
	else
		op_prg_list_insert(obstacle_list,input,OPC_LISTPOS_TAIL);
		
		
			
		chk = chk + 1;
		
		if (chk == 375)
			printf ("check here");
		
		if (chk <= 379)
			fgets(line, sizeof(line), obstaclePositions_traj_file);		
		
	}
 
	
	//check the list has been populated correctly below
	
	/*size_ob_list = op_prg_list_size (obstacle_list);
	for (k = 0; k <size_ob_list; k++)
	{
		line_coord_list = (List*)op_prg_list_access (obstacle_list, k);		
		count_inner_list = op_prg_list_size (line_coord_list);
		for (j=0; j< count_inner_list; j++)
		{
			coords = (char*)op_prg_list_access (line_coord_list, j);
			printf("%c", coords);		
		}
	}*/
				
	FOUT;
}

> Does anyone have any advice based on the below code?
Posting random bits of code where you think the problem is is seldom worthwhile.

Memory corruption issues are mostly caused by problems in one area of the code (cause) showing up in another area of the code (effect).
So posting a random bit of code somewhere close to the effect point is not going to be worthwhile.

To even begin to give anyone else a chance to find the problem, you would need to post something which can be compiled, along with all your test data and input instructions.

Also, which OS/Compiler are you using?

Here's an example.
How many bugs can you see?

Code:

$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char *foo ( void ) {
  return malloc(5);
}
char *bar ( char *p ) {
  strcpy(p,"world");
  return p;
}

int main ( ) {
  printf("%s\n", bar(foo()) );
  return 0;
}
$ gcc -Wall foo.c
$ ./a.out 
world

Now consider this.

Code:

$ valgrind ./a.out
==3266== Memcheck, a memory error detector
==3266== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3266== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==3266== Command: ./a.out
==3266== 
==3266== Invalid write of size 2
==3266==    at 0x40056D: bar (in /home/sc/Documents/a.out)
==3266==    by 0x400587: main (in /home/sc/Documents/a.out)
==3266==  Address 0x51d2044 is 4 bytes inside a block of size 5 alloc'd
==3266==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==3266==    by 0x400551: foo (in /home/sc/Documents/a.out)
==3266==    by 0x40057F: main (in /home/sc/Documents/a.out)
==3266== 
==3266== Invalid read of size 1
==3266==    at 0x4C29741: __GI_strlen (mc_replace_strmem.c:284)
==3266==    by 0x4E9BFAB: puts (ioputs.c:37)
==3266==    by 0x40058F: main (in /home/sc/Documents/a.out)
==3266==  Address 0x51d2045 is 0 bytes after a block of size 5 alloc'd
==3266==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==3266==    by 0x400551: foo (in /home/sc/Documents/a.out)
==3266==    by 0x40057F: main (in /home/sc/Documents/a.out)
==3266== 
world
==3266== 
==3266== HEAP SUMMARY:
==3266==     in use at exit: 5 bytes in 1 blocks
==3266==   total heap usage: 1 allocs, 0 frees, 5 bytes allocated
==3266== 
==3266== LEAK SUMMARY:
==3266==    definitely lost: 5 bytes in 1 blocks
==3266==    indirectly lost: 0 bytes in 0 blocks
==3266==      possibly lost: 0 bytes in 0 blocks
==3266==    still reachable: 0 bytes in 0 blocks
==3266==         suppressed: 0 bytes in 0 blocks
==3266== Rerun with --leak-check=full to see details of leaked memory
==3266== 
==3266== For counts of detected and suppressed errors, rerun with: -v
==3266== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)

So which function is wrong?
foo, for not allocating enough memory to begin with
bar, for trying to use too much memory

You see, if you had posted either foo() or bar(), it wouldn't have told us the bigger picture.
Each is correct in an isolated context, but both are incompatible with one another when combined into a whole program.