EOSError code 5 followed by Access Violation

rbuser

Hi,

The same error occurs in ISAPI dlls compiled with:
Delphi 7, RB 7.02 , DOA, Waler TExtraDevices (pdf stream)
Delphi 2005, RB 9.02, DOA, Waler TExtraDevices (pdf stream)

ISAPI Running in separate App Pool on Windows 2003 Server (IIS 6.0).

We have been using RB in our web ISAPI dll for years. Recently, we have two
installations where we experience the following two errors:
"Exception of class EOSError, System Error. Code: 5. Access is denied"

And after that, it seems reports on the same thread (same instance of
TppReport) produce an Access Violation.

The errors doesn't appear consistently, but after Restarting the dll, and
running some reports (10-20 pages) 3-4 times it usually happens. Some
reports seems more prone to cause the issue.

Searching the net for the Error Code 5 (I haven't been able to find full
description of it) leads me to think that it is related to File Access.
This could make sense, since the permissions of the dll
(IUSR_%computername%) might prohibit this.

I searched the RB sources, and found a couple of places where it might write
a file.
- "ppSubRpt.pas" in conditional define CacheTrack. Hopefully this is not
defined, as the file location (c:\) doesn't look very promising.
- "ppCache.pas" tries to write file-streams in Windows Temp folder. This
could be relevant since the reports that fail are slightly bigger (10-20
pages) than other, smaller reports that doesn't seem to cause the problem.
However the docu says that file cache will only be used in >1000 pages
reports.

Have not been able to reproduce it in a debug environment so far.
I feel that including a working example of the reports would be quite a big
deal since the environment where they run is quite complex.

Any ideas would be greatly appreciated.

Best Regards,
Paul Wiik
Omniware AS

nardmoseley

1. We have examples of using RB Server Edition to build an ISAPI WebTier
that uses TExtraDevices to output to PDF. In this context our solution
outputs the results to a temp file. (The WebTier maintains a file based
cache).

2. For RB 9.02 we enhanced the TppFileDevice class to be able to output
directly to stream. TppFileDevice is the ancestor for all of the devices
that output to file formats such as PDF. TExtraDevices descends from
TppFileDevice.

3. When TExtraDevices creates the PDF stream, does it create a temp file
during this process? My guess is that it does, but I really do not know.




--
Nard Moseley
Digital Metaphors Corporation
http://www.digital-metaphors.com

nardmoseley

The other files that you mentioned would only be created for debugging in
the first case (which is not on) and for a report that has CachePages set to
True and runs out of memory. This would be rare - definitely not for a 10-20
page report. It would take 1000+ pages.



--
Nard Moseley
Digital Metaphors Corporation
http://www.digital-metaphors.com

rbuser

Nard,

Thanks for the tip.
- Checked out TExtradevices, and it didn't appear to use any files if set to
print to stream.

After much struggle with debuging/reproducing multithread issues, I finally
managed to reproduce it on my Development PC.

It turned out it wasn't at all related to files!

After tracing it as far as I could get, I ended up in "ppRichTx":
"destructor TppCustomRichText.Destroy"
The line where it does "FRichEdit.Free;" fails with the EOSError Code 5
Access Denied
We use QMemory, and so I have a problem with tracing it further (the
debugger just jumps into QMemory. If I try to step to
TCustomRichEdit.Destroy, it fails before it gets there.

After thinking about this, I thouht it sounded familiar - The Delphi
Richedits not being multithread safe, but I haven't been able to find a way
out so far.

To Reproduce the problem I had to:
- Make sure the ISAPI had two threads. If only one was created, it wouldn't
happen.
- Load and print the report once (We have TppReport on the TWebmodule)
- Then the next time I tried to load it, it failed during releasing of the
old Template.

I'm not sure if it's a report-builder issue or a Delphi issue, or none of
them, but I would greatly appreciate any hints on fixes.
For now I will try to convince the customer to throw out the rich-edits.

Paul Wiik

nardmoseley

Yes, that makes sense. The TRichEdit is a visual control and as such it can
cause issues.

RB Server Edition supports RichText. You might download a trial version and
check it out.....



--
Nard Moseley
Digital Metaphors Corporation
http://www.digital-metaphors.com