Red Gate forums :: View topic - Strange Ants problem: win32-recv fails using LineLevelTiming
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
ANTS Performance Profiler 7
ANTS Performance Profiler 7 forum

Strange Ants problem: win32-recv fails using LineLevelTiming

Search in ANTS Performance Profiler 7 forum
Post new topic   Reply to topic
Jump to:  
Author Message
SamJost



Joined: 31 Oct 2012
Posts: 2

PostPosted: Wed Oct 31, 2012 12:27 pm    Post subject: Strange Ants problem: win32-recv fails using LineLevelTiming Reply with quote

I'm using Ants Profiler 7.4 Standard to profile a .NET executable (mixed c#/c++/clr application) and encounter a very strange problem:

When I start the problem standalone it works as it should.
When I start it using Ants and use Sample method-level timings it works, too.
But when I use Line-level and method-level timings I get an error when using tcp/ip-Connections regarding this win32 api:


int PASCAL FAR recv (
__in SOCKET s,
__out_bcount_part(len, return) __out_data_source(NETWORK) char FAR * buf,
__in int len,
__in int flags);

When some legacy part of the app uses this win32 api recv the call will fail with the error: WSAENOTSOCK 10038

Socket operation on nonsocket.
An operation was attempted on something that is not a socket. Either the socket handle parameter did not reference a valid socket, or for select, a member of an fd_set was not valid.

So for some strange reason line-level timing messes up my application communication.

Is this a known problem and a workaround?

I just upgraded Ants to the most current version 7.4 without any changes (the problem also existed on version 6). The system is x64 Windows 7.

Kind regards,
Sam
Back to top
View user's profile Send private message
Chris.Allen



Joined: 12 Mar 2009
Posts: 591

PostPosted: Thu Nov 01, 2012 3:09 pm    Post subject: Reply with quote

I don't recall this particular error or even any general interference with tcp/ip however, it is known that the instrumentation technique (line/method level) of profiling is much more "interfering" than sampling method when it comes to the running of IL since it dynamically injects IL.

Does it help by locking out this part of the code to mulitple threads (if only to test)?
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6669

PostPosted: Thu Nov 01, 2012 3:29 pm    Post subject: Reply with quote

APP installs detours for Win32 socket functions, so blocking calls can be noted in the results. Could this have something to do with the problem?
Back to top
View user's profile Send private message
SamJost



Joined: 31 Oct 2012
Posts: 2

PostPosted: Thu Nov 01, 2012 4:23 pm    Post subject: Re: Reply with quote

Chris.Allen wrote:
Does it help by locking out this part of the code to mulitple threads (if only to test)?


So I can lock this part out (exclude it) from profiling? I found no option in the "new session"-dialogue to achieve this.

Brian Donahue wrote:
APP installs detours for Win32 socket functions, so blocking calls can be noted in the results. Could this have something to do with the problem?


The recv should block until it receives data instead of throwing an error, so it might have to do something with the problem. I just don't see how to work around this.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group