#62 Rel 3.1.1 to Run on Windows 7 64 bit

Windows
closed
Interpreter (8)
complete
7
2013-01-19
2012-04-10
No

Bug ID 3405740 has been open for 7+ months now with no resolution in sight. I do realize that this may be difficult problem to find because of it's randomness and the actual bug occurs long before it is detected. Releases 3.1.2 thru 4.1.0 (32 & 64 bit) have all demonstrated this problem. Release 3.1.1 does not seem to have the problem and runs fine on my 32 bit OS. Unforunately Release 3.1.1 does not run on Windows 7 64 bit OS due to Bug ID 1630937. This was fixed in 3.1.2. Is it possible to get a special version of 3.1.1 (32 bit) with just the 1630937 fix?

I have yet to get my Windows 7 64 bit machine to live up to it's potential because I cannot get a reliable version of ooRexx (either 32 or 64 bit) to run on it. I need to use ooRexx so that I can replace existing applications that run on my 32 bit system that do not run on Windows 7 and their authors have long since disappeared into the woodwork. These applications do extensive work with file/folder structures for entire drives that should be available using SysFileTree. And in fact I have been able to successfully emulate their functionality using ooRexx apps running on Release 3.1.1.

I am willing to work with whomever to make this happen. I just don't have the OS experience level to implement the fix for 1630937 on my own nor do I know where to start. I also realize that any result would only be a 32 bit version of ooRexx.

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2012-04-11

    Jerry, I sympathize with you, but there is not much more we can do at this point.

    There is no doubt a bug in SysFileTree(). We have reports of it crashing, or behaving oddly, on every major OS. At some point, if none of the other developers fixes it, I'd like to rewrite the function using the C++ APIs which should make the code for setting the stem variable easier to understand. Unfortunately, there are really a lot of things I'd like to do and this is low on my list.

    It seems likely to me that the bug exists in 3.1.1, you just haven't hit it.

    Since you aren't able to get the bolt unscrewed using a hammer, maybe you should try another tool, like a wench.

    Perhaps use a Windows command line tool that searches files and directories and use ooRexx to parse the output. There is a Gnu 'find' for Windows, or even 'dir /s' might work.

    Alternatively, you could try breaking up the SysFileTree work into smaller portions. Recursively descend into the sub directories, use SysFileTree to search the lower levels, and combine the results.

     
  • Mark Miesfeld

    Mark Miesfeld - 2012-07-08

    Closing this as there has been no activity for 4 months.

     
  • Mark Miesfeld

    Mark Miesfeld - 2012-07-09

    Apparently I was not explicit enough in my original repsonse to this support request and Jerry felt I was not justified in closing it.

    As I see it, the request was:

    "Release 3.1.1 does not seem to have the problem and runs fine on my 32 bit OS. Unforunately Release 3.1.1 does not run on Windows 7 64 bit OS due to Bug ID 1630937. This was fixed in 3.1.2. Is it possible to get a special version of 3.1.1 (32 bit) with just the 1630937 fix?"

    1.) Although 3.1.1 appears to work on your system, we have anecdotal evidence that the bug goes back to IBM Object Rexx as several people on the RexxLA mailing list have reported having very similar problems with SysFileTree crashing whenever they used it with large directory trees. Because of this I think it is likely that the bug does exists in 3.1.1 and you have just not hit whatever fluke it is that triggers it.

    2.) The fix for 1630937 is non-trivial. To back port it to 3.1.1 is a substantial amount of work, with no guarentee that it would solve the problem to begin with. It is not a good use of my time, so I am not willing to do it.

    3.) Realizing that I don't speak for the other developers, I left the request open for several months. However, since I do the Windows builds, I know that if I was unwilling to do it, it is highly unlikely that one of the other developers would feel it was worth doing. When no one came forward to say they might do it, I felt correct in my assumption, so the request was closed.

    So - to be explicit here. I am not going to do a special build. It is highly unlikely that one of the other developers will either.

    We know there is a bug in SysFileTree. It is regrettable that the bug remains open, but I have spent dozens of hours trying to reproduce the crash, and have not been able to. Without a way to reproduce the crash, the bug has to remain low on my list of priorities.

    I'll leave this request open for now. But, several months from now as I scroll through the open tracker items, if no one else has responded, I'll surely close it again.

     
  • Jeremy C B Nicoll

    Am I missing something here? Mark says:

    "We know there is a bug in SysFileTree. It is regrettable that the bug remains open, but I have spent dozens of hours trying to reproduce the crash, and have not been able to. Without a way to reproduce the crash, the bug has to remain low on my list of priorities."

    which is fair enough. But the OP presumably can reproduce the crash. Would it not be more useful to put some time into providing him with some help in generating a trace (or profile or whatever debugging is possible for C) of the SysFileTree code's execution path, or something?

     
  • Mark Miesfeld

    Mark Miesfeld - 2012-07-21

    Jerry, I've started the work to convert SysFileTree to use the new native API. While this may not be in and of itself enough to fix the bug, it will greatly reduce the code complexity of the current implementation. In addition, I will understand the code much better having gone through it line by line.

    If you are serious about helping, the absolute best thing you can do would be to write an ooTest group to test SysFileTree.

    Any one that can install ooRexx and write a simple Rexx program can write a test group. All it takes is a little effort.

    I'll give you all the help you need to get started writing a test group, but I want to do it in a conversation on the ooRexx User list, so that others will see the conversation and it will perhaps encourage others to try writing test groups.

    You can subscribe to the list, if you aren't already, at:

    https://sourceforge.net/mail/?group_id=119701

    You could also down load the Quick Start guide from the repository by going to:

    http://oorexx.svn.sourceforge.net/viewvc/oorexx/test/trunk/doc/ooTestQuick.pdf?view=log

    and clicking on the down load link in:

    Revision 4680 - (view) (download) (as text) (annotate) - [select for diffs]

    which should give you an idea about what is involved in writing a test group.

    If the current SysFileTree code is changed we will need to test it well before it is released. By contributing a good test group for SysFileTree() you will greatly speed up the process of getting a fix released. At the same time you will demonstrate your willingness to help with things that are within your experience and skill level.

    Simply post a message to the User list and state where you need help to get started. E.g., you have no idea what a test group is, or you know what a test group is - where to start, or you have the test framework installed on your system - now what, etc..

    Jeremy - I read your post of course when you wrote it. I didn't reply because I didn't want to get into a long debate about it. The short answer is that trying to debug a difficult problem on a remote system that I have no access to, other than written communication with someone I don't know well, is way beyond my skills. Because of this, I consider the probablity of success low and time spent on it probably wasted.

     
  • Mark Miesfeld

    Mark Miesfeld - 2012-07-24

    Jerry,

    I have coded a second implementation of SysFileTree that eliminates some
    possible causes of access violations. In my testing it produces the same
    results as the original implementation.

    Since I can't produce the crash to begin with, I have no way to tell if
    this actually fixes things.

    I have a debug verison of the Windows installation package built that
    contains both a SysFileTree() and a SysFileTreeB(), wtih SysFileTreeB()
    being the new implementation.

    If you could test this build we can see if you still get access violations
    with SysFileTreeB(). E-mail me to get instructions on how to get the debug
    package.

    Thanks.

     
  • Mark Miesfeld

    Mark Miesfeld - 2013-01-19
    • status: open --> closed
    • assigned_to: Mark Miesfeld
    • pending_work_items: --> complete
     
  • Mark Miesfeld

    Mark Miesfeld - 2013-01-19

    Closing this.

     


Anonymous

Cancel  Add attachments