stack collection breaks cygwin?

[Ben_C_]

I'm trying to profile my build process, because fast builds are awesome.

My build runs on Windows, and it is powered by GNU Make and a whole pile of cygwin tools.  I don't think I care (yet) about what is going on inside the tools, but I am interested in how long each of those tools spends doing computation vs. I/O vs. just waiting.  I also want to know how many cores are getting used.

So I fire up a cmd.exe prompt, attach to it with VTune, start my locks and waits analysis, and run "make".  I then start getting a fair amount of spam that looks like this:

1 [main] touch 27544 dll_crt0_1: internal error: couldn't determine location of thread function on stack.  Expect signal problems.
1 [main] printf 26172 dll_crt0_1: internal error: couldn't determine location of thread function on stack.  Expect signal problems.

If I enable and disable vtune a few times, while also running make, I end up crashing the full cmd.exe shell that was running make.

I hit similar issues with basic hotspots.  I did not see these warnings when performing general exploration.  I made a custom analysis that collected cpu sampling data, synchronizationAPI data, signalling API data, and I/O api data, but without stacks on all of them.  That didn't cause warnings, but it also didn't produce terribly useful results.

I'm using VTune Amplifier 2017 for Systems, Update 1.  The version info on the associated cygwin1.dll that is loaded by touch.exe is 1.5.25-cr-0x5f1.  I guess that's the version of Cygwin as a whole?  The copyright was from 2003.

Is this a known issue?  Is there a workaround to get the profiling information I want without running in to these crashes and warnings?

[TimP]

Might it help if you limited cygwin activity to fewer than the full number of logical processors, so as to leave some resource for VTune? 

I'm not surprised if you don't learn anything beyond what you would get with cygwin tools such as top.  Most of the activity between tools in a script is probably at a higher level than what VTune handles well.  It's certainly possible that VTune gets confused in the case where both Microsoft and cygwin C run-time libraries are active.

I guess you have a much outdated cygwin, not that it makes a difference.  I have cygwin-2.6.0-1.dll

[Ben_C_]

Task manager tells me that my build isn't using all my cores all that effectively, so VTune getting some resources doesn't seem like a problem for my use case.

[Shailen_Sobhee]

Hello Ben,

From what I see, what you want to do is a General Exploration and profile your whole system. In the configuration pane in Analysis Target, you can set when you want to automatically resume your collection, lets say, 5 seconds, giving you time to prepare to start your make process.

If your make process takes, say 20 seconds, then stop the collection 5-10 seconds after those 20 seconds, so you can put a total of 30 seconds in the "Automatically stop collection after" box.

That's it. Give this a try and let us know what you see!

[DmitryVlad_P_Intel]

Hello, Ben

It looks like old Cygwin has some problems with programs that does code instrumentation or blocks code instrumentation (Outpost firewall, Intel PIN, ...) 

My general suggestion is to upgrade to modern Cygwin and use vTune in regular way.

I would also suggest to try Disk Input Output  analysis.  This a preview feature. You need admin rights to run it. It will show you a I/O wait queue and other I/O data transfer rate and I/O operations. Unfortunately, there are no direct links from I/O operations to processes and sources. You can try to do manual matching using timeline. Windows does not provide us with I/O wait for processes, so we cannot determine what processes are waiting for I/O.

Shailen's suggestion is also good as general exploration does not use pin and should work smoothly.

Regards,

Dmitry