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

void alloc(int i)
{
  auto double *a;
  int n;

  printf("%dMB\n", i);

  a = (double *) malloc(1048575);
  if(a == NULL){
    printf("allocation error\n");
    exit(0);
  }

//  free(a);

}

void main()
{
  int i;

  for(i = 0;;i++){
    alloc(i);
  }

}

    size_t n;  char *p, *q;

    for (n = 1048000; n <= 1050000; n++) {
        p = malloc(n);
        if (p == NULL) break;
        free(p);
        q = malloc(n);
        free(q);
        if (p != q) printf("p=%p, q=%p, n=%u (%#x)\n", p, q, n, n);
    }

このプログラムを走らせると、n = 1048573, 1048574, 1048575 のときのみ、通
常とは異なる結果になることがわかります。たいていの場合、free すると、その
領域がもう一度 malloc で使用されるため、同じアドレスが返されるはずです。

次に、
    for (n = 1024; ; n <<= 1) {
        p = malloc(n);
        if (p == NULL) break;
        printf("%p: %u\n", p, n);
        free(p);
    }

を試してみると、n が 1048576未満と、1048576以上とで返って来るアドレスが
異なることがわかります。

つまり、BCC の malloc は 1MBを境にメモリの割り付け方を変えているようです。
また、返されるアドレスは常に 4の倍数です。

ここからは推論ですが、1048573〜1048575 の領域を malloc するとき、これは
1MB未満なので、その領域に割り付けられます。ところが、実際にはサイズを
4の倍数にするため、1048576バイト割り付けたと記録されます。

free するとき、サイズが 1MBなので、1MB以上の領域を解放しようとして、
失敗しているものと思われます。

では、なぜこのバグが今まで問題にならなかったかというと、小さいサイズなら
ともかく、1MB ぐらいの領域を奇数バイト割り付けようとすることは普通しない
からではないでしょうか。

>> free するとき、サイズが 1MBなので、1MB以上の領域を解放しようとし
>> て、失敗しているものと思われます。

> ひょっとしたら BCC にはそのようなバグがある可能性も否定できませんが、
> そうではないと思われます。

今、読み返したら、誤解を与える文章なのに気づきました。次のように
読み替えてください。

  free するとき、サイズが 1MBなので、「1MB以上を確保する領域」から
  1MBを解放しようとして、失敗しているものと思われます。


もっと誤解のないように説明してみます。

・1MB未満のメモリは領域Ａから確保される。
・1MB以上のメモリは領域Ｂから確保される。
・指定されたサイズは、4の倍数に切り上げられる。

1048573〜1048575バイトの場合、1MB未満なので領域Ａから確保される。
ただし、確保されたサイズは 1048576(1MB)と記録される。

確保した領域を free しようとしたとき、サイズが 1MB なので、領域B の
解放処理が行われようとする。

しかし、free に渡されたポインタは領域Ａを指しているので失敗する。


> まず、malloc は要求したサイズぴったりのメモリを確保するとは限りません。
> 確保に成功すれば、最低でも要求したサイズは確保されますが、ひょっとし
> たらそれより大きいサイズを確保しているかもしれません（規格には定めら
> れていないようですが、少なくとも VC++ はそのような実装をしています。
> BCC はきっちり確保しますと BCC のドキュメントに明記されていたらごめ
> んなさい）。

私は、BCC の malloc が要求したサイズぴったりのメモリを確保するとは
言っていないので、シャノンさんの上の意見の真意が理解できません。


> また、返されるアドレスが４バイト境界だからといって、確保されるサイズ
> も４の倍数とは限りません。
> 仮に４の倍数バイトが確保されるとしても、前述の理由により、しっかり４
> の倍数バイト確保されたと記録されるはずです。

実は、書かなかったので申し訳ないのですが、確保された領域のひとつ前の
4バイトにそのサイズが書き込まれるようです。その値は、4の倍数です。
ただし、1〜11バイトは 12バイトになります。

    size_t n;  long *p;

    for (n = 1; n < 32; n++) {
        p = malloc(n);
        printf("p[-1]=%d, n=%d\n", p[-1], n);
        free(p);
    }


> 「滅多に無いだろうから」でバグを見逃すようなことは許されません。
 
私は、バグを見逃すことを許しているのではありません。
見逃された原因を推論しているだけです。

>>こんな誰でも思いつくようなテストをすっぽかした結果のバグが見逃されていると考えるくらいなら、何かはわからないけど何か他のバグがあると考えます。
>
>誰でも思いつくと言っておられますが、そうでもないと思いますよ。
>ただの境界値ではありません。
>境界値＋128Mまで実行しなければならないわけです。
># 真の再現条件はわからないけど、今のところは上記条件か?

よくわかりません。何ですか 128MB って。
ニタチさんが実験して、128MB 確保したところで落ちた、ですか？
今回の 1MB 境界問題とは関係ない話じゃないですか？

>はっきり言って、処理系だって他のソフトと変わりません。
>下手したら、入ったばかりの新人さんがいじった箇所がないとも限りませんし。
>OSだって処理系だって、しょっちゅうパッチが出てバグフィックスされてます。
>つまり、しょーもないバグを作り込む可能性はいくらでもあるかと。

入ったばかりの新人さんが作るのは別に構いませんよ。
俺だって入社４ヶ月目、実務２ヶ月目ですが、納品するソフト作ってますし。
しょーもないバグ作りこんでるところだってあるでしょう。
でも、作って終わりじゃないでしょう？
作った担当者がデバッグするのはもちろんのこと、その後で他の人がテストするでしょう。本人のデバッグよりずっと厳密に。

ましてや、言語処理系です。
バグがあったらバグってるソフトだけが落ちるんじゃ済まないんです。
なればこそ、テストは厳密なものが要求されます。
そこでも境界値チェックを見逃しているなんて信じられません。

>少なくとも、REEさんの示した結果により、可能性があることが示されたのに
>そこに目をつぶって可能性を捨て去るのは、建設的な不具合調査方法とは思えません。

いいです、非建設的で。
俺は BCC 使いませんから。

＃あぁ、フレーミング楽しー
＃でも、掲示板にもスレ主にも、真面目に原因探ってる方にも迷惑になるので（俺がな）、これ以上この横枝を伸ばさないようにお願い申し上げます。

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

void alloc(int i)
{
  double *a;

  printf("%dMB ", i);

  a = (double *) malloc(1048575);
  if(a == NULL){
    printf("allocation error\n");
    exit(0);
  }
  printf("malloc ");
  printf("a = %p ", a);

  free(a);
  printf("free\n");
}

int main(int argc, char* argv[])
{
  int i;

  for(i = 0; i < 10; i++){
    alloc(i);
  }
  getch();
  return 0;
}

私が知っている BCC の scanf のバグ。

	int n, i = 2, j = 3;

	n = sscanf("123 456 789", "%*[a-z] %d %d", &i, &j);
	printf("n=%d, i=%d, j=%d\n", n, i, j);

%*[a-z] は、1文字以上の英字列を読み飛ばすという書式です。
先頭の "1" は英字ではありませんから、sscanf はそこでスキャンを打ち切り
n には 0 が返るはずです。実際、VC++、gcc、LSI C-86 では、出力が、

    n=0, i=2, j=3

となりますが、BCC だけは、

    n=2, i=123, j=456

となります。