Re: Re: OutOfMemoryError while compiling GNU Classpath

Dalibor Topic wrote:
> Kiyo Inaba wrote:
>> Hi Ito-san,
>>
>> You wrote:
>>>> I have found that recent Kaffe causes OutOfMemoryError in the
>>>> process of this compiling.
>>> I tested this on a machine with rich memory, and have found out
>>> that, in order to compile GNU Classpath 0.96.1 with ecj,
>>
>> Since I gave up compiling GNU Classpath everytime, I did not notice
>> this trouble. But, even without zzip library if we need 384MB, the
>> increase of 60MB or so should not make much difference ;-)
>>
>> Kiyo
>> P.S. I am so happy to know the weekly snap helps tracking down these
>>      problem.
>> P.P.S. Of course, it is better to write some special note in FAQ about
>>      this memory issue.
> 
> GNU Classpath CVS head is a bit tough on the compilers, agreed. ;) But 
> this seems to be a kaffe issue, so I'll investigate to see if the new 
> zzip based code is leaking memory.

OK, running this through valgrind (and we could use a volunteer to make 
Kaffe valgrind clean now that the wrestling with the compiler warnings 
is coming to an end ...) gives me:

==10731== Thread 1:
==10731==
==10731== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely 
lost in loss record 4 of 25
==10731==    at 0x4022765: malloc (vg_replace_malloc.c:149)
==10731==    by 0x41E79B2: (within /lib/tls/i686/cmov/libc-2.6.1.so)
==10731==    by 0x41E8208: __nss_database_lookup (in 
/lib/tls/i686/cmov/libc-2.6.1.so)
==10731==    by 0x48EAFDB: ???
==10731==    by 0x48EC11C: ???
==10731==    by 0x4194EEB: getpwuid_r (in /lib/tls/i686/cmov/libc-2.6.1.so)
==10731==    by 0x419489D: getpwuid (in /lib/tls/i686/cmov/libc-2.6.1.so)
==10731==    by 0x40DC566: 
Java_gnu_classpath_VMSystemProperties_getUserName 
(gnu_classpath_VMSystemProperties.c:317)
==10731==    by 0x8151E2B: ???
==10731==    by 0x81625FC: ???
==10731==    by 0x81570C2: ???
==10731==    by 0x40ABA3B: engine_callMethod (sysdepCallMethod.h:46)
==10731==
==10731==
==10731== 100 bytes in 1 blocks are possibly lost in loss record 7 of 25
==10731==    at 0x4021AA4: calloc (vg_replace_malloc.c:279)
==10731==    by 0x427E115: zzip_file_open (in /usr/lib/libzzip-0.so.13.0.49)
==10731==
==10731==
==10731== 4,532,544 (46,800 direct, 4,485,744 indirect) bytes in 468 
blocks are definitely lost in loss record 19 of 25
==10731==    at 0x4021AA4: calloc (vg_replace_malloc.c:279)
==10731==    by 0x427E115: zzip_file_open (in /usr/lib/libzzip-0.so.13.0.49)
==10731==
==10731==
==10731== 1,885,752 bytes in 198 blocks are possibly lost in loss record 
22 of 25
==10731==    at 0x4022765: malloc (vg_replace_malloc.c:149)
==10731==    by 0x428C3F0: (within /usr/lib/libz.so.1.2.3.3)
==10731==    by 0x428C571: inflateInit2_ (in /usr/lib/libz.so.1.2.3.3)
==10731==    by 0x427E39C: zzip_file_open (in /usr/lib/libzzip-0.so.13.0.49)
==10731==
==10731==
==10731== 13,402,112 bytes in 409 blocks are possibly lost in loss 
record 25 of 25
==10731==    at 0x4022765: malloc (vg_replace_malloc.c:149)
==10731==    by 0x427E14C: zzip_file_open (in /usr/lib/libzzip-0.so.13.0.49)
==10731==
==10731== LEAK SUMMARY:
==10731==    definitely lost: 46,836 bytes in 469 blocks.
==10731==    indirectly lost: 4,485,864 bytes in 337 blocks.
==10731==      possibly lost: 15,287,964 bytes in 608 blocks.
==10731==    still reachable: 990,462 bytes in 56 blocks.
==10731==         suppressed: 0 bytes in 0 blocks.

So Ito-san is right, it's my fesh zziplib code. Sorry about that, I'll 
get on it right away, and thank you very much for spotting it.

cheers,
dalibor topic