64-bit OOREXX 5.0.0 build 11841 on Windows 10
Calling SysFileSearch can cause the entire OOREXX process to crash without displaying any error messages. To reproduce the issue:
OOREXX crashes consistently on my computer with both the production and this simplified test set. Interestingly enough, both files must be present before the crash will occur: deleting either file will allow the program to succeed. Processing many other combinations of files in a test directory will also cause OOREXX to crash for me. Whatever is causing the crash isn't just caused by the specific content of the files read by SysFileSearch. Other similar content is also apparently causes issues.
Please let me know if you need anything else. Similar crashes also happened with builds 11806, 11813, and 11840 although I have not tested any of them against this specific set of test files. They all did, however, crash OOREXX using the full set of 95 files currently of need of scanning prior to the startup of my application.
Thank you, Mark
Anonymous
Unfortunately, this is not crashing for me.
Well crud. It happens every time for me. I just rebooted (actually, I always have to reboot between versions sometime after 11740 because it says it can't stop RXAPI even though the service was really stopped) and reinstalled 11841 without doing the quick upgrade - I deleted the tree and started completely over. I don't run any other software at all, just the test62.rex program and I get the attached crash every time. Even after a fresh reboot before testing.
Now what? Do I need to build the Visual Studio test environment to capture the crash and send it to you? Can I get some help with that? Do you want me to try sending a bigger set of files? And if so, can I send them to just you so I don't have to worry about sanitizing all of them first?
I have to fall back to 11740 for development since that's the last release I have where this works for me.
Please advise, Mark
Mark,
Installing visual studio and capturing debug information would certainly be
helpful. Sending the full set of files would also be useful. I am leaving
on my trip on Monday and this weekend is going to be pretty hectic, so I
doubt I'll have an opportunity to help with this. Maybe Erick can help you
get setup and/or take a look at debugging the problem.
Rick
On Fri, Mar 15, 2019 at 6:46 PM Mark Harsen mharsen@users.sourceforge.net
wrote:
Related
Bugs:
#1610Code committed [r11482]
Erich's post about commenting out one line might have given me the answer. I definitely fixed a couple of problems with the code that reads on the next buffer of data that would cause some buffer overruns that would result in random traps. I hope this fixes all of the problems.
Related
Commit: [r11482]
Last edit: Rick McGuire 2019-03-16
Additional fix committed [r11483]
Related
Commit: [r11483]
Committed revision [r11844] - this should fix the reported issues
Related
Commit: [r11844]
Thank you Rick and Erich! Build 11844 gets past the previous crash and appears to produce proper results from my limited testing this morning. I will perform further testing and let you know if anything else untoward occurs, but it looks very good!
Sincere Gratitude, Mark
P.S. Rick, have a great trip!
I found another issue with 11844 SysFileSearch. A successful execution is not setting a numeric return code of zero ("0") but is returning an empty string instead.
The above program displays "{}" since Rc contains an empty string. The stem List. contains the proper values including List.0 having the correct number of items.
Let me know if you prefer another bug report instead of updating this one.
Thanks, Mark
Please open a new bug report.
Rick
On Mon, Mar 18, 2019 at 6:34 PM Mark Harsen mharsen@users.sourceforge.net
wrote:
Related
Bugs:
#1610Committed revision [r11847] for another attempt to fix the issue.
Added more tests
Updated rexxref
Related
Commit: [r11847]