c-奇怪的全局变量行为,一旦变量名称被更改,问题就消失了



在大学练习中,我遇到了一个变量的奇怪行为。

/* 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: %lfn", &sizeX) != 1) Debug("sizeX?",  1);
    if(fscanf(fp, "sizeY: %lfn", &sizeY) != 1) Debug("sizeY?",  1);
    if(fscanf(fp, "nPartX:%in", &nPartX) != 1) Debug("nPartX?", 1);
    if(fscanf(fp, "nPartY:%in", &nPartY) != 1) Debug("nPartY?", 1);
    if(fscanf(fp, "nCellX:%in", &nCellX) != 1) Debug("nCellX?", 1); //read value is 10
    if(fscanf(fp, "nCellY:%in", &nCellY) != 1) Debug("nCellY?", 1);    
    if(fscanf(fp, "steps: %lin", &steps) != 1) Debug("steps?",  1);    
//here the nCellX variable value 10 is changed somehow to 0
    if(fscanf(fp, "dt:    %lfn", &dt)    != 1) Debug("dt?",     1);
    if(fscanf(fp, "logs:  %cn",  &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;
}

老师和我得出的结论是,如果我们将变量名从"nCellX"更改为"nCellX_2",问题就会消失,代码也会按预期工作。另一件有趣的事情是,只有这个全局变量有这个问题,其他变量都能正常工作。我想知道有没有人也遇到过这种类型的问题。任何指导方针/解释都将不胜感激。

如果这个问题还不够清楚,请告诉我,如果需要完整的代码,我也可以提供。通常,该代码是"细胞中粒子"的并行算法。

可能是以下代码行导致了问题:

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

%li指示可能是64位的长整数,而steps是可能是32位的int。格式说明符应为%i,而不是%li

是否存在实际问题取决于环境(例如,如果构建64位应用程序,这很可能是一个问题)。如果64位与32位不匹配,那么fscanf调用将覆盖内存,并可能破坏内存布局中steps后面的任何变量(可能是nCellX)。请注意,使用-Wall选项应该会警告您这种情况。为什么将nCellX的名称更改为不同的名称会掩盖这个问题尚不清楚,但似乎更改名称可能会导致内存中变量布局的变化;我怀疑这是C标准不允许的(尽管我没有看)。

作为对@Mark Wilkins&公司。我想展示一下这个名字明确地说可以产生效果。

关于案例:
fprintf()获取一个指针,用于存储读取的内容。它不知道它指向的类型,但从格式中获取定义并强制转换论点类似sscanf("36", "%i", &my_dest);->number = va_arg(vl, int*);

为编译器使用正确的标志来捕获此


exec启动程序时,通常会为未初始化的程序分配地址数据(即int foo;)。(见图1)。

在许多系统上,这将是从低内存地址开始的。

为了证明(在给定系统上)会发生什么,我们有以下内容:

我从以下内容开始:

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

列表1

main()中,我说:

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';

列表2

并将一个无符号的char指针指向unA,并转储以下16个字节结果:
转储的格式为[char<dot>],或带前导零的十六进制(%c.或%02x)*

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

列表3

然后我将unB的名称更改为un2,与文件中的顺序相同:

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

列表4

现在我的转储给出:

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

列表5

正如人们所看到的,地址/对齐的顺序已经改变。类型没有变化,只有名称。


分配错误的类型:

下一步是强制转换并溢出某个类型的范围。将un2更改回unB。我们的对齐方式如列表3中所示。

我们创建了一个函数来设置字节(在具有4字节/32bit int的系统上),高阶为:

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 */
}

列表6

main()中,我们说:

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

列表7

获得:

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

列表8

或者:

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

列表9

正如人们所看到的,数据是重写的,无论类型和不类型如何。

在某些情况下,这将导致SIGSEGV。


对于您的代码中的问题,如前面的评论所述,但我重复一遍。

在声明中说int steps,在fscanf()中指定%li其是CCD_ 23而不是CCD_。在quie上,这可能有几个系统影响不大,但在64位系统上,一切都很糟糕。

通过asm:进行检查

我们复制代码并制作两份,一份带有long int steps;,另一份带有CCD_ 26命名为A:lin_ok.cB.lin_bad.c。然后我们创建一些asm输出。

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
...

如图所示,代码指示在64位上保留8个字节,在32位上保留4个字节(该系统)用于CCD_ 29。


如果使用gcc,请使用更多标志进行编译。我个人使用,通常:

gcc-Wall-Wextra-pedantic-std=c89-o main main.c或者如果需要CCD_ 30。

这将为您提供有关scanf中键入错误等问题的警告。


正在运行的应用程序的布局示例。它可以完全不同,取决于系统等,但是一个质子AFAIK。希望我已经大部分都是对的。

 ________________                       _________________
[                ]                     [                 ]
[                ]                     [ 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

图1。

相关内容

  • 没有找到相关文章

最新更新