Cameron…about OI App Error 0xc0000005 0x77f7d465, previously discussed (and submitted, but not accepted, into the earlier thread)

We have had a long period without this error occurring. And when it occurs it tends to be benign – namely not inhibiting other requests to OICGI.

We now have some new information on the OICGI Application Error on NT and have been able to reproduce it consistently. That is the good news. However the manner of triggering it has us foxed. We have an INET routine with the following lines:

A… html=3. Start date format: YYYYMMDD. "

B…

C… html=4. Valid period can have the start date format. "

D… html:="; return html

For this discussion, call them A thru D. B is a test line.

In this state (B is empty); the OICGI error occurs consistently.

If A or C (or both) are asterisked, there is no problem.

And now comes the magic step. Including a test line in B, (we have used html=Rubbish gggggggggggggggggggg ") removes the error! The whole program is 24k

Past experience has suggested the presence of hidden characters, but we could not detect any by shifting the lines into other editors. However past experience also suggests that it is not necessarily possible to cut and paste lines with hidden characters.

We suspect that it has something to do with line delimitation in the OI System Editor. I briefly thought that it might have something to do with the YYYY and delimitation, but this was not the case.

We thought that the NT might have got into a particular state. But the problem was consistent after rebooting. We are still using NT 4.0 (Build 1381) Service pack 5

This info may relate to a point made earlier by Carl Pates of Sprezzatura concerning errors of seemingly similar type generated after editing a program.

I hope that this is helpful

Am I missing something here? Are you not embedding @fm's in the html by executing html=… "? What version of OICGI are you using?

Jim,

The same thought struck me. But even the Inet_Trace function does it, so it must be all right.

- Oystein -

Either OICGI.EXE or Run_Inet_Request ( not sure which ) swaps out any @Fms with CRLF's in the document before returning it to the client.

The Sprezzatura Group

[/i]World leaders in all things RevSoft[/i]

Sprezz,

But what if you use CRLFs already? Are they translated into twice as many CRLFs? When I look with my web browser at the source (IE - View | Source) for my app's dynamic web pages, there are a lot of empty lines. (I've just been too lazy and/or busy to look into it myself. And it isn't that important, even if it makes your app generated html more difficult to check.)

- Oystein -

We have always used either the html= approach or the html:= approach in building up pages to be returned. Never had the slightest problem.

Version of OI is 3.7.3

For ye who doubt, we took the same lines that trigger the OI App Error and replaced html= by html:= and were still able to retrigger the Ap Error. And to prevent it from triggering by the same technique described.

It would seem that we have a few valuable lines of code there to be able to hold or bypass such an error ! The routine works just fine when we bypass the offending lines as described. Of course both variants compile without any error.

Anthony,

…valuable lines of code…

Are you planning to sell that

html=Rubbish gggggggggggggggggggg "

statement? How much for an unlimited license then?

…compile without any error.

There have been cases where compilation only seemed to run ok, but produced… …eh… …rubbish. (File under Clutching at Straws.)

- Oystein -

We have spent more time with the routines that consistently trigger the OI Ap Error on NT using OI 3.7.3 and NT 4.0 SP 5 – an error that we can consistently avoid by several techniques.

We have tested the lines of code for hidden characters and found none.

It is possible that the process of testing lost hidden codes however.

We have made copies of the routine and the Ap Error was consistently generated or avoided as the case may be in the second version (different name).

In order to preserve the error generating potential of the original version we tweaked only the copy.

We found out that a dummy line (html:=Rubbish ggggg…") was a key to preventing the triggering. The minimum length (number of ggg) was significant, around 15.

In an effort to avoid this "solution" we explored replacing our html=…code…" technique by html:=…code…". This seems to be a key, for whatever the reason. We only had about 89 such instances, of which we replaced the first 30…up to where the above funny business was occurring.

We have a bunch of other routines and it would be helpful to know whether this is the route that we should be going. Is there some secret rule that we should be following to avoid generating OI Ap Errors of the kind described.

We still have access to the version of the original routine that is holding the error generating lines, so if anyone has ideas for further tests, please comment.

Anthony,

You suspected funny characters or codes. I'm not sure that can be the reason here. But anyway: You say you've inspected your program code. Wouldn't it be better to check the result? At the end of your Inet function just OSWrite the whole Html variable to a text file - and instead return something harmless (e.g "testtest"). Then you can inspect the text file afterwards.

- Oystein -

Thanks for your suggestion. Unfortunately, inserting a test line to write the content of the required html – whether to an OI file or a system file – means that we are introducing a line in such a way as to affect the results of the test.

In fact the test line prevents the error from triggering the same way our "rubbish ggg…" line did.

Any comments?

Anthony,

But what can it be?

Is there something that goes wrong with the compilation in case A and not case B? So buggy object code is produced in case A and correct object code in case B?

If not - how can the presence and absence of a little bit of program code make a such difference?

Btw - adding program code to write to a text file (my suggestion) is a rather different kind of change from adding program code that changes the return value (the Rubbish ggg thing or using CRLF or "" instead of @FM). Have you tried yet other kinds of changes? E.g adding comments? Null statements?

I'm starting getting really curious to see that function.

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

[email protected]

Home:

Tel/fax: +47 56 14 06 11.

[email protected]

View this thread on the Works forum...