------------------------------------------------------------------------
Thu Mar 15 16:36:16 2001

In an effort to see if uninitialized data is reponsible for the test
failures on some systems (e.g., I have got inconsistent failures on
some of them), I compiled lcc first with -g, and then again with -g
-xO4, on Sun Solaris 2.7, and ran it under a debugger with memory leak
checking and pointer checking.

In neither case were pointer violations found, although there are a
substantial number of memory blocks that have not been freed on
completion, and in cpp, there is a read-from-uninitialized operation
in one call to memmove().  The latter appears to be related to input
buffer management, and may be harmless, but certainly bears further
investigation.

/var/tmp/lcc/4.1.beta.6/sparc-solaris/lcc -v -S ../lcc-4.1.beta.6/tst/paranoia.c

/tmp/local6/lib/lcc/4.1.beta.6/cpp \
	-D__STDC__=1 \
	-Dsparc \
	-D__sparc__ \
	-Dsun \
	-D__sun__ \
	-Dunix \
	-D__LCC__ \
	-I/tmp/local6/lib/lcc/4.1.beta.6/include \
	-I/usr/local/include \
	-I/usr/include \
	../lcc-4.1.beta.6/tst/paranoia.c \
	/tmp/lcc63490.i

/tmp/local6/lib/lcc/4.1.beta.6/rcc \
	-target=sparc/solaris \
	-v \
	/tmp/lcc63490.i \
	paranoia.s

with Sun dbx and "check -all" produces one read-from-uninitialized
during a memmove() call in cpp:

Read from uninitialized (rui):
Attempting to read 1 byte at address 0x6025c
    which is 8196 bytes into a heap block of size 32772 bytes at 0x5e258
This block was allocated from:
        [1] domalloc() at line 254 in "cpp.c"
        [2] setsource() at line 561 in "lex.c"
        [3] setup() at line 88 in "unix.c"
        [4] main() at line 34 in "cpp.c"

Current function is memmove
  106                           *cdp++ = *csp++;
(/opt/SUNWspro/bin/../WS6U1/bin/sparcv9/dbx) where
=>[1] memmove(dp = 0x5f9d6, sp = 0x5f9d8, n = 1U), line 106 in "unix.c"
  [2] foldline(s = 0x5e218), line 508 in "lex.c"
  [3] gettokens(trp = 0xffbee5fc, reset = 1), line 388 in "lex.c"
  [4] process(trp = 0xffbee5fc), line 54 in "cpp.c"
  [5] main(argc = 13, argv = 0xffbee674), line 38 in "cpp.c"

and on completion, reports these leaks:

Checking for memory leaks...

Actual leaks report    (actual leaks:       539  total size:    3114 bytes)

 Total  Num of  Leaked      Allocation call stack
 Size   Blocks  Block
                Address
======  ====== ==========  =======================================
  2153     431      -      domalloc < newstring
   401      89      -      domalloc < setsource
   288       6      -      domalloc < maketokenrow
   192      12      -      domalloc < dodefine
    80       1    0x5dd60  growtokenrow < gettokens < setup < main


Possible leaks report  (possible leaks:     244  total size:     902 bytes)

 Total  Num of  Leaked      Allocation call stack
 Size   Blocks  Block
                Address
======  ====== ==========  =======================================
   902     244      -      domalloc < newstring

Checking for memory use...

Blocks in use report   (blocks in use:      357  total size:   43145 bytes)

 Total  % of Num of  Avg     Allocation call stack
 Size    All Blocks  Size
======= ==== ====== ======  =======================================
  32772  75%      1  32772  domalloc < setsource < setup < main
   4048   9%     74     54  domalloc < maketokenrow
   2064   4%     86     24  domalloc < lookup
   1184   2%     74     16  domalloc < normtokenrow
   1136   2%      1   1136  growtokenrow < gettokens < process < main
    664   1%     88      7  domalloc < newstring
    624   1%      1    624  calloc < _tzload < _ltzset_u < localtime_u < ctime < main
    200  <1%     23      8  domalloc < newhideset
    156  <1%      1    156  calloc < _tzload < _ltzset_u < localtime_u < ctime < main
    124  <1%      1    124  newhideset < expand < expandrow < substargs < expand < expandrow < process < main
     36  <1%      1     36  calloc < _tzload < _ltzset_u < localtime_u < ctime < main
     36  <1%      1     36  _strdup < _tzload < _ltzset_u < localtime_u < ctime < main
     36  <1%      1     36  calloc < _tzload < _ltzset_u < localtime_u < ctime < main
     36  <1%      1     36  domalloc < setsource < setup < main
     13  <1%      1     13  calloc < _tzload < _ltzset_u < localtime_u < ctime < main
     12  <1%      1     12  tzcpy < getzname < _ltzset_u < localtime_u < ctime < main
      4  <1%      1      4  domalloc < iniths < main

For rcc, there are no runtime traps, and the leak report is this:

 Checking for memory leaks...

Actual leaks report    (actual leaks:         0  total size:       0 bytes)



Possible leaks report  (possible leaks:       0  total size:       0 bytes)


Checking for memory use...

Blocks in use report   (blocks in use:      184  total size: 1913840 bytes)

 Total  % of Num of  Avg     Allocation call stack
 Size    All Blocks  Size
======= ==== ====== ======  =======================================
 795256  41%     77  10328  allocate < dagnode
 473616  24%     46  10296  allocate < _label
 195624  10%     19  10296  allocate < tree
  82112   4%      8  10264  allocate < newarray
  62256   3%      6  10376  allocate < listnodes
  62256   3%      6  10376  allocate < temporary
  51920   2%      5  10384  allocate < constant
  43160   2%      3  14386  allocate < stringn
  33888   1%      3  11296  allocate < table
  31152   1%      3  10384  allocate < findlabel
  20592   1%      2  10296  allocate < code
  10384  <1%      1  10384  allocate < install < dclglobal < decl < program < main
  10376  <1%      1  10376  allocate < mkreg < progbeg < main
  10376  <1%      1  10376  allocate < genident < primary < unary < expr3 < expr2 < expr1 < call
  10304  <1%      1  10304  allocate < type < func < dclr < decl < program < main
  10296  <1%      1  10296  allocate < tnode < dclr1 < dclr < fields < structdcl < specifier < decl
  10272  <1%      1  10272  allocate < stringn < string < stringf < defsymbol2 < findlabel < listnodes < listnodes

------------------------------------------------------------------------
