C++代码崩溃并显示“free():下一个大小无效”

发布于 2024-12-15 14:26:29 字数 1331 浏览 3 评论 0原文

我编写了一个小程序,它使用函数指针进行一些数值计算。

double polynom(const int j, const double xi) {
  return pow(xi, j);
}

/**
 * Calculate the legendre_polynom l_end on a certain position xi.
 */
double legendre_polynom(const int l_end, const double xi) {
  vector <double> p_l(l_end+1);
  p_l[0] = 1.0;
  p_l[1] = xi;

  for (int x = 2; x <= l_end; x++) {
    // p_l = ((2x-1) * p_{x-1} - (x-1) * p_{x-2}) / l
    p_l[x] = ((2 * x - 1) * p_l[x - 1] - (x - 1) * p_l[x - 2]) / x;
  }

  double result = p_l[l_end];
  return result;
}

程序因异常 free() 错误而崩溃。如果我将函数指针更改为第一个函数(多项式),它可以正常工作,但会因 legendre_polynom 而失败。

我已经调试了那么远,它在退出该函数之后和其他代码继续之前就中断了。

*** glibc detected *** blub: free(): invalid next size (fast): 0x0804f248 ***
======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xb7d70bc2]
/lib/i386-linux-gnu/libc.so.6(+0x6f862)[0xb7d71862]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xb7d7494d]

...

number2(_ZN9__gnu_cxx13new_allocatorIdE10deallocateEPdj+0x11)[0x804bc8b]
number2(_ZNSt12_Vector_baseIdSaIdEE13_M_deallocateEPdj+0x25)[0x804bbc3]
number2(_ZNSt12_Vector_baseIdSaIdEED1Ev+0x37)[0x804ba33]
number2(_ZNSt6vectorIdSaIdEED1Ev+0x38)[0x804b8a0]
number2(_Z16legendre_polynomid+0x13f)[0x804af9b]

所以我的问题是这里出了什么问题?

I have written a small program which uses function pointers to do some numerical calculations.

double polynom(const int j, const double xi) {
  return pow(xi, j);
}

/**
 * Calculate the legendre_polynom l_end on a certain position xi.
 */
double legendre_polynom(const int l_end, const double xi) {
  vector <double> p_l(l_end+1);
  p_l[0] = 1.0;
  p_l[1] = xi;

  for (int x = 2; x <= l_end; x++) {
    // p_l = ((2x-1) * p_{x-1} - (x-1) * p_{x-2}) / l
    p_l[x] = ((2 * x - 1) * p_l[x - 1] - (x - 1) * p_l[x - 2]) / x;
  }

  double result = p_l[l_end];
  return result;
}

The program crashes with an unusual free() error. If I change the function pointer to the first function (polynom) it works fine, but it fails with legendre_polynom.

I already debugged that far that it breaks right after exiting that function and before the other code continues.

*** glibc detected *** blub: free(): invalid next size (fast): 0x0804f248 ***
======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xb7d70bc2]
/lib/i386-linux-gnu/libc.so.6(+0x6f862)[0xb7d71862]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xb7d7494d]

...

number2(_ZN9__gnu_cxx13new_allocatorIdE10deallocateEPdj+0x11)[0x804bc8b]
number2(_ZNSt12_Vector_baseIdSaIdEE13_M_deallocateEPdj+0x25)[0x804bbc3]
number2(_ZNSt12_Vector_baseIdSaIdEED1Ev+0x37)[0x804ba33]
number2(_ZNSt6vectorIdSaIdEED1Ev+0x38)[0x804b8a0]
number2(_Z16legendre_polynomid+0x13f)[0x804af9b]

So my question is what is wrong here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

薔薇婲 2024-12-22 14:26:29

如果您始终使用 l_end >= 1 调用该函数,则该代码中没有错误。

l_end == 0时,p_l[1] = xi;中存在越界写入操作。

但请注意,您不能仅仅因为这是发生崩溃的地方,或者仅仅因为不调用该函数就没有崩溃就推断出这是有问题的函数。

错误就是错误,崩溃就是崩溃。它们在 C++ 中是完全不同的;你越早意识到这个重要事实越好。其他地方可能有错误,而这个函数可能只是受害者。

如果您看到崩溃,则说明存在错误。如果您没有看到崩溃,则说明您一无所知(错误可能仍然存在)。

There is no error in that code, provided that you always call that function with l_end >= 1.

When l_end == 0 instead there is an out of boundary write operation in p_l[1] = xi;.

Note however that you cannot infer that this is the function having the problem just because this is where you get a crash or just because not calling this function you have no crash.

An error is an error and a crash is a crash. They are completely distinct in C++; the sooner you realize this important fact the better. There may be an error somewhere else and this function may be just the victim.

If you see a crash then there is an error. If you see no crash you know nothing (the error may be still present).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文