User account creation filtered due to spam.

Bug 6462 - jc1 should have better error message for corrupt jar file ("Cannot allocate xxx bytes after allocating yyyy bytes")
Summary: jc1 should have better error message for corrupt jar file ("Cannot allocate x...
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 3.0.4
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2002-04-25 13:36 UTC by me
Modified: 2016-09-30 22:52 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-09-30 05:25:13


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description me 2002-04-25 13:36:01 UTC
jc1 exits with the following error message when I try to compile a java file. It also happens when I try to compile already compiled .class files.


gcc --verbose  -c -o Board.o Board.java
Reading specs from /home/tmp/christl/gcc-3.0.4/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.0.4/specs
Configured with: ../gcc-3.0.4/configure --prefix=/home/cip/christl/tmp/gcc-3.0.4
Thread model: single
gcc version 3.0.4
 /home/tmp/christl/gcc-3.0.4/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.0.4/jc1 Board.java -quiet -dumpbase Board.java -version -o /tmp/ccwevWAf.s
GNU Java version 3.0.4 (i686-pc-linux-gnu)
        compiled by GNU C version 3.0.4.

jc1: Cannot allocate 1768386413 bytes after allocating 179016 bytes

Release:
gcc-3.0.4

Environment:
Redhat 7.2

gcc 3.0.4 built from source with "make bootstrap-lean", using gcc 2.96. I omitted the testing step.

AMD Athlon 900 MHz with 512MB RAM and plenty of diskspace
Comment 1 Tom Tromey 2002-04-25 23:34:38 UTC
From: Tom Tromey <tromey@redhat.com>
To: me@christltimon.de
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/6462: jc1 "Cannot allocate xxx bytes after allocating yyyy bytes" message
Date: 25 Apr 2002 23:34:38 -0600

 >>>>> ">" == me  <me@christltimon.de> writes:
 
 >> Number:         6462
 >> Synopsis:       jc1 "Cannot allocate xxx bytes after allocating yyyy bytes" message
 
 You haven't really given us enough information to help with this
 problem.  For instance, can you reproduce it with a small test case?
 
 gcc 3.1 is going to be released pretty soon.  Could you try compiling
 your program with the 3.1 snapshot?  That would be helpful.
 
 Tom

Comment 2 Tom Tromey 2002-04-29 15:36:06 UTC
From: Tom Tromey <tromey@redhat.com>
To: Christl Timon <me@christltimon.de>
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 <me@christltimon.de> 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
Comment 3 Andrew Pinski 2003-05-24 17:22:04 UTC
Can you try compiling your program with 3.3?
Comment 4 Tom Tromey 2003-08-01 03:39:14 UTC
Downgrading this as it is not critical.
It is really just a request for a nicer error message
if we find a corrupted .jar file.
Comment 5 Andrew Pinski 2016-09-30 22:52:00 UTC
Closing as won't fix as the Java front-end has been removed from the trunk.