Problem with Delphi SOAP Runtime

Hello,

I'm using D7 Pro (Build 8.1) and the soap runtime released on December 2007.

I get a systematic AV when I call a specific method of a Web Service. Or 
better, I get an AV when the application run on the customer PC's (I 
have tried on three different PC's) and not on my develop pc.
I made a deep debug session, executing step by step the application on 
my pc and on the customer pc at the same time (two Delphi instance, for 
the customer pc I used the remote debugger). At the end I got the point 
where the problem is raised.

function  TSOAPDomConv.ConvertSOAPToObject(...
var
   ...
begin
   ...
     LegalRef := True;
     if Assigned(Obj) then
     begin
       try
         if Obj.ClassType <> nil then
           LegalRef := True;
       except
         LegalRef := False;
       end;
     end;

In both pc Obj is not nil. On my pc when try to access to it (with 
Obj.ClassType) an exception will raised, so LegalRef is set to False.
On customer pc doesn't happen so, Obj.ClassType = nil so LegalRef remain 
True and then in the LoadObject an AV is raised at the first try to 
access to Obj method or property. Note that Obj will not be reassigned 
before the call of LoadObject.
On my pc at the end the result is correct while on the customer pc it 
doesn't reach the end because the AV.
To solve the problem for the moment I changed the code:

         if Obj.ClassType <> nil then
           LegalRef := True;

with

         if Obj.ClassType = nil then
           LegalRef := False;

I tried to investigate when the ObjP parameter passed to 
ConvertSOAPToObject is assigned but it is in an assembler part.
What I can say is that (I think) it refer to the last parameter of the 
Web Service method (the first that is examined).

What do you think?

Hello Maurizio,

The first thing that comes to mind is the DEP issue. This issue shows up on
some PCs on not on others. However, if you applied the runtime updates, this
is probably not the issue as the DEP issue is addressed with the
PrivateHeap.pas unit. Can you confirm that indeed you are using PrivateHeap?
My concern here is if you're using the SOAP package, then you'll need to
rebuild the later with the runtime updates. If you're not linking with
packages, then it's easier to ensure that you're using the runtime updates.
( http://tinyurl.com/9gsc7   http://cc.codegear.com/Item/24535 ).

About LegalRef itself, it's one of the fuzzy areas of the runtime. It a
wacky to deal with cases where we end up with a non-nil object but it's not
valid. This happens rarely but it's still a possibility, specially when
'var' or 'out' parameters are involved. Can you post a little more about the
signature of the method you're invoking?

Cheers,

Bruneau

Jean-Marie Babet wrote:
> Hello Maurizio,

Hello Bruneau,

> The first thing that comes to mind is the DEP issue. This issue shows up
on

Can you briefly explain what is the DEP issue?

> some PCs on not on others. However, if you applied the runtime updates,
this

Is it possible that the difference depends on different CPU and/or OS?
My pc, where it "works":
   OS: Windows 2000 Pro, Version: 5.0, Build: 893, "Service Pack 4"
   cpu: Intel, Pentium III, 933 MHz MMX
Customer PC's:
   OS: Windows XP Pro, Version: 5.1, Build: A28, "Service Pack 2"
   cpu: AMD, AMD Athlon(tm) 64 Processor 3400+, 2400 MHz MMX
   OS: Windows XP Pro, Version: 5.1, Build: A28, "Service Pack 1"
   cpu: Intel, Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz, 1700 MHz MMX
   OS: Windows XP Pro, Version: 5.1, Build: A28, "Service Pack 2"
   cpu: Intel, Intel(R) Core(TM)2 CPU U7600  @ 1.20GHz, 1200 MHz MMX

> is probably not the issue as the DEP issue is addressed with the
> PrivateHeap.pas unit. Can you confirm that indeed you are using
PrivateHeap?

Yes, I confirm that I'm using PrivateHeap included with the runtime 
updates. I see the dcu where I set the dcu output for the test application.
I even renamed the homonyms units in $(DELPHI)\Source\soap.

BTW may I suggest to add in the docs to add the location of the runtime 
update files to the project's ‘Debug Source path’ options too?
Otherwise Delphi (at least D7) shows the original source during the 
debug. Initially I don't understood why the code makes "strange" jumps
:-)

> My concern here is if you're using the SOAP package, then you'll need to
> rebuild the later with the runtime updates. If you're not linking with
> packages, then it's easier to ensure that you're using the runtime
updates.
> ( http://tinyurl.com/9gsc7   http://cc.codegear.com/Item/24535 ).

No I'm not linking with runtime packages, at least not yet. It is 
possible that I'll need to compile the real application with runtime 
packages, is it be possible?
The second link is where I get the soap runtime update, but the first 
one is not clear to me.

> About LegalRef itself, it's one of the fuzzy areas of the runtime. It a
> wacky to deal with cases where we end up with a non-nil object but it's
not
> valid.

I supposed that :-)
The problem in my case is that the object is non-nil and not valid. In 
my pc Obj.ClassType cause an AV between a try except, but on customer 
pc's it results nil, causing the AV afterwards.

> This happens rarely but it's still a possibility, specially when
> 'var' or 'out' parameters are involved. Can you post a little more about
the
> signature of the method you're invoking?

This is the one that cause the problem:

procedure MyWsProc(const arg0: TRemotable;
                    const arg1: WideString;
                    const arg2: TRemotable;
                    const arg3: TRemotable;
                    out arg4: TRemotable;
                    out arg5: WideString
                    ); stdcall;

Where do you see TRemotable really it is a descendant.
In this case the Obj that cause the AV refer to arg5.

This other is similar but not cause the problem:

procedure MyWSOtherProc(const arg0: WideString;
                         const arg1: WideString;
                         const arg2: WideString;
                         const arg3: TRemotable;
                         out arg4 TRemotable;
                         out arg5: WideString
                         ); stdcall;

In that case the Obj is nil when refer to arg5 and no AV is raised at 
all, even when run within Delphi (I have stop on Delphi exception on).

Tell me if you need more informations and/or tests. I'll be by the 
customer in the next days.

Hello,

Thanks for the reply.

The DEP issue is basically that starting with WinXP Service Pack 2, if your
hardware is capable, Windows will prevent execution of code from
non-executable memory. Unfortunately the Delphi SOAP runtime creates a bunch
of thunks and the memory allocated for these were not marked executable. So
when the OS update was released on capable hardware, you'd get an AV when
invoking a method backed by a RIO component. This issue was addressed in an
update with the PrivateHeap unit.

That said I think the issue you're running into is more related to the 'out'
issue. Would it be possible for me to see the context of the calls?  A few
lines of code leading to the call. Specially the contents of the 'out'
variables before the call. Can you clear (nill out) the variables used as
'out' before invoking the method? Does that help?

Is the service you're talking to a doc|literal service? If yes, I would
suggest no unwrapping the wrapper elements. This will change the interface
you use to interact with the service but it will also eliminate these 'out'
variables - which I believe to the source of the problem.

Cheers,

Bruneau.

Jean-Marie Babet wrote:
> Hello,

Hello,

sorry for delay but I can do the test only when I am by the customer.

[...]

> The DEP issue is basically that starting with WinXP Service Pack 2,

Very interesting.

[...]

> That said I think the issue you're running into is more related to the
'out'
> issue. Would it be possible for me to see the context of the calls?  A few
> lines of code leading to the call. Specially the contents of the 'out'
> variables before the call. Can you clear (nill out) the variables used as
> 'out' before invoking the method? Does that help?

The code before the call does nothing special. It simply initialize the 
variables passed as parameters, excepting the one declared as out 
because usually they do not need to be initialized.
Now I initialized they (the TRemotable descendant with nil and the 
WideString with '') and the problem disappear!
Do you still need to see the lines of code leading the call?

> Is the service you're talking to a doc|literal service? If yes, I would
> suggest no unwrapping the wrapper elements. This will change the interface
> you use to interact with the service but it will also eliminate these
'out'
> variables - which I believe to the source of the problem.

No, the service use the rpc style.