calloc + strcpyについて

フォーラム(掲示板)ルール
フォーラム(掲示板)ルールはこちら  ※コードを貼り付ける場合は [code][/code] で囲って下さい。詳しくはこちら
わん

calloc + strcpyについて

#1

投稿記事 by わん » 7年前

以下のコードを実行したときの実行結果についてわかりません。
連続して領域を確保すると、どのように考えればよろしいでしょうか?

コード:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(){
  char *a,*b;
  int i;

  a = (char*)calloc(20,sizeof(char));
  b = (char*)calloc(20,sizeof(char));
  strcpy(a,"abcdefgh ijklmn op qrstuvwxyz! abcdefg hij lmnopqrst");

  for(i = 0; i<20; i++)
    printf("a[%d] = %c\n",i,a[i]);
  for(i = 0; i<20; i++)
    printf("b[%d] = %c\n",i,b[i]);
  return 0;
}
実行結果

a[0] = a
a[1] = b
a[2] = c
a[3] = d
a[4] = e
a[5] = f
a[6] = g
a[7] = h
a[8] =
a[9] = i
a[10] = j
a[11] = k
a[12] = l
a[13] = m
a[14] = n
a[15] =
a[16] = o
a[17] = p
a[18] =
a[19] = q
b[0] = b
b[1] = c
b[2] = d
b[3] = e
b[4] = f
b[5] = g
b[6] =
b[7] = h
b[8] = i
b[9] = j
b[10] =
b[11] = k
b[12] = l
b[13] = m
b[14] = n
b[15] = o
b[16] = p
b[17] = q
b[18] = r
b[19] = s

わん

calloc + strcpyについて

#2

投稿記事 by わん » 7年前

言語はC++となってますが、C言語です。

アバター
usao
記事: 1887
登録日時: 11年前

Re: calloc + strcpyについて

#3

投稿記事 by usao » 7年前

何が言いたいのか(何の話をしたいのか,意図)がわかりません.

YuO
記事: 947
登録日時: 13年前
住所: 東京都世田谷区

Re: calloc + strcpyについて

#4

投稿記事 by YuO » 7年前

わん さんが書きました:連続して領域を確保すると、どのように考えればよろしいでしょうか?
単なるバッファーオーバーランによる未定義動作の結果なので,「たまたまこうなった」としか考えようがないです。

梅衣堂ひよ
記事: 24
登録日時: 7年前

Re: calloc + strcpyについて

#5

投稿記事 by 梅衣堂ひよ » 7年前

わん さんが書きました:

コード:

  a = (char*)calloc(20,sizeof(char));
  b = (char*)calloc(20,sizeof(char));
メモリがaとbで連続した領域を確保できたため、事実上のa[40]になったことが原因だと思います。
プログラム実行直後だから起きた出来事ですね。
何度もメモリの確保と解放を繰り返した影響でメモリが断片化した状態で行えば、a[20]とb[20]で別々の場所にメモリが確保されるはずのなので、再現できる可能性は限りなく低いと思いますよ。

C++、メモリ断片化しますよね?(そこが自信ない
結構説明が下手ですのでご了承ください。割と言葉が足りなかったり文字だらけで分かりにくかったりします。

アバター
みけCAT
記事: 6734
登録日時: 13年前
住所: 千葉県
連絡を取る:

Re: calloc + strcpyについて

#6

投稿記事 by みけCAT » 7年前

まず、C言語では確保された領域の外にアクセスすると未定義動作となり、何があってもおかしくありません。
梅衣堂ひよ さんが書きました:メモリがaとbで連続した領域を確保できたため、事実上のa[40]になったことが原因だと思います。
これは違うでしょう。
提示された実行結果を見ると、「rstuvwxyz! a」の12文字が抜けており、領域は連続していません。
これは、メモリの管理に使う情報が入るためか、32バイトのアラインメントに合わせるためであると考えられます。
複雑な問題?マシンの性能を上げてOpenMPで殴ればいい!(死亡フラグ)

わん

Re: calloc + strcpyについて

#7

投稿記事 by わん » 7年前

皆様 ご回答ありがとうございます。

このような結果となってしまった理由について、お願いしたいと思います。

aとbは不連続な領域をとり、aとbの間の領域に消えた12文字が存在する。
そのような結果となってしまった理由として、12文字はメモリの管理に使う情報またはアラインメントに合わせるためという理解でよろしいでしょうか?

YuO
記事: 947
登録日時: 13年前
住所: 東京都世田谷区

Re: calloc + strcpyについて

#8

投稿記事 by YuO » 7年前

わん さんが書きました:このような結果となってしまった理由について、お願いしたいと思います。
たまたま。

アバター
みけCAT
記事: 6734
登録日時: 13年前
住所: 千葉県
連絡を取る:

Re: calloc + strcpyについて

#9

投稿記事 by みけCAT » 7年前

わん さんが書きました:どのように考えればよろしいでしょうか?
こんな未定義動作の危険なコードを書くのはやめよう、未定義動作を起こさないように気をつけよう、と考えるのがいいでしょう。
複雑な問題?マシンの性能を上げてOpenMPで殴ればいい!(死亡フラグ)

みえ
記事: 23
登録日時: 7年前

Re: calloc + strcpyについて

#10

投稿記事 by みえ » 7年前

calloc や malloc といった API の仕様は、言語である C/C++ の範疇ではなく、ライブラリ (VC ランタイムや GLIBC) に依存する部分だと思います。"malloc しくみ" などのキーワードで検索すれば、どのようにメモリ領域が割り当てられるかを説明しているページが数多くヒットするので、幾つか探してみてはいかがでしょうか。また、Youtube には伝説の malloc 動画と呼ばれる有名な動画もあります。
わん さんが書きました:このような結果となってしまった理由について、お願いしたいと思います。

aとbは不連続な領域をとり、aとbの間の領域に消えた12文字が存在する。
そのような結果となってしまった理由として、12文字はメモリの管理に使う情報またはアラインメントに合わせるためという理解でよろしいでしょうか?
わんさんの見た 12 文字 (すなわち "b - a == 0x20" ) は、梅衣堂ひよさんが仰るように、プロセス開始直後でヒープ領域ががら空きであり、a と b に隣り合った領域 (= チャンク) が順当に割り当てられた結果だと思います。

VC++ の場合は分かりませんが、GLIBC であれば calloc を呼び出すと以下のコードで実装されている __libc_calloc という内部関数が呼ばれます。

sourceware.org Git - glibc.git/blob - malloc/malloc.c
https://sourceware.org/git/?p=glibc.git ... 3db04#l496

上記ソースコード中のコメントに、各チャンクの構造が略図で示されています。

コード:

/*
   malloc_chunk details:

(..snip..)

    An allocated chunk looks like this:

    chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             Size of previous chunk, if unallocated (P clear)  |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             Size of chunk, in bytes                     |A|M|P|
      mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             User data starts here...                          .
            .                                                               .
            .             (malloc_usable_size() bytes)                      .
            .                                                               |
nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             (size of chunk, but used for application data)    |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |             Size of next chunk, in bytes                |A|0|1|
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(..snip..)

*/
もし隣り合ったチャンクがともに解放されていないのであれば、みけCAT さんの仰る「管理データ」は[Size of next chunk, in bytes] で示された 8 バイトということになります。ただし、各チャンクが管理データを持っているため、管理データの長さがチャンク間の長さに寄与することはなさそうです。

そこで出てくるのが「アラインメント」の方ですが、これは単純に 64bit 境界に合わせるのではなく、GLIBC の中でアラインメント境界 (= MALLOC_ALIGNMENT) がワード サイズの 2 倍とされているようなので、64bit だと 16 バイトでしょうか。さらに、チャンクの最小サイズ (= MIN_CHUNK_SIZE = &((struct malloc_chunk*)0)->fd_nextsize == 32?) も決まっています。

20 バイトを確保すると、まず最小サイズの 32 バイトに切り上げられ、これは 16 バイト境界に合うためチャンクは 32 バイトとなります。これが 12 バイトの真相ではないでしょうか。

上記はコードをざっと眺めただけの判断なので厳密には間違っているかもしれませんが、回答になっていれば幸いです。

sleep

Re: calloc + strcpyについて

#11

投稿記事 by sleep » 7年前

みえ さんが書きました: 20 バイトを確保すると、まず最小サイズの 32 バイトに切り上げられ、これは 16 バイト境界に合うためチャンクは 32 バイトとなります。これが 12 バイトの真相ではないでしょうか。

上記はコードをざっと眺めただけの判断なので厳密には間違っているかもしれませんが、回答になっていれば幸いです。
間違ってませんよ。

chunk のサイズ用の領域が8byte、それを含む最小サイズが32byte
以降、1 byteでも超えると16byteずつchunkの割り当てサイズが更新されていきます。
例えば25byte割り当てれば25+8=33byteになるので32+16=48byte、41byte割り当てれば41+8=49byteになるので32+16+16=64byte、57byte割り当てれば57+8=65byteになるので32+16+16+16=80byteになっていきます。

ただし、これはslabから連続したオブジェクトの領域を獲得できた場合の限定された話です。
サイズの大きな動的割り当てを実施した場合など、動的割り当て毎に別のslabから未割り当てオブジェクトが獲得されると今回のようなケースの結果にはなりません。
わん さんが書きました: このような結果となってしまった理由について、お願いしたいと思います。

aとbは不連続な領域をとり、aとbの間の領域に消えた12文字が存在する。
そのような結果となってしまった理由として、12文字はメモリの管理に使う情報またはアラインメントに合わせるためという理解でよろしいでしょうか?
calloc、strcpyについての質問のようですが、これLinux環境のglibcに限定された環境依存の実装の話なので、calloc、strcpyというC言語のライブラリ関数の仕様ではありません。

返信

“C言語何でも質問掲示板” へ戻る