Memory-Leaks / cross-domain security problems

[LETH]

Hi

I have two problems while playing with the POCO library the first time:
A)
Just have implemented the time server sample into an old AFX dialog.
Following code at the onInitDialog handler:

unsigned short port = (unsigned short)9980;
std::string format(DateTimeFormat::SORTABLE_FORMAT);
ServerSocket svs(port);
pxSrv = new HTTPServer( new TimeRequestHandlerFactory(format), svs, new HTTPServerParams );
pxSrv->start();

And following at the onClose handler:
pxSrv->stop();
delete pxSrv;

The HTTP server just runs perfectly if I use a browser on the port. After terminating, there is quite a lot of memory leaks dumped at the IDE (VS2010) - which I guess was not the plan of the developers of the lib.

Is there a way to free all memory??

B)
I tried to buil a little Silverlight application as the client part to this HTTP server. Now Silverlight is very restrictive in relation to cross-domain.
Normally, one may drop a cross-domain file at server's root directory.

Now, in case of my own server, what is the right way (mechanism) to allow cross domain access??

Many thanks and kind regards
Thomas

[Royce]

I don't know about the leaks but I used a header in my server.

Early in the request handler:

Code: Select all

string cors = Poco::Util::Application::instance().config().getString("CORSHeader");
response.add("Access-Control-Allow-Origin", cors);


I set CORSHeader to whatever URL that I expect will fetch a page from a full server that will end up calling my api server.

[alex]

Is there a way to free all memory??

HTTPServerParams and HTTPRequestHandlerFactory are passed in as smart pointers so memory is freed automatically. Can you be more specific as to what do you exactly see on shutdown?

[LETH]

@royce:
thnx for the hint. was not the solution but leaded me into light
Following the solution:

I found at HTTPRequestHandler that Silverlight does send an URI like "/clientaccesspolicy.xml" first, leading to a subsequent request to "/". On that first request I could deliver the well described, requested "clientaccesspolicy.xml" file and the problem was gone!

@alex:
I still have lots of dumps on program termination. I tested again, HTTP server (start/stop) commented out -> no dumps. HTTP server just started and stopped ->

Detected memory leaks!
Dumping objects ->
{535} normal block at 0x0084ED88, 32 bytes long.
Data: <TCPServer: 0.0.0> 54 43 50 53 65 72 76 65 72 3A 20 30 2E 30 2E 30
{534} normal block at 0x0084E480, 8 bytes long.
Data: < > B8 D6 84 00 00 00 00 00
{521} normal block at 0x0084DE70, 8 bytes long.
Data: < > E4 DA 84 00 00 00 00 00
{520} normal block at 0x0084DC18, 8 bytes long.
Data: < > CC DA 84 00 00 00 00 00
{454} normal block at 0x0084DAA8, 144 bytes long.
Data: < v @ > F4 76 C6 01 01 00 00 00 40 D7 84 00 00 00 00 00
{453} normal block at 0x0084DA68, 4 bytes long.
Data: < > 01 00 00 00
{452} normal block at 0x0084DA18, 16 bytes long.
Data: < | @ H > 90 7C C6 01 40 D7 84 00 80 48 97 00 88 D8 84 00
{451} normal block at 0x00974880, 4 bytes long.
Data: < > 02 00 00 00
{450} normal block at 0x0084D9B8, 32 bytes long.
Data: <%Y-%m-%d %H:%M:%> 25 59 2D 25 6D 2D 25 64 20 25 48 3A 25 4D 3A 25
{449} normal block at 0x0084D970, 8 bytes long.
Data: < > CC D8 84 00 00 00 00 00
{448} normal block at 0x0084D928, 8 bytes long.
Data: < > 9C D8 84 00 00 00 00 00
c:\fle\test\httptests\httptests\httptests\httptestsdlg.cpp(108) : {447} normal block at 0x0084D888, 100 bytes long.
Data: < S b > B8 E1 BE 01 D4 53 C6 01 8C D8 84 00 FE E8 62 01
{446} normal block at 0x0084D840, 8 bytes long.
Data: < > 80 D7 84 00 00 00 00 00
{445} normal block at 0x0084D7F8, 8 bytes long.
Data: <` > 60 D7 84 00 00 00 00 00
c:\fle\test\httptests\httptests\httptests\httptestsdlg.cpp(108) : {444} normal block at 0x0084D740, 120 bytes long.
Data: <\S > 5C 53 C6 01 02 00 00 00 80 96 98 00 00 00 00 00
c:\fle\test\httptests\httptests\httptests\httptestsdlg.cpp(108) : {443} normal block at 0x0084D688, 120 bytes long.
Data: <xD C 8 > 78 44 C6 01 BC 43 C6 01 38 D6 84 00 A8 DA 84 00
{440} normal block at 0x0084D638, 16 bytes long.
Data: <dm , > 64 6D C6 01 01 00 00 00 2C 01 00 00 01 CD CD CD
Object dump complete.
The thread 'Win32 Thread' (0x1490) has exited with code 0 (0x0).
The program '[5776] httptests.exe: Native' has exited with code 0 (0x0).

Regards
Thomas

[guenter]

The reported memory leaks are probably not real memory leaks (else they would have been discovered long ago). Problem is that VC++ memory leak reporting is unreliable in multithreaded applications. In the specific case, even after stopping the HTTPServer, the thread handling the last connection may still run at the time the "leaks" are reported (since you did not call stopAll(true)) and its heap objects will be reported as leaks, even though the objects will be properly deleted when the thread completes.

[alex]

The reported memory leaks are probably not real memory leaks (else they would have been discovered long ago).

I agree. I ran HTTPTimeServer example and no leaks were reported. FWIW, if you are concerned and want to check for leaks yourself, I wrote a simple windows LeakDetector class long time ago.
You can use it like this:

Code: Select all

LeakDetector ld; assert (!ld.hasLeaks());
ld.checkPoint(); assert (!ld.hasLeaks());
int* pi = new int;
ld.checkPoint(); assert (ld.hasLeaks());
ld.dump();