私が得ているこの奇妙なエラーは何ですか? Ubuntu 10.10でg ++を使用してC++をコンパイルしています。実行可能ファイルを実行するとランダムにポップアップします(8時間に2回、1時間に10回コンパイルされる可能性があります)。ただし、クリーンにして再コンパイルすると、ほとんどの場合消えます。
*** glibc detected *** ./emailQueue.app: free(): invalid next size (fast): 0x0000000001c40270 ***
======= Backtrace: =========
/lib/libc.so.6(+0x774b6)[0x7f490d95e4b6]
/lib/libc.so.6(cfree+0x73)[0x7f490d964c83]
./emailQueue.app[0x401f47]
/lib/libc.so.6(__libc_start_main+0xfe)[0x7f490d905d8e]
./emailQueue.app[0x401cc9]
======= Memory map: ========
00400000-0040d000 r-xp 00000000 08:01 1311132 /home/server/Projects/email/emailQueue.app
0060d000-0060e000 r--p 0000d000 08:01 1311132 /home/server/Projects/email/emailQueue.app
0060e000-0060f000 rw-p 0000e000 08:01 1311132 /home/server/Projects/email/emailQueue.app
01c40000-01c82000 rw-p 00000000 00:00 0 [heap]
7f4908000000-7f4908021000 rw-p 00000000 00:00 0
7f4908021000-7f490c000000 ---p 00000000 00:00 0
7f490ce52000-7f490ce5e000 r-xp 00000000 08:01 1051251 /lib/libnss_files-2.12.1.so
7f490ce5e000-7f490d05d000 ---p 0000c000 08:01 1051251 /lib/libnss_files-2.12.1.so
7f490d05d000-7f490d05e000 r--p 0000b000 08:01 1051251 /lib/libnss_files-2.12.1.so
7f490d05e000-7f490d05f000 rw-p 0000c000 08:01 1051251 /lib/libnss_files-2.12.1.so
7f490d05f000-7f490d075000 r-xp 00000000 08:01 1048770 /lib/libz.so.1.2.3.4
7f490d075000-7f490d275000 ---p 00016000 08:01 1048770 /lib/libz.so.1.2.3.4
7f490d275000-7f490d276000 r--p 00016000 08:01 1048770 /lib/libz.so.1.2.3.4
7f490d276000-7f490d277000 rw-p 00017000 08:01 1048770 /lib/libz.so.1.2.3.4
7f490d277000-7f490d28e000 r-xp 00000000 08:01 1051248 /lib/libnsl-2.12.1.so
7f490d28e000-7f490d48d000 ---p 00017000 08:01 1051248 /lib/libnsl-2.12.1.so
7f490d48d000-7f490d48e000 r--p 00016000 08:01 1051248 /lib/libnsl-2.12.1.so
7f490d48e000-7f490d48f000 rw-p 00017000 08:01 1051248 /lib/libnsl-2.12.1.so
7f490d48f000-7f490d491000 rw-p 00000000 00:00 0
7f490d491000-7f490d49a000 r-xp 00000000 08:01 1051244 /lib/libcrypt-2.12.1.so
7f490d49a000-7f490d69a000 ---p 00009000 08:01 1051244 /lib/libcrypt-2.12.1.so
7f490d69a000-7f490d69b000 r--p 00009000 08:01 1051244 /lib/libcrypt-2.12.1.so
7f490d69b000-7f490d69c000 rw-p 0000a000 08:01 1051244 /lib/libcrypt-2.12.1.so
7f490d69c000-7f490d6ca000 rw-p 00000000 00:00 0
7f490d6ca000-7f490d6e2000 r-xp 00000000 08:01 1051256 /lib/libpthread-2.12.1.so
7f490d6e2000-7f490d8e1000 ---p 00018000 08:01 1051256 /lib/libpthread-2.12.1.so
7f490d8e1000-7f490d8e2000 r--p 00017000 08:01 1051256 /lib/libpthread-2.12.1.so
7f490d8e2000-7f490d8e3000 rw-p 00018000 08:01 1051256 /lib/libpthread-2.12.1.so
7f490d8e3000-7f490d8e7000 rw-p 00000000 00:00 0
7f490d8e7000-7f490da61000 r-xp 00000000 08:01 1048743 /lib/libc-2.12.1.so
7f490da61000-7f490dc60000 ---p 0017a000 08:01 1048743 /lib/libc-2.12.1.so
7f490dc60000-7f490dc64000 r--p 00179000 08:01 1048743 /lib/libc-2.12.1.so
7f490dc64000-7f490dc65000 rw-p 0017d000 08:01 1048743 /lib/libc-2.12.1.so
7f490dc65000-7f490dc6a000 rw-p 00000000 00:00 0
7f490dc6a000-7f490dc7f000 r-xp 00000000 08:01 1048655 /lib/libgcc_s.so.1
7f490dc7f000-7f490de7e000 ---p 00015000 08:01 1048655 /lib/libgcc_s.so.1
7f490de7e000-7f490de7f000 r--p 00014000 08:01 1048655 /lib/libgcc_s.so.1
7f490de7f000-7f490de80000 rw-p 00015000 08:01 1048655 /lib/libgcc_s.so.1
7f490de80000-7f490df02000 r-xp 00000000 08:01 1051246 /lib/libm-2.12.1.so
7f490df02000-7f490e101000 ---p 00082000 08:01 1051246 /lib/libm-2.12.1.so
7f490e101000-7f490e102000 r--p 00081000 08:01 1051246 /lib/libm-2.12.1.so
7f490e102000-7f490e103000 rw-p 00082000 08:01 1051246 /lib/libm-2.12.1.so
7f490e103000-7f490e1eb000 r-xp 00000000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14
7f490e1eb000-7f490e3ea000 ---p 000e8000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14
7f490e3ea000-7f490e3f2000 r--p 000e7000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14
7f490e3f2000-7f490e3f4000 rw-p 000ef000 08:01 4853329 /usr/lib/libstdc++.so.6.0.14
7f490e3f4000-7f490e409000 rw-p 00000000 00:00 0
7f490e409000-7f490e5c7000 r-xp 00000000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0
7f490e5c7000-7f490e7c7000 ---p 001be000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0
7f490e7c7000-7f490e7cc000 r--p 001be000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0
7f490e7cc000-7f490e816000 rw-p 001c3000 08:01 4851315 /usr/lib/libmysqlclient.so.16.0.0
7f490e816000-7f490e817000 rw-p 00000000 00:00 0
7f490e817000-7f490e837000 r-xp 00000000 08:01 1048597 /lib/ld-2.12.1.so
7f490ea15000-7f490ea1c000 rw-p 00000000 00:00 0
7f490ea33000-7f490ea37000 rw-p 00000000 00:00 0
7f490ea37000-7f490ea38000 r--p 00020000 08:01 1048597 /lib/ld-2.12.1.so
7f490ea38000-7f490ea39000 rw-p 00021000 08:01 1048597 /lib/ld-2.12.1.so
7f490ea39000-7f490ea3a000 rw-p 00000000 00:00 0
7fffb85b9000-7fffb85da000 rw-p 00000000 00:00 0 [stack]
7fffb85ff000-7fffb8600000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted
メモリエラーがあることを意味します。 free
によって割り当てられていないポインターをmalloc
(またはdelete
によって作成されていないオブジェクトnew
)にしようとしているか、しようとしている可能性があります。 free
/delete
このようなオブジェクトが複数回。バッファをオーバーフローさせているか、書き込むべきではないメモリに書き込みを行っているため、ヒープが破損している可能性があります。
この問題は、プログラミングエラーがいくつでも発生する可能性があります。デバッガを使用し、バックトレースを取得し、エラーが発生したときにプログラムが何をしているかを確認する必要があります。それが失敗し、過去のある時点でヒープが破損していると判断した場合、いくつかの苦痛なデバッグが必要になる可能性があります(プロジェクトが少しずつ取り組むことができるほど小さければ、それほど苦痛ではないかもしれません)。
プログラムで動的なメモリ割り当てを行わなかったにもかかわらず、同じ問題が発生しましたが、メモリを割り当てずにベクトルのインデックスにアクセスしていました。したがって、同じ場合は、resize()
を使用してメモリを割り当ててから、ベクトル要素にアクセスしてください。
コードが必要ですが、通常、割り当てられていないポインターからfree()
メモリーをしようとするとポップアップします。これは、二重解放を行っているときによく起こります。
次のようなポインターの配列にスペースを割り当てようとしている場合
char** my_array_of_strings; // or some array of pointers such as int** or even void**
次に、n個のポインターにスペースを割り当てるときに、Wordのサイズ(64ビットシステムでは8バイト、32ビットシステムでは4バイト)を考慮する必要があります。ポインターのサイズは、Wordのサイズと同じです。
したがって、n個のポインターにスペースを割り振ることができますが、実際には8倍または4倍のn倍が必要になります(それぞれ64ビットまたは32ビットのシステムの場合)
8バイトのn要素に対して割り当てられたメモリがオーバーフローしないようにするには:
my_array_of_strings = (char**) malloc( n * 8 ); // for 64-bit systems
my_array_of_strings = (char**) malloc( n * 4 ); // for 32-bit systems
これは、それぞれ8バイト(または32ビットシステムを使用している場合は4バイト)で構成されるn個のポインターのブロックを返します。
Linuxでは、Wordのサイズを補正していなくてもn個のポインターをすべて使用できることに気づきましたが、そのメモリーを解放しようとすると、その間違いに気付き、かなり厄介なエラーが発生します。割り当てられたメモリをオーバーフローさせると、多くのセキュリティ問題が待ち構えています。
同様のエラーが発生しました。それは急いで行われたnoobの間違いでした。サイズint a []を宣言せずにアクセスしようとする整数配列。 C++コンパイラーは、mainにあれば、このようなエラーを簡単にキャッチするはずです。ただし、この特定のint配列はオブジェクト内で宣言されているため、オブジェクトと同時に作成され(多くのオブジェクトが作成されていた)、コンパイラはfree():invalid next size(normal)エラーをスローしていました。私はこれについて2つの説明を考えました(誰かがもっと知っているなら私に教えてください):これはそれに割り当てられたランダムなメモリをもたらしましたが、これはアクセスできなかったので、見つけようとしている他のすべてのヒープメモリを解放しましたこのint。 2.)プログラムが必要とするメモリはプログラムにとって実質的に無限であり、これを割り当てるために他のすべてのメモリを解放していました。
シンプルな:
int* a;
class foo{
foo(){
for(i=0;i<n;i++)
a=new int[i];
}
問題を解決しました。しかし、コンパイラがエラーを「実際に」見つけることができなかったため、これをデバッグしようとするとかなり時間がかかりました。
コードがSTLのapiを回避し、誰かがサイズを変更すると、安全に配列に書き込みを行うような状況に遭遇しました。ここにアサートを追加すると、キャッチされました:
void Logo::add(const QVector3D &v, const QVector3D &n)
{
GLfloat *p = m_data.data() + m_count;
*p++ = v.x();
*p++ = v.y();
*p++ = v.z();
*p++ = n.x();
*p++ = n.y();
*p++ = n.z();
m_count += 6;
Q_ASSERT( m_count <= m_data.size() );
}