OI 7.0.1 / UD 3.0

I have been getting reports from users for a few months now that OI is crashing unexpectedly.

There does not seem to be any rhyme or reason to what OI is doing before it crashes. Here is a list of some of the types of processes that have been running when the crash occurs:

- RLIST selects

- BTREE Extracts

- Data entry windows

- OS Write to text file

Yesterday seemed to be an exceptionally heavy day for this to happen. It happened to myself and another programmer on my team. It also happened to two users within a few hours of each other.

The only times I recall this happening to me in the past were when I opened IE (6.0), but I didn't open IE yesterday and haven't really noticed that issue in quite some time.

I checked the event viewer of the server and noticed an exceptional number of (nondescript) linear hash errors yesterday, but the timing of those errors did not coincide with the time that OI crashed on the desktop.

We have ruled out that it's a workstation issue. The users that were reporting the problem are all in one department and had the same HP workstations, but we swapped a few out with Dells and they are still experiencing the issues. I believe it has also happened while they are doing RDP sessions to one of our terminal servers.

I was just curious if anyone else has experienced this and, if so, what the resolution was? We will be upgrading to 7.2.2 within a few weeks, so I am hopeful that that may resolve the issues, but if there's something I can do in the interim, that would be helpful.

TIA

Chip

Chip,

I don't know if this is related but I have a customer experiencing problems with oinsight.exe being left in memory after exiting. Sometimes Windows would report that Oinsight has caused a problem and needs to shut down… The client is using UD 3.0 on Novell. I installed the UD 4.0 client (included in OI 8.03) and all those problems went away. Perhaps you should upgrade to 8.03 instead of going to 7.22.

HTH,

John

I certainly get OI to crash when IE6 is opened, at least perhaps one in 10 times.

I suspect that something in memory is causing a trash of some OI stuff. Maybe the functions you are performing is using up a load of memory and perhaps a garbagecollect, or flush or other memory cleanup might resolve. If you are using a load of common variables, and pumping a load of data into them, it might be worth setting these variables to null when the form is closed, unless you are using freecommon.

Colin

Wow - this was one heck of an issue to troubleshoot. Thanks to Colin and John for your replies.

We finally traced it to a line in a program that called the INLIST() function. It was causing a Dr Watson error and closing the APP. Not every time - but often enough.

We didn't drill down too much once we identified what was causing it, but it seems that it might have had something to do with the variable being searched not being INLIST.

Hope nobody else comes across this, but just in case I figured I would post the resolution.

Could this be the RCL4.Dll version problem? Versions of this DLL were found to be responsible for the .EXEs getting stuck in memory. You can get the proper version from Rev. I believe installing the UD4 driver installs the proper version of the DLL.

Not that it does much good now, but there were known problems with INLIST and it was recommended not to use it. I thought it was fixed ages ago, for 4.x, but as a rule, I don't use that opcode.

Sorry .. but that just isn't right. If it is in the system then it should work. Yes?

You are exactly right.

Thanks,

John

I believe the word you're looking for is 'bug' :)

'Undocumented feature'

I don't recall this being an issue, but we'll take a look at it for 8.1 and see if we can fix it without breaking anything else…

Mike

I think it moves more into the realm of lore than anything else, to be honest. See this post] from Cameron back in 1998. I heard it had been fixed as part of one of the 4.x releases, but I've still been wary of it, which is a shame, since it's a great and very useful opcode.

FWIW, I just tested it with a small list in 8.1, and it worked. I tested for both an item I knew was in the list, and one I knew wasn't- both worked as expected.

Mike

That is great news as we do use it. I love "sets" I grew up with that new math

I'll give it a good try then. There have been plenty of times when I'd prefer to have used inList rather than anything else.

Since the suggestion section is temporarily offline right now, can I suggest here that for 8.1 an inListC, for case-insensitive inList be added?

Interesting - inlist is littered throughout our app and we have a huge problem with intermittent crashes.

I'm replacing all occurences of inlist() now (with a custom version, since much more work to rewrite case statements to use a locate… stmt). Hopefully we can get it to customer to test soon and see if it takes care of the problem.

Regret to say that we still seem to have an inlist problem. We have been experiencing intermittent problems with OI crashing out of memory altogether when running long reports. Problem analysis points the finger firmly at inlist - as in the error log's last line is "Entering InList" - when it exits cleanly it adds "Exited Inlist". In this case OI just disappeared entirely from memory.

This happens randomly - in this case it was about the 50,000th iteration - all the others having been trouble free.

The Sprezzatura Group

World leaders in all things RevSoft

I am (sort of) glad to hear that. We also were using inlist() quite a bit and have several users complaining of this behavior. I have just completed an update that replaces all occurences with our own pgm instead (to keep it a function call), which in turn uses locate by to determine the answer. I am now trying to get them all upgraded and hope this does solve their issues.

View this thread on the Works forum...