llvm-gcc std:: 分配器错误?

发布于 2024-10-01 18:12:50 字数 595 浏览 1 评论 0原文

代码:

#include <vector>
#include <stack>
using namespace std;

class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};

int main()
{
  std::stack<int, intvec> s;
}

使用 g++ (4.4.3) 和 llvm-g++ (4.2.1) 进行编译,但后者的输出出现 seg 错误:

$ g++ main.cc && ./a.out
$ llvm-g++ main.cc && ./a.out
Segmentation fault

这似乎是释放未分配的内容的问题。这是 llvm-gcc 中的错误吗?

更新:根据 llvm 邮件列表上的讨论,看起来这是 llvm-gcc 或其 STL 实现中的一个错误,该错误已在较新版本中修复。然而,我并没有费心从他们的存储库中安装和构建 llvm-gcc 来找出答案。

The code:

#include <vector>
#include <stack>
using namespace std;

class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};

int main()
{
  std::stack<int, intvec> s;
}

compiles with both g++ (4.4.3) and llvm-g++ (4.2.1), but the output of the latter seg faults:

$ g++ main.cc && ./a.out
$ llvm-g++ main.cc && ./a.out
Segmentation fault

It appears to be an issue of freeing something that wasn't allocated. Is this a bug in llvm-gcc?

Update: Based on the discuss on the llvm mailing list, it looks like this is a bug, either in llvm-gcc or its implementation of the STL that has been fixed in newer versions. I haven't bother to install and build llvm-gcc from their repository to find out, however.

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

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

发布评论

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

评论(3

娇纵 2024-10-08 18:12:50

好的。所以我在 Ubuntu 10.10 x64 上运行了这个,我看到了分段错误。这是一些细节。总的来说,我的总结似乎是这是编译器中的一个错误。 (请注意,我不是最初的提问者,我只是能够重现他的结果)。

我还将此转发到 llvm 邮件列表,网址为 http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-11 月/036231.html< /a>


wlynch@green:/tmp$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
wlynch@green:/tmp$ llvm-g++ -O0 -g main.cc && ./a.out 
Segmentation fault
wlynch@green:/tmp$ llvm-g++ -O3 -g main.cc && ./a.out 
Segmentation fault

(gdb) bt
#0  0x00007ffff780aa75 in *__GI_raise (sig=<value optimized out>)                                                                at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff780e5c0 in *__GI_abort ()                                                                                         at abort.c:92
#2  0x00007ffff78444fb in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>)                             at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007ffff784e5b6 in malloc_printerr (action=3, str=0x7ffff791ead3 "free(): invalid pointer", ptr=<value optimized out>)    at malloc.c:6266
#4  0x00007ffff7854e83 in *__GI___libc_free (mem=<value optimized out>)                                                          at malloc.c:3738
#5  0x0000000000401476 in __gnu_cxx::new_allocator<int>::deallocate (this=0x7fffffffe5a8, __p=0x62c000, unnamed_arg=4)           at include/c++/4.2.1/ext/new_allocator.h:97
#6  0x00000000004014b1 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate (this=0x7fffffffe5a8, __p=0x62c000, __n=4) at include/c++/4.2.1/bits/stl_vector.h:146
#7  0x00000000004014fe in std::_Vector_base<int, std::allocator<int> >::~_Vector_base (this=0x7fffffffe5a8)                      at include/c++/4.2.1/bits/stl_vector.h:132
#8  0x00000000004017cf in std::vector<int, std::allocator<int> >::~vector (this=0x7fffffffe5a8)                                  at include/c++/4.2.1/bits/stl_vector.h:287
#9  0x0000000000401886 in intvec::~intvec (this=0x7fffffffe5a8)                                                                  at main.cc:6
#10 0x00000000004018a4 in std::stack<int, intvec>::~stack (this=0x7fffffffe5a8)                                                  at include/c++/4.2.1/bits/stl_stack.h:99
#11 0x0000000000400c01 in main ()                                                                                                at main.cc:10

我们还获得了无效指针的释放。从回溯来看这是有道理的。


wlynch@green:/tmp$ valgrind ./a.out 
==4644== Memcheck, a memory error detector
==4644== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4644== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4644== Command: ./a.out
==4644== 
==4644== Invalid free() / delete / delete[]
==4644==    at 0x4C270BD: free (vg_replace_malloc.c:366)
==4644==    by 0x401475: __gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long) (new_allocator.h:97)
==4644==    by 0x4014B0: std::_Vector_base<int, std::allocator<int> >::_M_deallocate(int*, unsigned long) (stl_vector.h:146)
==4644==    by 0x4014FD: std::_Vector_base<int, std::allocator<int> >::~_Vector_base() (stl_vector.h:132)
==4644==    by 0x4017CE: std::vector<int, std::allocator<int> >::~vector() (stl_vector.h:287)
==4644==    by 0x401885: intvec::~intvec() (main.cc:6)
==4644==    by 0x4018A3: std::stack<int, intvec>::~stack() (stl_stack.h:99)
==4644==    by 0x400C00: main (main.cc:10)
==4644==  Address 0x5433000 is not stack'd, malloc'd or (recently) free'd
==4644== 
==4644== 
==4644== HEAP SUMMARY:
==4644==     in use at exit: 1 bytes in 1 blocks
==4644==   total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==4644== 
==4644== LEAK SUMMARY:
==4644==    definitely lost: 1 bytes in 1 blocks
==4644==    indirectly lost: 0 bytes in 0 blocks
==4644==      possibly lost: 0 bytes in 0 blocks
==4644==    still reachable: 0 bytes in 0 blocks
==4644==         suppressed: 0 bytes in 0 blocks
==4644== Rerun with --leak-check=full to see details of leaked memory
==4644== 
==4644== For counts of detected and suppressed errors, rerun with: -v
==4644== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

我稍微减少了测试用例。我实际上倾向于认为这是 STL 实现错误,而不是编译器错误。

#include <vector>

class blub {};
class intvec : public std::vector<int>, public blub {};

int main() {
    intvec d;
    intvec e(d);
}

Okay. So I ran this on Ubuntu 10.10 x64 and I see the segmentation fault. Here's some details. In general, my summary seems to be that this is a bug in the compiler. (Note that I'm not the original question asker, I was merely able to reproduce his results).

I've also forwarded this to the llvm mailing list at http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036231.html


wlynch@green:/tmp$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
wlynch@green:/tmp$ llvm-g++ -O0 -g main.cc && ./a.out 
Segmentation fault
wlynch@green:/tmp$ llvm-g++ -O3 -g main.cc && ./a.out 
Segmentation fault

(gdb) bt
#0  0x00007ffff780aa75 in *__GI_raise (sig=<value optimized out>)                                                                at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff780e5c0 in *__GI_abort ()                                                                                         at abort.c:92
#2  0x00007ffff78444fb in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>)                             at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007ffff784e5b6 in malloc_printerr (action=3, str=0x7ffff791ead3 "free(): invalid pointer", ptr=<value optimized out>)    at malloc.c:6266
#4  0x00007ffff7854e83 in *__GI___libc_free (mem=<value optimized out>)                                                          at malloc.c:3738
#5  0x0000000000401476 in __gnu_cxx::new_allocator<int>::deallocate (this=0x7fffffffe5a8, __p=0x62c000, unnamed_arg=4)           at include/c++/4.2.1/ext/new_allocator.h:97
#6  0x00000000004014b1 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate (this=0x7fffffffe5a8, __p=0x62c000, __n=4) at include/c++/4.2.1/bits/stl_vector.h:146
#7  0x00000000004014fe in std::_Vector_base<int, std::allocator<int> >::~_Vector_base (this=0x7fffffffe5a8)                      at include/c++/4.2.1/bits/stl_vector.h:132
#8  0x00000000004017cf in std::vector<int, std::allocator<int> >::~vector (this=0x7fffffffe5a8)                                  at include/c++/4.2.1/bits/stl_vector.h:287
#9  0x0000000000401886 in intvec::~intvec (this=0x7fffffffe5a8)                                                                  at main.cc:6
#10 0x00000000004018a4 in std::stack<int, intvec>::~stack (this=0x7fffffffe5a8)                                                  at include/c++/4.2.1/bits/stl_stack.h:99
#11 0x0000000000400c01 in main ()                                                                                                at main.cc:10

We also get a free of an invalid pointer. Which makes sense from the traceback.


wlynch@green:/tmp$ valgrind ./a.out 
==4644== Memcheck, a memory error detector
==4644== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4644== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4644== Command: ./a.out
==4644== 
==4644== Invalid free() / delete / delete[]
==4644==    at 0x4C270BD: free (vg_replace_malloc.c:366)
==4644==    by 0x401475: __gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long) (new_allocator.h:97)
==4644==    by 0x4014B0: std::_Vector_base<int, std::allocator<int> >::_M_deallocate(int*, unsigned long) (stl_vector.h:146)
==4644==    by 0x4014FD: std::_Vector_base<int, std::allocator<int> >::~_Vector_base() (stl_vector.h:132)
==4644==    by 0x4017CE: std::vector<int, std::allocator<int> >::~vector() (stl_vector.h:287)
==4644==    by 0x401885: intvec::~intvec() (main.cc:6)
==4644==    by 0x4018A3: std::stack<int, intvec>::~stack() (stl_stack.h:99)
==4644==    by 0x400C00: main (main.cc:10)
==4644==  Address 0x5433000 is not stack'd, malloc'd or (recently) free'd
==4644== 
==4644== 
==4644== HEAP SUMMARY:
==4644==     in use at exit: 1 bytes in 1 blocks
==4644==   total heap usage: 1 allocs, 1 frees, 1 bytes allocated
==4644== 
==4644== LEAK SUMMARY:
==4644==    definitely lost: 1 bytes in 1 blocks
==4644==    indirectly lost: 0 bytes in 0 blocks
==4644==      possibly lost: 0 bytes in 0 blocks
==4644==    still reachable: 0 bytes in 0 blocks
==4644==         suppressed: 0 bytes in 0 blocks
==4644== Rerun with --leak-check=full to see details of leaked memory
==4644== 
==4644== For counts of detected and suppressed errors, rerun with: -v
==4644== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

I reduced the test case a bit. I'm actually leaning towards this being a STL implementation error, rather than a compiler error.

#include <vector>

class blub {};
class intvec : public std::vector<int>, public blub {};

int main() {
    intvec d;
    intvec e(d);
}
高冷爸爸 2024-10-08 18:12:50

要了解实际发生的情况,请尝试使用 -g 标志进行编译以启用调试信息,然后运行 ​​valgrind ./a.out 来获取堆栈跟踪发生段错误的地方。

To figure out what's actually happening, try to compile with the -g flag to enable debug information to be emitted, then run valgrind ./a.out to get a stack trace where the segfault occurs.

甲如呢乙后呢 2024-10-08 18:12:50

对我来说没有段错误,你使用什么平台?

macmini:stackoverflow samm$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

macmini:stackoverflow samm$ cat stack.cc
#include <vector>
#include <stack>
using namespace std;

class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};

int main()
{
  std::stack<int, intvec> s;
}
macmini:stackoverflow samm$ llvm-g++ -g stack.cc 
macmini:stackoverflow samm$ ./a.out
macmini:stackoverflow samm$ echo $?
0
macmini:stackoverflow samm$ 

does not segfault for me, what platform are you using?

macmini:stackoverflow samm$ llvm-g++ --version
llvm-g++ (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

macmini:stackoverflow samm$ cat stack.cc
#include <vector>
#include <stack>
using namespace std;

class blub {};
class intvec : public std::vector<int, std::allocator<int> >, public blub {};

int main()
{
  std::stack<int, intvec> s;
}
macmini:stackoverflow samm$ llvm-g++ -g stack.cc 
macmini:stackoverflow samm$ ./a.out
macmini:stackoverflow samm$ echo $?
0
macmini:stackoverflow samm$ 
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文