Menu

#593 Crashes during execution with TRACE ?I

v4.0
closed
APIs (66)
5
2012-08-14
2009-03-29
Jim129
No

I'm unable to isolate the particular problem. It seems to execute statement 240 in DAClientSetup and then crash. It does this on 3.2.1 as well. I'm running the 64-bit beta built on 2/16/09. To reproduce this, unzip the attached file into a directory called DADumpAnalyzer-MIS. Then enter REXX DAClientSetup.REX. There's a lot of extra software here but I chose to send all of it rather than figure out the minimum required. Right now, there's a TRACE ?I statement in DAClientSetup.REX at statement 229. When you get to statement 249, ooRexx crashes. If you comment out the lines 230-247, it runs OK.

The data need for the dialog that's displayed is shown in the .JPG file which is there as well.

Since the data is too large to attach, I'm sending a link which has the .ZIP file and the .JPG file in it. It's http://www.yousendit.com/download/UmNLcmxVMVh0QTJ4dnc9PQ

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2009-03-29

    I'll take a look at this.

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-03-29

    Jim,

    The 'finished' attribute is not intended to be used the way you are using it.

    In a completely separate unguarded thread, in the run() method, a loop is going as long as finished == 0. When finished is set to not 0, the loop is dropped out of in run() and the run() method ends. At that point, the underlying memory structures in the C / C++ code for the dialog start getting freed.

    You can't set self~finished to 1 at the top of your OK method and then set it back to 0 at some point later in your OK method. Well you can, but you are likely to cause things to crash. <grin></grin>

    What happens is: at some point as your code is working its way through the OK method, the run() method checks the finished attribute, sees that it is 1 and quits. The C / C++ code starts freeing the backing structures for the dialog, and you crash.

    (Or you might not. If you luck out and set self~finished back to 0 before it is checked in run() you will probably be alright. If self~finished stays at 1 and all the code in your OK method finishes executing before the underlying memory is freed, you would also be okay. But, if you don't crash it is pure luck.)

    You need to redo the logic of the OK method. Instead of using self~finished at the top of your method, you could use a local variable. Something like:

    myFinished = 1
    ...
    if myFinished == 1 then
    ...
    if myFinished == 1 then
    ...

    At the end of the OK method then do something like:

    if myFinished == 1 then do
    self~finished = 1
    self~ok:super
    end
    return myFinished

    Some points about the ending of the OK method. If myFinished == 0, you are not going to end the dialog. In that case you do not need invoke the superclass OK method, you do not need to change self~finished, it stays 0. In addition, you always need to return 0 or 1 from the OK method. Be sure that myFinished is set to 0 when you want to continue the dialog.

    --
    Mark Miesfeld

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-03-29

    Jim,

    Even if you make the changes I suggested, things still crash. That doesn't make what I said wrong, you still need those changes. I'll look further.

     
  • Jim129

    Jim129 - 2009-03-29

    Thanks for the education, Mark. I knew it had to be something like that but didn't know what I was doing to cause it.

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-03-30

    Committed revision 4330.

    Jim thanks, this uncovered a bug in TRACE ?I. I suspect you had a problem with your OK method and then tried to trace it. If you make changes similar to what I mentioned, your OK method should work fine. Take out the trace statement and you should be okay.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-02-22

    The fix for this item was in the 4.0.0 release.

     

Anonymous
Anonymous

Add attachments
Cancel