From mboxrd@z Thu Jan  1 00:00:00 1970
From: Akim Demaille <akim@epita.fr>
To: russadw@yahoo.com, bug-gcc@gnu.org
Cc: autoconf-gnats@sourceware.cygnus.com
Subject: Re: autoconf/140: g++ doesn't handle exception thrown in unexpected handler
Date: Thu, 03 Aug 2000 03:09:00 -0000
Message-id: <mv4n1iuslpi.fsf@nostromo.lrde.epita.fr>
References: <20000802214446.20805.qmail@sourceware.cygnus.com>
X-SW-Source: 2000-08/msg00063.html
List-Id: <gcc-bugs.sourceware.org>

Thanks, this is not a bug in Autoconf, it's a bug in the GCC's Gnats
interface for submitting bug reports which had you believe you were
filling a PR for GCC.

        Akim

| >Number:         140
| >Category:       autoconf
| >Synopsis:       g++ doesn't handle exception thrown in unexpected handler
| >Confidential:   no
| >Severity:       serious
| >Priority:       medium
| >Responsible:    akim
| >State:          open
| >Class:          sw-bug
| >Submitter-Id:   net
| >Arrival-Date:   Wed Aug 02 14:52:00 PDT 2000
| >Closed-Date:
| >Last-Modified:
| >Originator:     see Bruce Eckel's book Thinking in C++ V2 chapter 7, Cleanup.cpp
| >Release:        fails on 2.95.2 and 2.8.1
| >Organization:
| >Environment:
| IRIX64 6.2
| >Description:
| The code fails at line 47 "throw; // rethrow some exception" and emits a core file.
| >How-To-Repeat:
| compile with g++ -o Cleanup Cleanup.cpp
| type "Cleanup" at the command line
| cat cleanup.out
| >Fix:
| 
| >Release-Note:
| >Audit-Trail:
| >Unformatted:
| ----gnatsweb-attachment----
| Content-Type: application/octet-stream; name="Cleanup.cpp"
| Content-Transfer-Encoding: base64
| Content-Disposition: attachment; filename="Cleanup.cpp"
| 
| Ly86IEMwNzpDbGVhbnVwLmNwcAovLyBGcm9tIFRoaW5raW5nIGluIEMrKywgMm5kIEVkaXRpb24K
| Ly8gQXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuQnJ1Y2VFY2tlbC5jb20KLy8gKGMpIEJydWNlIEVj
| a2VsIDIwMDAKLy8gQ29weXJpZ2h0IG5vdGljZSBpbiBDb3B5cmlnaHQudHh0Ci8vIEV4Y2VwdGlv
| bnMgY2xlYW4gdXAgb2JqZWN0cwojaW5jbHVkZSA8ZnN0cmVhbT4KI2luY2x1ZGUgPGV4Y2VwdGlv
| bj4KI2luY2x1ZGUgPGNzdHJpbmc+CnVzaW5nIG5hbWVzcGFjZSBzdGQ7Cm9mc3RyZWFtIG91dCgi
| Y2xlYW51cC5vdXQiKTsKCmNsYXNzIE5vaXN5IHsKICBzdGF0aWMgaW50IGk7CiAgaW50IG9iam51
| bTsKICBzdGF0aWMgY29uc3QgaW50IHN6ID0gNDA7CiAgY2hhciBuYW1lW3N6XTsKcHVibGljOgog
| IE5vaXN5KGNvbnN0IGNoYXIqIG5tPSJhcnJheSBlbGVtIikgdGhyb3coaW50KXsKICAgIG9iam51
| bSA9IGkrKzsKICAgIG1lbXNldChuYW1lLCAwLCBzeik7CiAgICBzdHJuY3B5KG5hbWUsIG5tLCBz
| eiAtIDEpOwogICAgb3V0IDw8ICJjb25zdHJ1Y3RpbmcgTm9pc3kgIiA8PCBvYmpudW0KICAgICAg
| PDwgIiBuYW1lIFsiIDw8IG5hbWUgPDwgIl0iIDw8IGVuZGw7CiAgICBpZihvYmpudW0gPT0gNSkg
| dGhyb3cgaW50KDUpOwogICAgLy8gTm90IGluIGV4Y2VwdGlvbiBzcGVjaWZpY2F0aW9uOgogICAg
| aWYoKm5tID09ICd6JykgdGhyb3cgY2hhcigneicpOwogIH0KICB+Tm9pc3koKSB7CiAgICBvdXQg
| PDwgImRlc3RydWN0aW5nIE5vaXN5ICIgPDwgb2JqbnVtCiAgICAgIDw8ICIgbmFtZSBbIiA8PCBu
| YW1lIDw8ICJdIiA8PCBlbmRsOwogIH0KICB2b2lkKiBvcGVyYXRvciBuZXdbXShzaXplX3Qgc3op
| IHsKICAgIG91dCA8PCAiTm9pc3k6Om5ld1tdIiA8PCBlbmRsOwogICAgcmV0dXJuIDo6bmV3IGNo
| YXJbc3pdOwogIH0KICB2b2lkIG9wZXJhdG9yIGRlbGV0ZVtdKHZvaWQqIHApIHsKICAgIG91dCA8
| PCAiTm9pc3k6OmRlbGV0ZVtdIiA8PCBlbmRsOwogICAgOjpkZWxldGUgW11wOwogIH0KfTsKCmlu
| dCBOb2lzeTo6aSA9IDA7Cgp2b2lkIHVuZXhwZWN0ZWRfcmV0aHJvdygpIHsKICBvdXQgPDwgImlu
| c2lkZSB1bmV4cGVjdGVkX3JldGhyb3coKSIgPDwgZW5kbDsKICB0aHJvdzsgLy8gUmV0aHJvdyBz
| YW1lIGV4Y2VwdGlvbgp9CgppbnQgbWFpbigpIHsKICBzZXRfdW5leHBlY3RlZCh1bmV4cGVjdGVk
| X3JldGhyb3cpOwogIHRyeSB7CiAgICBOb2lzeSBuMSgiYmVmb3JlIGFycmF5Iik7CiAgICAvLyBU
| aHJvd3MgZXhjZXB0aW9uOgogICAgTm9pc3kqIGFycmF5ID0gbmV3IE5vaXN5WzddOwogICAgTm9p
| c3kgbjIoImFmdGVyIGFycmF5Iik7CiAgfSBjYXRjaChpbnQgaSkgewogICAgb3V0IDw8ICJjYXVn
| aHQgIiA8PCBpIDw8IGVuZGw7CiAgfQogIG91dCA8PCAidGVzdGluZyB1bmV4cGVjdGVkOiIgPDwg
| ZW5kbDsKICB0cnkgewogICAgTm9pc3kgbjMoImJlZm9yZSB1bmV4cGVjdGVkIik7CiAgICBOb2lz
| eSBuNCgieiIpOwogICAgTm9pc3kgbjUoImFmdGVyIHVuZXhwZWN0ZWQiKTsKICB9IGNhdGNoKGNo
| YXIgYykgewogICAgb3V0IDw8ICJjYXVnaHQgIiA8PCBjIDw8IGVuZGw7CiAgfQp9IC8vLzp+Cg==
| 
| 
>>From Jos.vandenOever@fenk.wag-ur.nl Thu Aug 03 03:50:00 2000
From: Jos van den Oever <Jos.vandenOever@fenk.wag-ur.nl>
To: gcc-bugs@gcc.gnu.org
Subject: can't handle 1 Gb
Date: Thu, 03 Aug 2000 03:50:00 -0000
Message-id: <39894E88.F00CDE9E@fenk.wag-ur.nl>
X-SW-Source: 2000-08/msg00064.html
Content-length: 1929

Hi,

I've attached a program that verbosely allocates memory in steps of 1 Mb and finished when the system refuses to allocate more. I wrote it to find out what the largest process is I can run on a machine. As long as the total available memory is less than 1Gb it works fine. The program stops, cleans up and finishes.

When I compile and run attached program with gcc-2.95.2 under SuSE 6.0 kernel 2.0.38 or with gcc-2.91.66 under Red Hat 6.1 kernel 2.2.15 on machines that have more than 1Gb either swap or real memory, the program gives a segmentation fault just over 1Gb of memory allocated. I've run another program that does heavy equation solving and this can use at least 1.3 Gb which in top is assigned under `lib'. So I figure that refusing to allocate more than 1Gb under some circumstances is a bug.

Best regards, Jos

I used no optimisation.
Here's the output of gdb with -g3
....
....
999000000
1000000000
1001000000
 
Program received signal SIGSEGV, Segmentation fault.
chunk_alloc (ar_ptr=0x400ca1a0, nb=1000008) at malloc.c:2801
malloc.c:2801: No such file or directory.
Current language:  auto; currently c
#include <stdlib.h>
#include <iostream.h>
typedef char * ptr;

int main() {
        ptr *z;
        z = new ptr[1000];
        ptr *zend = z+1000;
        ptr *i = z;
        while (i < zend) {
                *i=NULL;
                i++;
        }
        int size = 1000000;
        i = z;
        *i = (char *)malloc(size);
        while (*i) {
                ptr x = *i;
                ptr end = *i+size;
                while (x<end) {
                        *x = 0;
                        x++;
                }
                cout << (i-z)*size << endl;
                i++;
                *i = (char *)malloc(size);
        }
        while (i != z) {
                i--;
                free(*i);
        }
        delete [] z;
        cout << "finished" << endl;
        return 0;
}