1

我一直被这个问题随机困扰，我似乎无法弄清楚是什么原因造成的。

我有一个声明大量变量、指针和数组的函数。但是在某个时候，如果我声明一个新变量，我的程序似乎会崩溃。即使它确实崩溃了，它似乎也不一致。如果我的函数下面的代码，如果我将变量 b 声明为 int 它将使程序崩溃，但如果我将其声明为 int b[10] 它不会。

我为大量代码道歉，但我想提供整个功能以防我遗漏了什么。我指的变量 b 在顶部附近。

我怀疑这是某种内存问题，但我所看到的似乎并不一致。

static should_inline void decode_image_internal(PictureDecoderData* pdd, FILE* outfile)
{
  unsigned int mb_row;
  unsigned int mb_col;
  unsigned int mb_idx;
  unsigned int i;
  unsigned int j;
  unsigned int b[10];
  unsigned char topy[30720];
  unsigned char topcb[7680];
  unsigned char topcr[7680];

  Picture* pic = pdd->pic;
  unsigned int bottom_field_flag = pdd->prev_sh->bottom_field_flag; // TODO: remove the     use of prev_sh since it really depends on the pdd decoding context.
  slice_header_t* slice0 = pic->field_sh[bottom_field_flag][0]; // get a slice header.   It is used for variables that are the same for the whole picture
  seq_parameter_set_rbsp_t* sps = slice0->sps;
  pic_parameter_set_rbsp_t* pps = slice0->pps;
  int PicWidthInMbs = sps->PicWidthInMbs;
  unsigned int PicWidthY = PicWidthInMbs * 16;
  unsigned int PicHeightInMbs = slice0->PicHeightInMbs;
  unsigned int PicSizeInMbs = PicWidthInMbs*PicHeightInMbs;
  int CurrMbAddr;
  MbAttrib* mb_attr = pic->field_data[bottom_field_flag].mb_attr;
  MbAttrib* curr_mb_attr;
  unsigned int mbc_width = MbWidthC[1];
  unsigned int mbc_height = MbHeightC[1];
//  unsigned int mbc_size = mbc_width*mbc_height;
  unsigned int PicWidthC = PicWidthInMbs * mbc_width;
  int clipY = (1<<sps->BitDepthY)-1;
  int meanY = 1<<(sps->BitDepthY-1);
  int clipC = (1<<sps->BitDepthC)-1;
  int meanC = 1<<(sps->BitDepthC-1);
  int mb_data_size = (256+2*MbSizeC[1]);
  int16_t* mb_data = pic->field_data[bottom_field_flag].data;
  int16_t* curr_mb_data;
  unsigned int field_pic_flag = slice0->field_pic_flag;
  unsigned int strideY = PicWidthY << field_pic_flag;
  unsigned int strideC = PicWidthC << field_pic_flag;
  slice_header_t* sh;
  unsigned int constrained_intra_pred_flag = pps->constrained_intra_pred_flag;

  pixel_t* Y;
  pixel_t* C[2];
  pixel_t* y;
  pixel_t* c[2];

  Y = (pixel_t*)((uint32_t)pic->Y + (bottom_field_flag!=0)*PicWidthY);
  C[0] = (pixel_t*)((uint32_t)pic->C[0]+ (bottom_field_flag!=0)*PicWidthC);
  C[1] = (pixel_t*)((uint32_t)pic->C[1]+ (bottom_field_flag!=0)*PicWidthC);


  for (j = 0; j<=pic->slice_num[bottom_field_flag]; j++)
  {
    sh = pic->field_sh[bottom_field_flag][j];
    CurrMbAddr = sh->first_mb_in_slice;

    //for (i = 0; i<sh->mb_nb; i++)
     for (i = 0; i<2; i++)
    {
      pixel_t ysamp[256], cbsamp[8*8], crsamp[8*8];
      mb_row = (CurrMbAddr) / PicWidthInMbs;
      mb_col = (CurrMbAddr) % PicWidthInMbs;
      mb_idx = (CurrMbAddr);
      curr_mb_attr = &mb_attr[mb_idx];
      curr_mb_data = mb_data + mb_idx * mb_data_size;
     // printf(" %d %d \n ",strideY, mb_row);
      y = Y + mb_col*16 + mb_row*strideY*16;
      c[0] = C[0] + mb_col*mbc_width + mb_row*strideC*mbc_height;
      c[1] = C[1] + mb_col*mbc_width + mb_row*strideC*mbc_height;


        {
          MB_TYPE mb_type = curr_mb_attr->mb_type;
          unsigned int mb_field_decoding_flag = curr_mb_attr->mb_field_decoding_flag;
          pixel_t* mb_C_samples[2];

          mb_C_samples[0] = c[0];
          mb_C_samples[1] = c[1];


          //if (mb_type <= SI) // Intra mb
            decode_intra_mb(curr_mb_attr, mb_type, curr_mb_data, 1920, 960, y, mb_C_samples[0], mb_C_samples[1],
            ysamp, cbsamp, crsamp,
            mbc_height, mbc_width, clipY, clipC, meanY, meanC, mb_field_decoding_flag, mb_row&1, PicWidthInMbs, 0,
            constrained_intra_pred_flag);

            rgbconvert(ysamp, cbsamp, crsamp, outfile);


        }

      CurrMbAddr = NextMbAddress(sh->MbToSliceGroupMap, CurrMbAddr, PicSizeInMbs, pps->num_slice_groups_minus1);
    }

  }


  // Release the ref picture it was using
  release_picture_refpics(pic, bottom_field_flag); // it is OK even when the pic is a frame because both field points to the same lists

  filter_image(pic, bottom_field_flag);

  // Output the picture !
  add_image_to_dpb(pic);
}

任何指导将不胜感激！

编辑*感谢大家的回复！原来堆栈的损坏是正确的答案。我正在修复它的路上。

4

4 回答 4

2

在堆栈上分配太多的大数组是一个坏主意。堆栈不是为此而设计的，您很容易用完堆栈内存。更糟糕的是，很难控制和捕捉到这样的问题。

相反，您必须在堆上分配大量内存。那里有更多的内存（但不是无限的，当然！）

简而言之，更换

unsigned char topy[30720];

和

unsigned char* topy = (char*)malloc(30720);

必须要好得多，并且可能会消除您的问题。只是不要忘记在free(topy)不再需要时释放分配的内存 ( )。

UPD：当然，这些是一般推理，它们不适用于特殊情况（即嵌入式系统等）。

于 2013-02-22T10:13:34.043 回答
1

如果我将变量 b 声明为 int 它将使程序崩溃，但如果我将其声明为 int b[10] 它不会。

显而易见的原因是，使用后者，您将保留 10 倍的内存。但是，您似乎没有在b任何地方使用，因此几乎可以肯定您在其他地方超出了内存。不同之处在于保留额外的内存会阻止错误覆盖关键的东西（与程序仅在调试下工作时相同）。

麻烦的是这只是程序的一部分，实际错误可能在其他地方，因为您正在调用其他函数并使用传入的数据作为参数。

bottom_field_flag是一个明显的检查值。

你没有提到你得到什么类型的崩溃。这对于进一步推进该决议至关重要。例如，如果您遇到堆栈溢出，并且您在 Windows 上，那么您需要检查编译器中的堆栈大小设置（我认为 /F 和 Visual Studio 中的链接器选项）。

于 2013-02-22T10:23:49.733 回答
0

哪个操作系统？如果这是在Windows上，那么这很可能是由编译器插入的 chkstk 例程引起的，而没有询问它何时看到具有 >4k 局部变量的函数。如果您使用了 -nostdlib，那么这将失败。

于 2013-02-22T10:11:35.547 回答
0

Valgrind（由@nevelis 提出）是解决此类问题的好主意。

另一种选择是使用调试器 ( gdb )执行应用程序，等待崩溃并查看回溯。

在 gdb 中，命令是：

run

坠机后：

bt

我认为您还应该减少堆栈大小（自动变量）。堆栈上的 44K 似乎不是一个好主意。

于 2013-02-22T10:14:19.333 回答