From: *Henry Rich* <henryhr...@gmail.com> Date: 8 May 2016 at 08:46 To: jeng...@jsoftware.com
I am working on this old crash: r =: 2.5 (r=:3) ] r ] ] crashes. The disaster unfolds as follows: 1. The value of r has use-count 1. 2. When r is moved to the parser stack, it is added to the nvr stack, indicating that the block has a reference outstanding. 3. r=:2.5 is executed. This causes a search on the nvr stack for the data-block for r. One is found. The use-count for this block is incremented (when found on the nvr stack), and then decremented (because the reassignment of the name reduces the number of references to the block). The nvr stack is also marked, indicating that the increment was performed, because this increment must be undone later. Use-count is still 1. 4. The sentence completes. The nvr stack is processed, decrementing the use-count of the original r-block to 0, and it is freed. 5. The result of the sentence is now a verb containing a reference to a freed block. If that is referenced, for example for display, J crashes. One thing is clear: nvrpop must not be performed in the parser. The result of the parser might end up being the result of an explicit entity. I was thinking that every caller to the parser (there aren't many) should be required to call nvrpop at the appropriate time. Then I wondered whether the call should be moved into tpop somehow. Then I decided to ask for help. Help! Henry ---------- From: *Henry Rich* <henryhr...@gmail.com> Date: 8 May 2016 at 14:35 To: jeng...@jsoftware.com I think the best solution is this: instead of calling fa() directly, nvrpop will move the blocks-needing-free to jt->tstack by calling tpush(). That's all. There will always be a subsequent tpop() that will free the blocks. This seems bulletproof. It will let reassigned names live a little bit longer, as they need to. Henry ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
