Re: About protected memory in COM(in-process)
- From: "Tony Johansson" <johansson.andersson@xxxxxxxxx>
- Date: Mon, 8 Dec 2008 22:24:56 +0100
Hello!
Thanks for you answer.
But I mean that the COM dll is doing exactly the same thing whether it's VB
that is using it or
C# asp.net.
So the error can't be in the actual code I assume.
So do you agree with me that I find it very very hard to assume that there
could be any programming bugs
like index out of bounds or such things.
We use Oracle OLE DB providerns to connect to the database.
For example we have a CDataSource object named DS which is part of MFC.
Which is used in this way
hr = DS.Open("OraOLEDB.Oracle", "IDTHU1", "CCR_DTH_USER"," P55534552");
and then we have a CSession object called Session that is used in this way.
hr = Sesssion.Open(DS);
We have noticed that sometimes will this DS.Open throw an exception which
cause protected memory
despite knowing that all hard coded parameter is valid to this DS.Open(...).
This exception can't be catched with
catch(CException *) becuase it's not derived from that class but with
catch(...).
I have read at some places on the web that other have had problem using this
oracle OLE DB providern and have to change
to microsoft oracle providern.
We have tried to reproduce the protected memory error when running the code
in debug under IIS using VS but haven't succeded yet.
What conclusion can we make if it's impossible to reproduce the error in
debug mode using VS desite running the code under IIS ?
It seems to be impossible to get any kind of information about the reason
for getting this protected memory.
We just get this protected memory and we are almost certain that it has
something to do with the
connection to the oracle database.
Everything is pointing at that direction.
Can you give a suggestion what I can do to try to get rid of this protected
memory ?
We have added statement to the code to trace to a file to get information
how far in the code it goes.
Have you ever hear about that it can be a bug in the oracle OLD DB providern
?
//Tony
"Igor Tandetnik" <itandetnik@xxxxxxxx> skrev i meddelandet
news:OlsHkwWWJHA.4252@xxxxxxxxxxxxxxxxxxxxxxx
Tony Johansson <johansson.andersson@xxxxxxxxx> wrote:
Now to my question:
How is possible that the exact same COM dll work just perfectly when
being run under windows VB6 and not from
C# asp.net webb application.
My guess is, the DLL makes assumptions about lifetimes of its various
objects, which no longer hold. The main difference between VB6 and .NET
(when it comes to interfacing with COM) is that the former is
reference-counted while the latter is garbage-collected. When a VB
variable holding a COM interface goes out of scope, VB immediately calls
Release on the interface pointer. When a C# variable goes out of scope,
the object it refers to (a .NET wrapper around the interface pointer)
becomes orphaned and eligible for GC. Some time later, noone knows when,
the garbage collector will get around to finalizing this object, at which
point Release will be called.
So objects stick around longer. If the DLL, say, makes an assumption that
only one object of a certain type would be alive at a time, it's in
trouble.
Another possible reason: ASP.NET application runs inside IIS process under
a pretty locked-down account with limited privileges. Could it be that the
DLL is trying to do something it doesn't have rights to, and gets
security-related errors? E.g. an ASP.NET application cannot, by default,
read or write arbitrary files on disk.
Why don't you debug the DLL and figure out where it fails?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
.
- Follow-Ups:
- Re: About protected memory in COM(in-process)
- From: Brian Muth
- Re: About protected memory in COM(in-process)
- From: Igor Tandetnik
- Re: About protected memory in COM(in-process)
- References:
- About protected memory in COM(in-process)
- From: Tony Johansson
- Re: About protected memory in COM(in-process)
- From: Igor Tandetnik
- About protected memory in COM(in-process)
- Prev by Date: Re: About protected memory in COM(in-process)
- Next by Date: Re: About protected memory in COM(in-process)
- Previous by thread: Re: About protected memory in COM(in-process)
- Next by thread: Re: About protected memory in COM(in-process)
- Index(es):
Relevant Pages
|
