[Oorexx-bugs] [ oorexx-Bugs-3554117 ] Access violation in rexxhide.exe or rexx.dll

[SourceForge.net <no...@so...>]

Bugs item #3554117, was opened at 2012-08-03 15:01
Message generated for change (Comment added) made by jeremynicoll
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3554117&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeremy C B Nicoll (jeremynicoll)
Assigned to: Nobody/Anonymous (nobody)
Summary: Access violation in rexxhide.exe or rexx.dll

Initial Comment:
An exec that I run most days just crashed at or near the end of its processing.  In its final work before stopping it writes data to a logfile - which worked, as did all the real processing it did before that, then uses RxMessageBox() to display a final summary message - having used the same function many times while running.  On this occasion the final summary message was not displayed in a message box, but XP (Pro SP3) reported rexxhide had ended.  Dr Watson files are attached, in case they help.      As the exec runs most days, and this does not normally happen, I have no idea how to recreate the problem. 

----------------------------------------------------------------------

>Comment By: Jeremy C B Nicoll (jeremynicoll)
Date: 2012-08-04 11:03

Message:
Hi Mark.   The exec that crashed was going through standard exit processing
which culminates in:

if log.0 > 0 then do
   call l "ending; began:" log.0sta || ","   ,
               "logstart:" log.0lr1 || "."
   call l "."                  /* append marker to chunk of log lines */
   /* By opening a log in a SHARED mode, we let this exec update logs */
   /* even if they are open in, for example, a 'tail'-capable viewer. */
   openit = stream(log.0fil,"COMMAND","OPEN WRITE APPEND SHARED")
   if openit \== "READY:" then do
      say g.0eleaf "could not open" log.0fil
      say " err:" openit
      say
      say "so here's the lines ("log.0") meant to be logged:"
      say
      do oo = 1 to log.0
         say log.oo
      end
      say
      g.0saids = .true
   end
   else do
      do oo = 1 to log.0
         call lineout log.0fil,log.oo
      end
      shutit = stream(log.0fil,"COMMAND","CLOSE")
   end
   drop log.
   log.0 = 0
end


if msg.0 > 0 then do
   titl = "Final message from:  " g.0eleaf      /* note extra spaces */

   icon = "INFORMATION"                             /* noisy!        */
   icon = "QUERY"                                   /* quiet         */

   text = ""
   do mm = 1 to msg.0
      text = text || msg.mm || d2c(10)           /* insert linefeeds */
   end

   show = RxMessageBox(text,titl,,icon)
end


if g.0saids then do
   say
   say "*** Hitenter..."
   parse pull hitenter
   say
end

exit



and had successfully written the whole of the log out to the log file.  The
content of the log looks good.  (The exec had been scanning through a set
of podcasts doing things to them, so it's easy to tell that the log is good
because it shows successive actions to a set of files.  Also one of those
actions was to re-tag and move them from one folder to another and they did
all get moved ok.     The stem "msg." would have been expected to contain
at least one line of text - the final summary of actions message - and that
should have been presented in a message box by the exit code just after the
log file got written out.   It never appeared.   I've never seen it not do
so before, in either this exec or any of the others that use the same
standard exit code, 

I did look back in the event logs (I have process start/stop logged in
'Security' logs) to check that the dump, which happened for pid=1492,
really was for the exec which was doing the podcast manipulation... it was.
 This was easy to verify because that exec calls several CLI tools to do
MP3 ID3 tag extraction & manipulation in the podcasts and each of these CLI
processes being started showed they had pid=1492 as their parent process. 


Scheduled tasks runs rexx execs more or less all the time, so the fact that
something else was running is no surprise.  It's most likely to be the code
that looks for creation of DrWatson dumps, every few seconds.  [Because XP
only ever keeps a single .dmp file with the most recent dump in it (though
it keeps a log file with summary dump info for multiple dumps), I like to
have .dmp files and .log files moved elsewhere as soon as they're created;
the files get renamed according to the time of the dump, pid etc from text
extracted from the log files.  It's not perfect but better than XP's
default behaviour.  I wrote something similar but much more complex for a
bank's MVS systems a while ago.]

Fortunately the log file for the thing that looks for DrW dumps does itself
log the pid that that exec runs under, each time it runs... and it was the
one running with pid=2516 as mentioned in the list of processes in the DrW
file.   And it worked properly, archiving the log files as required...

None of my rexx execs communicate with each other.

I wasn't expecting the DrW files to have much/anything that's useful,
because I've learned that seems to be the case pretty much always. 
Nevertheless I feel like I should provide them  in case one day they turn
out to be useful to someone.

I know there's nothing to go on, except a violation type and an offset...

 
.



----------------------------------------------------------------------

Comment By: Mark Miesfeld (miesfeld)
Date: 2012-08-03 20:55

Message:
Jeremy, the DR Waston files don't help a lot.

What does the Rexx script that was running look like?  Can you tell from
the log being wrtiten that it was completely written?

From the Dr. Watson log, there were 2 separate Rexx programs running at the
time of the crash.  What was the other program doing?  Did you have any
communication going between the 2 programs, or where they completely
separate?

----------------------------------------------------------------------

Comment By: Jeremy C B Nicoll (jeremynicoll)
Date: 2012-08-03 15:05

Message:
Event log record says:  Faulting application rexxhide.exe, version
4.1.1.7797, faulting module rexx.dll, version 4.1.1.7797, fault address
0x00039903.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3554117&group_id=119701