1

During my university exercise I have come across strange behaviour of a variable.

/* Main parameters                                                          */
double sizeX, sizeY;      /* Size of the global domain                      */
int nPartX, nPartY;       /* Particle number in x, y direction              */
int nPart;                /* Total number of particles                      */
int nCellX, nCellY;       /* (Global) number of cells in x, y direction     */
int steps;                /* Number of timesteps                            */
double dt;                /* Stepsize for timesteps                         */
int logs;                 /* Whether or not we want to keep logfiles        */

void ReadInput(const char *fname)
{
  FILE *fp;
  char c;

  Debug("ReadInput", 0);
  if(rank == 0)
  {
    fp = fopen(fname, "r");
    if(!fp) Debug("Cannot open input file", 1);
    if(fscanf(fp, "sizeX: %lf\n", &sizeX) != 1) Debug("sizeX?",  1);
    if(fscanf(fp, "sizeY: %lf\n", &sizeY) != 1) Debug("sizeY?",  1);
    if(fscanf(fp, "nPartX:%i\n", &nPartX) != 1) Debug("nPartX?", 1);
    if(fscanf(fp, "nPartY:%i\n", &nPartY) != 1) Debug("nPartY?", 1);
    if(fscanf(fp, "nCellX:%i\n", &nCellX) != 1) Debug("nCellX?", 1); //read value is 10
    if(fscanf(fp, "nCellY:%i\n", &nCellY) != 1) Debug("nCellY?", 1);    
    if(fscanf(fp, "steps: %li\n", &steps) != 1) Debug("steps?",  1);    
//here the nCellX variable value 10 is changed somehow to 0
    if(fscanf(fp, "dt:    %lf\n", &dt)    != 1) Debug("dt?",     1);
    if(fscanf(fp, "logs:  %c\n",  &c)     != 1) Debug("logs?",   1);
    logs = (c == 'y');
    fclose(fp);
  }

  printf("(%i) reporting in...\n", rank);

  MPI_Bcast(&sizeX, 1, MPI_DOUBLE, 0, grid_comm);  
  MPI_Bcast(&sizeY, 1, MPI_DOUBLE, 0, grid_comm);
  MPI_Bcast(&nPartX,1, MPI_INT,    0, grid_comm);  
  MPI_Bcast(&nPartY,1, MPI_INT,    0, grid_comm);
  MPI_Bcast(&nCellX,1, MPI_INT,    0, grid_comm);
  MPI_Bcast(&nCellY,1, MPI_INT,    0, grid_comm);
  MPI_Bcast(&steps, 1, MPI_INT,    0, grid_comm);
  MPI_Bcast(&dt,    1, MPI_DOUBLE, 0, grid_comm);
  MPI_Bcast(&logs,  1, MPI_INT,    0, grid_comm);
  nPart = nPartX * nPartY;
  dt2 = dt * dt;
}

Teacher and I have concluded that if we change the variable name from "nCellX" to "nCellX_2", the problem disappears and the code works as expected. Another interesting thing is that only this single global variable have this problem, other variables works correctly. I was wondering does anyone came across this type of problem as well. Any guideline/explanation would be appreciated.

If this problem is not clear enough let me know, also if full code is required I can provide that as well. In general the code is a parallel algorithm of a Particle-in-Cell.

talonmies
  • 70,661
  • 34
  • 192
  • 269
alien01
  • 1,334
  • 2
  • 14
  • 31
  • 1
    Is your program multi-threaded? And what is the code for `DEBUG`? – Shahbaz Mar 23 '12 at 13:30
  • 2
    Are you getting any compiler warnings? Try compiling with `-Wall -Wextra -pedantic` and see if you get anything. – Collin Mar 23 '12 at 13:31
  • Also, try defining `nCellX` by setting it equal to some initial value. If that name has been initialized before (say, in MPI somewhere) that would cause an error – Collin Mar 23 '12 at 13:45

2 Answers2

5

It is possible that the following line of code is causing a problem:

if(fscanf(fp, "steps: %li\n", &steps) != 1) Debug("steps?",  1);

The %li indicates a long integer, which might be 64-bits while steps is an int, which might be 32-bits. The format specifier should be %i instead of %li.

Whether there is an actual problem depends on the environment (e.g., it is most likely an issue if building a 64-bit application). If there is that 64-bit vs 32-bit mismatch, then the fscanf call will overwrite memory and possibly destroy whatever variable follows steps in the memory layout (and that could be nCellX). Note that using -Wall option should warn you about this situation. Why changing the name of nCellX to something different should mask the problem is not clear, but it would seem that changing the names may be resulting in a change in the layout of the variables in memory; I doubt that is disallowed by the C standard (although I have not looked).

Mark Wilkins
  • 40,729
  • 5
  • 57
  • 110
  • That can't explain why changing the name `nCellX` to `nCellX_2` could fix the problem. – Shahbaz Mar 23 '12 at 14:21
  • 2
    @Shahbaz, yes it can. If there is a type mismatch that is "undefined behavior", anything can happen, even that. – Jens Gustedt Mar 23 '12 at 14:29
  • "anything can happen", but the compilers are deterministic. In theory yes, anything can happen, but in practice with the same compiler, same code, except one variable name change, the output is "the same anything", whatever that anything may be. – Shahbaz Mar 23 '12 at 14:39
  • In this particular case, if `%li` was causing the variable before `steps` being overwritten, it wouldn't have mattered what the name of that variable is. – Shahbaz Mar 23 '12 at 14:40
  • 1
    @Shahbaz: changing a variable name can change where in the symbol table it appears and where it is located in memory relative to the buffer overflow. It could easily explain the behaviour reported. – talonmies Mar 23 '12 at 14:44
  • @Shahbaz: And another possibility is that perhaps the OP did not simply rename the variable in place. He may have commented out the line and added the new declaration in a different place in the file; it seems unlikely but he didn't actually say. I think this is less likely than the compiler changing the layout but certainly a possibility. – Mark Wilkins Mar 23 '12 at 14:58
  • Sorry to reply so late. Solution proposed by Mark Wilkins have solved the problem. Thank you all for your help. – alien01 Mar 24 '12 at 20:36
  • @Shahbaz, as I demonstrate below, this is not as far fetched. The behavior is undefined and can easily explain why. – Morpfh Mar 25 '12 at 10:32
2

As an confirmation to the comment by @Mark Wilkins & Co. I'm trying to show that naming defineitively can have an effect.

On the case:
fprintf() takes a pointer where it stores what it read. It does not know the type it points to, but take the definition from the format and cast the argument. Something like sscanf("36", "%i", &my_dest); -> number = va_arg(vl, int*);

Use correct flags for you compiler to catch this

When exec starts up a program it typically assign addresses for uninitialized data (ie int foo;) in a region known as BSS. (See Fig. 1 down below for a figure).

On many systems this would be from a low memory address and up.

To demonstrate what happens (on a given system) we have as follows:

I start out with the following:

/* global scope */
unsigned char unA;
unsigned char unB;
unsigned char unC;
unsigned int  unD;

List 1

In main() I say:

unA = '1';
unB = '2';
unC = '3';
/* bit shifting the "string" NAC! into unD, reverse order as my system is LSB 
 * first (little-endian), unD becomes 558055758 => by byte ASCII !CNA */
unD = 0 | ('!' << 24) | ('C' << 16) | ('A' << 8) | 'N';

List 2

And point a unsigned char pointer to unA and dumps the following 16 bytes which result in:
Dumps are in format [char<dot>], or hex with leading zero (%c. or %02x)*

 +-- Address of unA
 |
0x804b06c: 1.3.0000N.A.C.!. 2.00000000000000 
           | |     |_____|  |
           | |        |     +--- unB
           | |        +--------- unD
           | +------------------ unC
           +-------------------- unA

List 3

Then I change name of unB to un2, same order in file:

unsigned char unA;
unsigned char un2;
unsigned char unC;
unsigned int  unD;

List 4

Now my dump gives:

 +-- Address of unA
 |
0x804b06c: 1.3.2.00N.A.C.!. 0000000000000000
           | | |   |_____|  
           | | |      +--------- unD
           | | +---------------- unB
           | +------------------ unC
           +-------------------- unA

List 5

As one can see the order of the addresses / alignment has been changed. No change in type, only in name.

Assigning wrong type:

Next step is then to cast and overflow range of a type. Change un2 back to unB. We have alignment as in List 3.

We create a function that set the bytes (on a system with 4 byte/32bit int), high order as:

void set_what(unsigned int *n)
{
    *n = 0 | ('t' << 24) | ('a' << 16) | ('h' << 8) | 'w';
    /* or *n = 0x74616877; in an ASCII environment 
     * 0x74 0x61 0x68 0x77 == tahw */
}

List 6

In main() we say:

/* dump */
set_what((unsigned int*)&unA);
/* dump */

List 7

And get:

0x804b06c: 1.3.0000N.A.C.!. 2.00000000000000
0x804b06c: w.h.a.t.N.A.C.!. 2.00000000000000

List 8

Or:

set_what((unsigned int*)&unB); -> Yield:
0x804b06c: 1.3.0000N.A.C.!. 2.00000000000000
0x804b06c: 1.3.0000N.A.C.!. w.h.a.t.00000000

set_what((unsigned int*)&unC); -> Yield:
0x804b06c: 1.3.0000N.A.C.!. 2.00000000000000
0x804b06c: 1.w.h.a.t.A.C.!. 2.00000000000000

List 9

As one can see data is over written, regardless of type and what not.

Under some conditions this would result in SIGSEGV.

To the problems in your code, as stated in earlier comment, but I repeat it.

In the declarations you say int steps and in fscanf() you specify %li which is a long int and not an int. On quie a few systems this could have little effect, but on a 64bit system everything goes bad.

Check by asm:

We copy the code and make two copies, one with long int steps; and one with int steps; named A: lin_ok.c and B: lin_bad.c. Then we create some asm output.

A $ cpp lin_ok.c > lin_ok_m32.i
A $ cpp lin_ok.c > lin_ok_m64.i
B $ cpp lin_bad.c > lin_bad_m32.i
B $ cpp lin_bad.c > lin_bad_m64.i

A $ gcc -std=c89 -m32 -S lin_ok_m32.i
A $ gcc -std=c89 -m64 -S lin_ok_m64.i
B $ gcc -std=c89 -m32 -S lin_bad_m32.i
B $ gcc -std=c89 -m64 -S lin_bad_m64.i


$ diff lin_ok_m32.s lin_ok_m64.s | head
9c9
<   .comm   steps,4,4   ; reserve 4 bytes
---
>   .comm   steps,8,8   ; reserve 8 bytes
...

As one can see the code instructs to reserve 8 bytes on 64 bit and 4 on 32 bit (this system) for steps.

If you use gcc, compile with more flags. Personally I use, typically:

gcc -Wall- Wextra -pedantic -std=c89 -o main main.c or -std=c99 if in need.

This will give you warnings on such problems as wrong type in scanf.

An example of layout of a running application. It can be completely different, depending on system, etc, but is an aprox AFAIK. Hopefully I've gotten most of it right.

 ________________                       _________________
[                ]                     [                 ]
[                ]                     [ Physical memory ]
[ Virtual memory ] <-- Translation --> [                 ]
[     range      ]        table        { - - - - - - - - }
[________________]                     [                 ]
    |                                  [_________________]
    |
 +--+ high address : Virtual address
 |
0xF00 +-------------------+'''''''''''''''''' Runnning env
      | argv, env-vars, ..|                              |
0xBFF +-------------------+                              | ptr
      |       stack       | <- Running storage, where    |
      |...  grows down ...|  fun_a should return, local  | 0xC0000000 on
      |                   |  variables, env, ...         | linux Intel x86
      |  < huge area  >   |  New frame allocated for     |
      |                   |  recursive calls etc.        |
      |...   grows up  ...|                              |     
      |                   | <- Dynamic memory alloc.     |
      |       heap        |  malloc, etc                 |
0x9e49+-------------------+                              | 
      | double sizeX;     | <- Uninitialized data        |
bss   | ...               |           BSS 000000 ...     |
seg.  | int nCellY        |                              |
      | int steps;        |                              |
0x804c+-------------------+''''''''''''''''''''' Stored '| --- edata
data  |                   |                        on    |
seg.  | int rank = 0;     | <- Initialized data   disk   |
0x804b+-------------------+                         :    | --- etext
      | main()            |                         :    |
text  | mov ecx, edx      | <- Instructions         :    | 0x08048000 on
seg.  | ELF, or the like  |   Layout, link, etc     :    | linux Intel x86
0x8040+-------------------+ ''''''''''''''''''''''''''''''
 |
 +--- low address : Virtual address

Fig 1.

Morpfh
  • 4,033
  • 18
  • 26
  • Wow that is one comprehensive explanation. Thank you a lot, both for the effort and the explanation. – alien01 Mar 25 '12 at 19:54