Topic
  • 2 replies
  • Latest Post - ‏2013-04-16T14:45:07Z by llandale
EHcnck
EHcnck
78 Posts

Pinned topic Allocated Object not being full deleted

‏2013-04-15T22:05:19Z |

Hello,

I cannot figure out why all allocated object aren't being fully deleted.  Depending upon which module you run the script against you get a different number of remaining allocated objects.  Right now I'm just running the script then exiting the dialog box.  I was able to figure out some logic errors for why certain object weren't being deleted.  I think it has to do with my skip list of skip lists not being freed correctly any help would be wonderful. Thank you.

-Jim

Attachments

Updated on 2013-04-16T14:46:16Z at 2013-04-16T14:46:16Z by EHcnck
  • llandale
    llandale
    2972 Posts

    Re: Allocated Object not being full deleted

    ‏2013-04-16T14:33:19Z  

    Allocation Bugs:

    1. At line #229 I see you "continue" without actually "delete otherVersion".  Ditto line #934
    2. At line #580 I think you want to delete "sVersion" instead of "otherVersion"
    3. At line #597 I think you want to delete "tVersion" instead of "sVersion" which is already deleted at line #588.  Ditto a few following lines.

    Other Bugs:

    1. You can only use "tempStringOf" in two general cases: [1] you "Dispose of" or you [2] "Abandon" the string  before you use the Buffer again.  You cannot "Store" such a string.
      At lines #779 and #815 you are "Storing" the string in the Skip and you can fully espect the string in the Skip to be modified every time you subsequently modify the original Buffer (buffLine).  This is a serious error although I could not trace down what the symptoms would end up being.  Put the "stringOf(buffLine)" into the Skip.
      ... [1] "Dispose of" includes print, output to a file, set a DBE, and set an attribute value.
      ... [2] "Abandon" includes using the string in a "length" or "findPlainText" statement or an "if" statement.
      I think if you delete the buffer and THEN access the strings in the Skip, you can get exception violations.
    2. Bug: Your "object_" function will return the last "o" in the module if the absno isn't found.  [] replace "break" with "return(o)"; [] replace "return(o)" at the bottom with "return(null Object)".

    Other Responses:

    1. I cannot tell for sure if I'm right here, but I THINK you use function "object_" on "trgAbsNo" of objects that are NOT in module "m" (such as line #378).  I think you (at line #447) insert trgAbsNo into (linkSetListView, ln, 3) using the "Absolute Number" from "othero" which presumably is in some other module.
    2. I THINK your use of variable "cnt" in function "memoryCleaner" is incorrect.  At line #120 I think you want "if (cnt-1>0" instead of "if(--cnt > 0".  In any event, this function would flow better if you inserted this at line #115: "if (DataBaseModule != m)"; that would resolve any "cnt" issue that seems to be there (but perhaps is not).
    3. Something like this inserted after line #62 would be VERY beneficial:
      if (null m) then{ack("Run from open module"); halt}
      ... and I wonder if also this:
      if (!isEdit(m)) then {ack("Run from EDITED module"); halt}
    4. I cannot tell by reading what your code is doing.  But I think it is deleting Links.  If so, line #153 "downgrade(m)" doesn't seem useful and in any event violates some natural law of the universe.
    5. I think you want to add "\n" after all the "print allocatedObjects()" statements.
    6. Consider adding function <<void PrintAllocs(string Label){if (Debug) then print allocatedUnits "\t" Label "\n"}>>; and then just call that function throughout.
    7. Seems to me you would want to print # allocated objects at the start of your main functions and also at the end; not just at the end.
    8. My intuition says you have "flushDeletions" in the wrong place although I cannot rationally defend it.
      My nagging memory says "flushDeletions" is a "current Module" thing, although I cannot find any evidence of that.
      My Mom says use "flushDeletions" before you "save" a Module .. and she says to "save" a Module after "flushDeletions".  However my Mom cannot even spell "DXL" so what does she know.
      My Psycoanalyst says Louie has "flushDeletionsPhobia".  Maybe you should ignore this whole point.

    -Louie

  • llandale
    llandale
    2972 Posts

    Re: Allocated Object not being full deleted

    ‏2013-04-16T14:45:07Z  
    • llandale
    • ‏2013-04-16T14:33:19Z

    Allocation Bugs:

    1. At line #229 I see you "continue" without actually "delete otherVersion".  Ditto line #934
    2. At line #580 I think you want to delete "sVersion" instead of "otherVersion"
    3. At line #597 I think you want to delete "tVersion" instead of "sVersion" which is already deleted at line #588.  Ditto a few following lines.

    Other Bugs:

    1. You can only use "tempStringOf" in two general cases: [1] you "Dispose of" or you [2] "Abandon" the string  before you use the Buffer again.  You cannot "Store" such a string.
      At lines #779 and #815 you are "Storing" the string in the Skip and you can fully espect the string in the Skip to be modified every time you subsequently modify the original Buffer (buffLine).  This is a serious error although I could not trace down what the symptoms would end up being.  Put the "stringOf(buffLine)" into the Skip.
      ... [1] "Dispose of" includes print, output to a file, set a DBE, and set an attribute value.
      ... [2] "Abandon" includes using the string in a "length" or "findPlainText" statement or an "if" statement.
      I think if you delete the buffer and THEN access the strings in the Skip, you can get exception violations.
    2. Bug: Your "object_" function will return the last "o" in the module if the absno isn't found.  [] replace "break" with "return(o)"; [] replace "return(o)" at the bottom with "return(null Object)".

    Other Responses:

    1. I cannot tell for sure if I'm right here, but I THINK you use function "object_" on "trgAbsNo" of objects that are NOT in module "m" (such as line #378).  I think you (at line #447) insert trgAbsNo into (linkSetListView, ln, 3) using the "Absolute Number" from "othero" which presumably is in some other module.
    2. I THINK your use of variable "cnt" in function "memoryCleaner" is incorrect.  At line #120 I think you want "if (cnt-1>0" instead of "if(--cnt > 0".  In any event, this function would flow better if you inserted this at line #115: "if (DataBaseModule != m)"; that would resolve any "cnt" issue that seems to be there (but perhaps is not).
    3. Something like this inserted after line #62 would be VERY beneficial:
      if (null m) then{ack("Run from open module"); halt}
      ... and I wonder if also this:
      if (!isEdit(m)) then {ack("Run from EDITED module"); halt}
    4. I cannot tell by reading what your code is doing.  But I think it is deleting Links.  If so, line #153 "downgrade(m)" doesn't seem useful and in any event violates some natural law of the universe.
    5. I think you want to add "\n" after all the "print allocatedObjects()" statements.
    6. Consider adding function <<void PrintAllocs(string Label){if (Debug) then print allocatedUnits "\t" Label "\n"}>>; and then just call that function throughout.
    7. Seems to me you would want to print # allocated objects at the start of your main functions and also at the end; not just at the end.
    8. My intuition says you have "flushDeletions" in the wrong place although I cannot rationally defend it.
      My nagging memory says "flushDeletions" is a "current Module" thing, although I cannot find any evidence of that.
      My Mom says use "flushDeletions" before you "save" a Module .. and she says to "save" a Module after "flushDeletions".  However my Mom cannot even spell "DXL" so what does she know.
      My Psycoanalyst says Louie has "flushDeletionsPhobia".  Maybe you should ignore this whole point.

    -Louie

    My numbered lists looked correct while I was writing them.

    Don't advertise the port@server of your databases.  Don't tell me they are "safe behind the fire wall" and "login protected" ... trust me they are not.  Or more truthfully "trust MM they are not".

    -Louie