Re: Large files on AIX ?

[Gunturi Srimanth]

Pasted below are some stack traces of the cvs core.
This happens in all versions of CVS, but the 
stacktrace below is from CVS 1.11.1p1 on AIX 4.3.3.
Do let me know if there is something specific which 
needs to be checked out. 
Regards,
Srimanth.

======= where.out ============================
malloc_y.extend(0x140, 0xf0045808, 0x0) at 0xd017b6f8
malloc_y.malloc_y(??, ??) at 0xd017cf78
malloc.malloc(??) at 0xd017a5f4
buffer.allocate_buffer_datas(), line 102 in "buffer.c"
buffer.get_buffer_data(), line 124 in "buffer.c"
unnamed block buffer.buf_output.$b44, line 190 in
"buffer.c"
buffer.buf_output(0x200255d8, 0x2ff22e10, 0x3), line
190 in "buffer.c"
server.cvs_outerr(0x2ff22e10, 0x3), line 6466 in
"server.c"
unnamed block error.error.$b171, line 130 in "error.c"
error.error(0x1, 0xc, 0x20007324, 0xf032, 0x0,
0x60000000, 0x600077bd, 0x0), line 130 in "error.c"
server.protocol_memory_error(0x200255d8), line 2391 in
"server.c"
unnamed block buffer.buf_output.$b44, line 193 in
"buffer.c"
buffer.buf_output(0x200255d8, 0x2ff22e10, 0x3), line
193 in "buffer.c"
server.cvs_outerr(0x2ff22e10, 0x3), line 6466 in
"server.c"
unnamed block error.error.$b171, line 130 in "error.c"
error.error(0x1, 0xc, 0x20007324, 0xf032, 0x0,
0x60000000, 0x600077bd, 0x0), line 130 in "error.c"
=================================================
============ dump.out ===========================
malloc_y.extend(0x140, 0xf0045808, 0x0) at 0xd017b6f8

malloc_y.malloc_y(??, ??) at 0xd017cf78

malloc.malloc(??) at 0xd017a5f4

buffer.allocate_buffer_datas(), line 102 in "buffer.c"

buffer.get_buffer_data(), line 124 in "buffer.c"

unnamed block buffer.buf_output.$b44, line 190 in
"buffer.c"

buffer.buf_output(0x200255d8, 0x2ff22e10, 0x3), line
190 in "buffer.c"

server.cvs_outerr(0x2ff22e10, 0x3), line 6466 in
"server.c"

unnamed block error.error.$b171, line 130 in "error.c"

error.error(0x1, 0xc, 0x20007324, 0xf032, 0x0,
0x60000000, 0x600077bd, 0x0), line 130 in "error.c"

server.protocol_memory_error(0x200255d8), line 2391 in
"server.c"

unnamed block buffer.buf_output.$b44, line 193 in
"buffer.c"

buffer.buf_output(0x200255d8, 0x2ff22e10, 0x3), line
193 in "buffer.c"

server.cvs_outerr(0x2ff22e10, 0x3), line 6466 in
"server.c"

unnamed block error.error.$b171, line 130 in "error.c"

error.error(0x1, 0xc, 0x20007324, 0xf032, 0x0,
0x60000000, 0x600077bd, 0x0), line 130 in "error.c"

server.protocol_memory_error(0x200255d8), line 2391 in
"server.c"

unnamed block buffer.buf_output.$b44, line 193 in
"buffer.c"

buffer.buf_output(0x200255d8, 0x2ff22e10, 0x3), line
193 in "buffer.c"

server.cvs_outerr(0x2ff22e10, 0x3), line 6466 in
"server.c"

unnamed block error.error.$b171, line 130 in "error.c"

error.error(0x1, 0xc, 0x20007324, 0xf032, 0x0,
0x60000000, 0x600077bd, 0x0), line 130 in "erro
==========================================
======== mapcore.out ==========================
Entry 1:
   Object name: cvs
   Text origin:     0x10000000
   Text length:     0xd4126
   Data origin:     0x20000670
   Data length:     0x244bc
   File descriptor: 0x6

Entry 2:
   Object name: /usr/lib/libcrypt.a
   Member name: shr.o
   Text origin:     0xd00250f8
   Text length:     0x87a
   Data origin:     0xf0084528
   Data length:     0x13c
   File descriptor: 0x7

Entry 3:
   Object name: /usr/lib/libc.a
   Member name: shr.o
   Text origin:     0xd016dbe0
   Text length:     0x1d5faf
   Data origin:     0xf0000400
   Data length:     0x83b08
   File descriptor: 0x8
==========================================
=========== registers.out ====================
  $r0:0x00000000  $stkp:0x2df23050   $toc:0xf00439a4  
 $r3:0x00000140  
  $r4:0xf0045808    $r5:0x00000000    $r6:0x00000000  
 $r7:0x00000000  
  $r8:0x00000000    $r9:0x00000000   $r10:0x00000000  
$r11:0x00000000  
 $r12:0x00000000   $r13:0x00000000   $r14:0x00000000  
$r15:0x00000000  
 $r16:0x00000000   $r17:0x00000000   $r18:0x00000000  
$r19:0x00000000  
 $r20:0x00000000   $r21:0x00000000   $r22:0x00000000  
$r23:0x00000000  
 $r24:0x00000000   $r25:0x00000000   $r26:0x00000000  
$r27:0x00000000  
 $r28:0x00000000   $r29:0x00000000   $r30:0x00000000  
$r31:0x00000000  
 $iar:0xd017b6f8   $msr:0x00000000    $cr:0x00000000
$link:0xd017cf7c  
 $ctr:0x00000000   $xer:0x00000000 
 [unset $noflregs to view floating point registers]
in malloc_y.extend at 0xd017b6f8
0xd017b6f8 (extend+0x14) 9421ffa0    stwu   r1,-96(r1)

=========================================


--- Larry Jones <lawrence.jones@eds.com> wrote:
> Gunturi Srimanth writes:
> > 
> > Well, regarding allocating memory - I was able to 
> > write a small C program which was able to malloc()
> > upto ~134MB - It gave a pointer back, and i was
> able 
> > to write to all of it without any signals. Then
> why 
> > do you think CVS is having trouble with a 70MB
> file?
> 
> CVS has additional overhead -- it doesn't just suck
> the file into a
> single block of memory, it builds a data structure. 
> If you get a core
> dump and know how to get a traceback from it, it
> might be informative to
> see exactly where CVS crashed.  Note that CVS tries
> to detect out-of-
> memory conditions and handle them without crashing,
> but it isn't always
> possible.  AIX in particular used to be notorious
> for allowing you to
> allocate virtual memory that you couldn't actually
> use.
> 
> -Larry Jones
> 
> I can do that!  It's a free country!  I've got my
> rights! -- Calvin


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree