From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17231 invoked by alias); 29 Apr 2002 21:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 17217 invoked by uid 71); 29 Apr 2002 21:36:01 -0000 Date: Mon, 29 Apr 2002 14:36:00 -0000 Message-ID: <20020429213601.17216.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Tom Tromey Subject: Re: java/6462: jc1 "Cannot allocate xxx bytes after allocating yyyy bytes" message Reply-To: Tom Tromey X-SW-Source: 2002-04/txt/msg01614.txt.bz2 List-Id: The following reply was made to PR java/6462; it has been noted by GNATS. From: Tom Tromey To: Christl Timon Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/6462: jc1 "Cannot allocate xxx bytes after allocating yyyy bytes" message Date: 29 Apr 2002 15:36:06 -0600 >>>>> ">" == Christl Timon writes: I've CC'd gcc-gnats so that this will be logged in the PR. >> Note especially #2: The source line is >> zipf-> central_directory=ALLOC(zipf->dir_size+1); >> For a certain jar file in my $CLASSPATH (retroguard.jar, a bytecode >> optimizer and obfuscator) the value of zipf->dir_size is unusally large. >> Seems that the makers of retroguard have corrupted the jarfile with >> their own product. When I remove this jar file from my $CLASSPATH it works. Thanks for analyzing this. We definitely can't support cases where a jar file is intentionally corrupted like this. jar files must conform to the spec. Perhaps we could change this xmalloc() to an ordinary malloc() and print a nicer error message before dying. That's pretty low priority for me, but if you want to write a patch that would be helpful. Tom