Why the excecution result changes when i try the same code on linux ?

[engAmrnajjar]

I have a program (which is a university assignment) it does compile and run correctly on windows, but when i copy it an compile it on linux, it compiles and run successful but gives other results, i have been trying to figure out why for the last 10 hours and i could not ,

i have done debuging on Linux, and discovered that tere is an array of integer which values change automatically, i mean without any code that manipulaties the values,
(this unexpected change occurs only when i run on linux )
i have to deliver the assignment tommorow , it is urgent
anyone can help ?

[Ectara]

We need more information, such as a code snippet or output, to be able to help you.

[engAmrnajjar]

there is a problem

thanks
the problem is that because of debugging the code in no more readable

the exercise is Knapsack problem and i have coded brutal force algorithms and the result is an array of the item which we should put in the knapsack to achieve optimal solution
so on windows it gives the right array (which yeilds the optimal solution)
on linux it does not give the same array but a random array

[engAmrnajjar]

here is the code
but it need a text input file to be executed

[Ectara]

Can you provide a sample input file that is being used to test this?

And also, can you paste the output when executing this in Windows? I only run Linux on this machine.

[engAmrnajjar]

the final output of this file on windows is the array
1
0
0
1
1
1
1
1
1
1
so an item taken = 1
an item not taken = 0 ;
and here is an a simple input
and what i discovered is that there is a change in the value of the array checklist between lines
124
131

[Ectara]

Well, with the lack of the real input file, I took some liberties from what the code appears to do, and made a test file:

4
1 20 1
2 40 4
3 70 15
4 20 8
15

As you can see, with a max weight of 15, picking the first two and the last one would come out to more value than picking the third, or any other combination.

The output:
ectara@Nemesis: ~$ g++ /home/ectara/Desktop/code/temp/read_instance.c ; ./a.out test
n=4 W=15
item 1 has profit 20 and weigth 1
item 2 has profit 40 and weigth 4
item 3 has profit 70 and weigth 15
item 4 has profit 20 and weigth 8
heeeey1

4

15

8

this is checklist 0this is optList 0
this is checklist 0this is optList 0
this is checklist 0this is optList 0
this is checklist 0this is optList 0
this is CheckArray
1
1
0
1
this is the check item : 1 this is the opt Item : 0
this is the check item : 1 this is the opt Item : @@1
this is the check item : 1 this is the opt Item : 0
this is the check item : 1 this is the opt Item : @@1
this is the check item : 0 this is the opt Item : 0
this is the check item : 0 this is the opt Item : @@0
this is the check item : 1 this is the opt Item : 0
this is the check item : 1 this is the opt Item : @@1
this is the first Case
1
1
0
1
1
1
0
1


And so, my machine agrees, and states(several times) that it is logical to take the first two and the last(1) and leave the third one(0).

Despite not knowing much about what it is outputting, looks like it is working to me, assuming a 1-0-knapsack problem. Without the original test file, I can do no more than assure you that the code works on my machine, Linux 2.6.26-2-686.

[engAmrnajjar]

now i have discovered a new thing
first of all
the problem is that the program works well on visual studio
not with others even with windows (like Dev-C++)
i attached a code file in which i know the place where the problem happens but i do not know why
in line 131 for example the assignment

tempint= checklist[counter];
changes the last value of the array checklist(altho ugh it is in the left hand side of the assingment)
and here u have a real input file and the code
i really do not know why this error happens
the ouptfile is attached
and the input name is test.txt

[Ectara]

Oh, those were line numbers at the end of your last post.

Hm. That is strange. The program initially has the right answer, then changes to something completely wrong. I'll take a closer look at it right now.

[engAmrnajjar]

okay i,m waiting
and thank you sooo much

[Ectara]

FINALLY FOUND IT!

int main ( int argc, char** argv ) {
//BEGIN_MAIN
	unsigned int mainCounter ;
	unsigned int i ; 
	
	if ( argc != 2 ) {
		printf ("./read_instance instance_file\n");
		return 0 ;
	}
	checklist= (unsigned int*) malloc ( instance.n * sizeof(unsigned int) ) ;
	optlist= (unsigned int*) malloc ( instance.n * sizeof(unsigned int) ) ;
	
	read_instance ( argv[1], &instance ) ;
//BEGIN_EXPERIMENT

Anyone notice anything strange?

	checklist= (unsigned int*) malloc ( instance.n * sizeof(unsigned int) ) ;
	optlist= (unsigned int*) malloc ( instance.n * sizeof(unsigned int) ) ;
	
	read_instance ( argv[1], &instance ) ;

void read_instance (char* instance_file,instance_t* instance)

	{
		unsigned int j ;
		FILE* in ;
		in = fopen ( instance_file, "r" ) ;
		if ( in == NULL ) 
		{
			printf ( "error while opening file %s\n", instance_file ) ;
			return ;
		}
	
		
		fscanf ( in, "%d", &instance->n ) ;
		instance->w = (unsigned int*) malloc ( instance->n * sizeof(unsigned int) ) ;
		instance->p = (unsigned int*) malloc ( instance->n * sizeof(unsigned int) ) ;
		
		for ( j=0; j<instance->n ; ++j ) {
			int tmp ;
			fscanf ( in, "%d %d %d", &tmp, instance->p+j, instance->w+j ) ;
			if ( tmp != j+1 ) {
				printf("bad file format\n");	
				fclose ( in ) ;
				return ;
			}
		}
	fscanf ( in, "%d", &instance->W ) ;
	fclose ( in ) ;
	}

See it now? All this time we were looking in the recursive algorithm. But simply, you were allocating the arrays BEFORE initializing the variables holding the number of elements to allocate for. Allocated the arrays after reading the file, and everything works fine on my machine.

I have no idea how it worked in Windows.

[engAmrnajjar]

thank so much, i'm really thankful
that's a kind of bug i would have never discovered .
anyway talk to you tomorrow, bcoz now i have to go to sleep
thanks
Kindest Regards

[Ectara]

No problem at all. Glad to help. I've done things like that before. Good luck on your assignment.