TIPHTTPRequestHeaders.Clear AV

Remoting SDK
1

Hello, I’m using D2007, DA 6.0.47.841 and TROIPHTTPServer

I’ve a lot of AV in TIPHTTPRequestHeaders.Clear in my servers, this is the madExcept CallStack

operating system : Windows 2003 R2 Service Pack 2 build 3790
system up time : 137 days 14 hours
program up time : 2 hours 32 minutes
processors : 4x Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
physical memory : 2629/4094 MB (free/total)
free disk space : (C:) 76,42 GB
display mode : 1024x768, 32 bit
process id : $1524
allocated memory : 221,72 MB
largest free block : 638,93 MB
exec. date/time : 2017-01-17 10:34
compiled with : Delphi 2006/07
madExcept version : 4.0.16
callstack crc : $ea9a618b, $2a90808c, $0fa9fe4b
count : 2
exception number : 2
exception class : EAccessViolation
exception message : Access violation at address 007B9054 in module ‘server.exe’. Read of address 00000045.

thread $999c (TIPSocketWorkerThread):
007b9054 +008 Server.exe uIPHttpHeaders 89 +1 TIPHTTPRequestHeaders.Clear
00880be8 +028 Server.exe uIPAsyncHttpServer 281 +3 TIPAsyncContext.Clear
008811f9 +075 Server.exe uIPAsyncHttpServer 388 +12 TIPAsyncContext.cbResponse
0087ec30 +078 Server.exe uIPAsyncSocket 438 +16 TIPBaseAsyncSocket.BufferedSendCallback
00880154 +43c Server.exe uIPAsyncSocket 965 +100 TIPSocketWorkerThread.IntExecute
0053bc1a +02a Server.exe uROClasses 2614 +5 TROInitializedThread.Execute
0046323b +02b Server.exe madExcept HookedTThreadExecute
0048d8dc +034 Server.exe Classes ThreadProc
00405cb8 +028 Server.exe System 1044 +0 ThreadWrapper
0046311d +00d Server.exe madExcept CallThreadProcSafe
00463187 +037 Server.exe madExcept ThreadExceptFrame

created by thread $33c8 (TIPSocketWorkerThread) at:
0053bbd0 +020 Server.exe uROClasses 2605 +2 TROInitializedThread.Create

Thanks in advance

2

we had similar issue and I think it was fixed a long time ago
if you are compiling your project with latest RO version, this error will be reproduced?
another workaround: replace TROIPHTTPServer with Indy-based HTTP server

3

I don’t have newest version but I don’t view any fix in changelog.
Can you confrim that please?

Thanks.

4

you can use trial version of RO for testing.
I don’t remember any support issues with this problem for latest several years

5

I use TROIPHTTPServer Synapse based because in my tests is faster than Indy.

6

Hello, I replace TROIPHTTPServer with Indy-based HTTP server and get same AV in TIPHTTPRequestHeaders.Clear. Can I apply any fix to my RO version?

Thanks

7

hmm, weird.
looks like your code isn’t thread-safe.
can you describe your application in several words? does it use background threads, events?
if it use events, it should have personal channel+message for usual calls and for events.

can you create a simple testcase that reproduces this problem?

8

Events may be causing the problem. I’ll try to deactivate it.

9

Sorry, one last questión. How can I assign a personal channel to my TDADBEventRepository? I can’t found it.

Is there an example that indicates how to configure the server correctly?

Thanks.

10

client-side should use one channel+message for usual calls and one channel+message for events.
note: this is valid for usual (i.e. non-super) channels. one instance of super channel can be used for all requests (usual calls and events)

11

Ok, I saw the wiki and you say

“Assign its Message property to the message you use to communicate with the server (note that since events are dispatched based on the ClientID, this must be the same Message component you also use for your regular communication)”

http://old.wiki.remobjects.com/wiki/Event_Sinks_and_Server_Callbacks

12

ClientID should be the same for both messages or you can use the shared message.
anyway, original problem was in channel component

13

But my AV is in server side

14

can you create a simple testcase that reproduces this problem. pls?

15

Sorry but only can reproduce it in production system with hundred of clients

16

it could be a problem in SDK or a problem with your code.
you have reproduced this with both different servers (synapse- and indy-based).
we have never had such issues for plain indy http server so it could be something with your code if you do something with server-side headers.
by other way, it could be some corner case, but I need to testcase for reproducing this.

also I recommend to retest this issue with the latest [trial] RO version. it has a chance, that everything will work as expected

17

I tried to retest this issue with latest (trial) RO version but it’s impossible without legacy components. uROEncryption, IDADataSets.SQL, etc, etc. It would take me days to change all my program code for a test

18

pls look at http://old.wiki.remobjects.com/wiki/Breaking_Changes .
it may contain some workarounds for you like

19

The setup of last trial installation don’t use the folder especified in the installation, always use the default folder. This causes errors with my old version installation.