This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: other/9081: gcc doesn't diagnose, that the compiler exceeds acompiler limit
- From: Peter Bergner <bergner at vnet dot ibm dot com>
- To: 133574 at bugs dot debian dot org, gcc-gnats at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, pavel at atrey dot karlin dot mff dot cuni dot cz
- Date: Mon, 27 Jan 2003 20:39:29 -0600
- Subject: Re: other/9081: gcc doesn't diagnose, that the compiler exceeds acompiler limit
We hit this same bug on ppc64 running 32-bit apps with the following
testcase (32-bit apps get a full 4G of addr space to live in on ppc64):
char x[2000000000];
int
main(void)
{
return 10;
}
Pavel is correct that all the calls to do_brk fail to test
the return status of do_brk. This is only part of the problem.
The other major problem is that we don't call set_brk to reserve
the bss region for the application until after we've already loaded
the loader via the load_elf_interp() call.
I have a patch that fixes both of those problems, but got delayed
in posting since I was also trying to clean up what looks to be
memory leaks in the error paths of load_elf_binary() before getting
pulled away on another problem. For example, it would seem the
following code should be freeing some of the storage it allocaed
before returning. I'll try and clean up my patch and submit it.
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
current->mm->rss = 0;
retval = setup_arg_pages(bprm);
if (retval < 0) {
send_sig(SIGKILL, current, 0);
return retval;
}
Peter