Fix CodeImgObj being collected

[GoogleCodeExporter]

During ipm, the code image object (CIO) is anchored to a func & frame that 
executes and then goes away, so the code image is unlinked after its initial 
execution.  Any subsequent GC and new allocation will overwrite the CIO and all 
the functions/classes/etc it contained will no longer work.

Here's a snippet that exposes the defect in ipm:

def foo(): 
    return 42

foo()
import sys
sys.gc()
r = range(50)
foo()

The resulting error looks like (issue #103 partly in place, so error reports 
look different):

 Traceback (most recent call first):
  File "X?", line 137, in foo
  File "<ipm>", line 1, in <ipm>
  File "../lib/ipm.py", line 91, in ipm
  File "main.py", line 19, in main
  <module>.
SystemError detected by interp.c:2156

Original issue reported on code.google.com by dwhall...@gmail.com on 31 Jul 2010 at 7:56

[GoogleCodeExporter]

The potential solution of reading an image straight into C structs is dismissed 
because the structs would have to be allocated (possibly incurring a GC) which 
might take so long as to miss the data coming in from the input stream (serial 
port).

The potential solution of anchoring the complete image object in temporary 
roots is dismissed because it places an limit on the number of interactive 
statements that may be typed.

The potential solution of anchoring the complete image object in a list object 
is dismissed because it would require "import list" and the extra storage space 
of the list; RAM would be exhausted quickly.

The potential solution of reading the image into one dynamic buffer and then 
parsing the buffer into dynamically allocated structs is chosen because:
1) the buffer may be released immediately
2) the structs will be used during subsequent execution and if no links to the 
roots are formed, the structs will be collected during the next GC.

Original comment by dwhall...@gmail.com on 1 Aug 2010 at 3:57

• Added labels: Component-ipm
• Removed labels: Component-all

[GoogleCodeExporter]

Correction to the above, a solution was found that does not require as drastic 
of a change:

1) The CodeImgObj continues to serve as the buffer for incoming code images for 
ipm.
2) All COs made from the image are given a reference to the top of the 
CodeImgObj so that it isn't collected.

This fix is coded and works.  The downside is that a LARGE image object is kept 
around even if there is only one CO that needs it.

Since this defect was found during the work on Issue #103, I fixed it at the 
same time, so the changes are intertwined with #103. 

Original comment by dwhall...@gmail.com on 2 Aug 2010 at 2:32

[GoogleCodeExporter]

r526
Size before:
    main.elf  :
    section             size      addr
    .text              46988         0
    .rodata             4236     46988
    .rodata.str1.1        69     51224
    .rodata.str1.4       136     51296
    .data               2232   2097152
    .bss               12812   2099384

Size after:
    main.elf  :
    section             size      addr
    .text              47188         0
    .rodata             4400     47188
    .rodata.str1.1        69     51588
    .rodata.str1.4       136     51660
    .data               2236   2097152
    .bss               12812   2099388

Original comment by dwhall...@gmail.com on 2 Aug 2010 at 9:21

[GoogleCodeExporter]

Created recursive function, co_rSetCodeImgAddr(), to set the proper (very top) 
image address in every code object that results from a CodeImgObj during an ipm 
session.  This proper reference means the big image string is not reclaimed by 
the GC as long as there are objects that refer to the CO.

Also: Added stacksize field to the code object struct.  Using co_nlocals field 
so the image doesn't have to be re-read (in interp.c and frame.c).

Original comment by dwhall...@gmail.com on 2 Aug 2010 at 9:26

• Changed state: Started
• Added labels: Milestone-09

[GoogleCodeExporter]

r538
All tests pass.  Interactive test (from above) tested manually, passes.
Mainlined directly

Original comment by dwhall...@gmail.com on 2 Aug 2010 at 9:27

• Changed state: Fixed