#426 Open Object Rexx Interface Error - RxWinExec

v4.0
closed
5
2012-08-14
2007-10-03
Anonymous
No

Occasionally, will encounter an "Open Object Rexx Interface has encountered a problem and needs to close" error. The error occurs when calling RxWinExec to display a PDF file with SumatraPDF.exe. When using my application in a 1 hour period, I will experience this between 2-3 times.

Open Object Rexx 3.1.2 on Windows XP SP2 (upto date on hotfixes and security patches).


::method Open / Open the PDF file /
expose pdffile
parse arg pdffile
if self~IsPDF = -1 then return -1
rc = RxWinExec('SumatraPDF\SumatraPDF "'pdffile'"')
if rc < 32 then do
call ErrorDialog SysGetErrorText(rc)
return -1
end
return 0


Attached are screenshots of the error messages and the debug information from the DrWatson log.

Discussion

  • Nobody/Anonymous

    Error screenshots and DrWatson logs

     
  • rffrexx

    rffrexx - 2007-10-03

    Logged In: YES
    user_id=1209735
    Originator: NO

    Updating ticket to include my sourceforge username.

     
  • Lee Peedin

    Lee Peedin - 2007-10-03

    Logged In: YES
    user_id=1223125
    Originator: NO

    I tried your code using Acrobat 6.0 and did not encounter the problem. I did; however, encounter an issue with the maximum number of pdf files that can be opened by Acrobat. It did not "bomb" ooRexx, but it did freeze the application. I was trying to open 78 pdf files back to back and Acrobat seems to have a limit of around 20 that can be opened at any given time. I will download and test SumatraPDF later today and see if I can duplicate the issue.

    During the 1 hour period are you closing SumatraPDF between each document or are all your "used" documents still open?

    Lee

     
  • Nobody/Anonymous

    Logged In: NO

    Lee,
    SumatraPDF is being closed between documents.

     
  • Lee Peedin

    Lee Peedin - 2007-10-04

    Logged In: YES
    user_id=1223125
    Originator: NO

    I didn't get a chance to down load and try SumatraPDF today (one of "those" days). I did; however, run another test with Acrobat and was able to open 79 pdf files back to back by closing Acrobat after each document.

    Will report back my finding with SumatraPDF, probably on Thu.

    Lee

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-10-04

    Logged In: YES
    user_id=191588
    Originator: NO

    Robert (and Lee),

    I intend to look into this as soon as I get a chance. But, it won't be until this weekend at least and probably not until I wrap up what I need to do for 3.2.0.

    Lee, if you do reproduce this with a short program, please attach it. Instructions for getting the PDF reader would be nice too. <grin>

     
  • rffrexx

    rffrexx - 2007-10-04

    Logged In: YES
    user_id=1209735
    Originator: NO

    Lee and Mark,
    Since I can reproduce this condition with SumatraPDF, I can modify the code to call Adobe Reader 8.1 (the version I have installed). I will then give the app a workout. If this condition still occurs, I will try calling the XP "start" command in place of RXWinExec. Then put the app through its paces, once again.

    I should be able to run through this drill over the weekend.

     
  • Lee Peedin

    Lee Peedin - 2007-10-04

    Logged In: YES
    user_id=1223125
    Originator: NO

    Robert/Mark,
    I ran the following code for 1 hour - 5481 iterations without error.

    I downloaded and used this program.
    http://blog.kowalczyk.info/software/sumatrapdf/

    I ran this on a Win2K system with ooRexx 3.2 Rev 853 - didn't want to tie up my working WinXP system that long.

    Without knowing what Robert was doing with each PDF, I simply used 'taskkill' to kill each iteration.

    One other note: I specified the full path to both the program and the PDF.

    Lee

    / Bug1806681.rex /
    call SysCls
    start_msm = time('m')
    say 'Started At' start_msm
    end_msm = start_msm + 60
    pdffile = 'c:\bug1806681\oorexxtry32.pdf'
    obj = .OpenPDf~new
    ctr = 0
    do until time('m') >= end_msm
    ctr = ctr + 1
    say 'Executing Iteration..:' ctr '@' time('m') 'Stop At' end_msm
    obj~Open(pdffile)
    end

    ::class OpenPDF
    ::method Open / Open the PDF file /
    expose pdffile
    parse arg pdffile
    if self~IsPDF = -1 then
    do
    say 'IsPDF Failed'
    return -1
    end
    rc = RxWinExec('c:\program files\SumatraPDF\SumatraPDF "'pdffile'"')
    say rc
    if rc < 32 then
    do
    say 'RxWinExec Failed' SysGetErrorText(rc)
    return -1
    end
    call SysSleep(.5)
    'taskkill /PID' rc
    return 0

    ::method IsPDF
    expose pdffile
    p_stream = .stream~new(pdffile)
    if p_stream~query('exists') = '' then
    return -1
    return 0

    /*
    Last part of Results
    Executing Iteration..: 5841 @ 540 Stop At 541
    444
    SUCCESS: The process with PID 444 has been terminated.

    C:\Bug1806681>
    */

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-10-11

    Logged In: YES
    user_id=191588
    Originator: NO

    Robert,

    I took a stab at reproducing this and couldn't. Looking at the RxWinExec code, I don't see anything that looks like it would cause a crash.

    If you have an example program that can reproduce the crash, please attach it with intstructions on the exact steps needed to reproduce the crash. Thanks.

     
  • Mark Miesfeld

    Mark Miesfeld - 2007-10-12

    Logged In: YES
    user_id=191588
    Originator: NO

    Robert,

    I took a stab at reproducing this and couldn't. Looking at the RxWinExec code, I don't see anything that looks like it would cause a crash.

    If you have an example program that can reproduce the crash, please attach it with intstructions on the exact steps needed to reproduce the crash. Thanks.

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-04-28

    This bug was fixed by commit 4371.

    RxWinExec() had a bug in its argument validation code. Arg 2 is optional, but the validation would dereference the arg 2 pointer as long as the value was not null. This worked as long as memory at that point was zeros, but crashed otherwise.

    Interestingly, to me, the orignal opener of this bug included a Dr Watson report, which shows the crash was right in this validation routine. When you match the Dr Watson report with the ASM listing produced for the release build, you can clearly see that the crash was in the validation routine.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-02-22

    The fix for this item was in the 4.0.0 release.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks