- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I'm running VTune Amplifier 2018, and I found what looks like a bug in the way command lines are managed. Specifically, if the command line arguments of an application contain the ampersand character (even if the arguments are quoted), upon stopping the Analysis the GUI will show a "Please wait until the collection is cancelled" dialog box and the GUI will hang until doing a Force Quit.
I'm running the OSX version of the VTune GUI, connected over SSH to a Linux host. The following command works fine:
/home/user/ffmpeg 'udp://192.168.1.5?overrun_nonfatal=1' foo.ts
but this command causes the GUI to hang:
/home/user/ffmpeg 'udp://192.168.1.5?overrun_nonfatal=1&fifo_size=5000' foo.ts
I've tried using both single and double quotes, as well as just having VTune run a shell script rather than putting the arguments directly into the VTune GUI. The problem occurs in all instances.
Any suggests that could be offered to work around this behavior is appreciated.
Thanks,
Devin Heitmueller
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
As the workaround it's possible to create a bash script for profiling.
So on target there will be test.sh with call of the application you are interesting in.
- Pavel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Pavel,
Thanks for replying.
I actually tried that prior to posting the original issue report. My first instinct was that it was some sort of parsing issue in the GUI and I could bypass it simply by running a shell script that contained the suspect command line arguments. However even in that case I got the same behavior.
The fact that the target application runs makes me think it's some aspect of the post-processing that occurs after I've stopped the analysis rather than an issue with the initial parsing when running the command.
Devin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is two option to understand the root cause of your problem.
First of all. Let's try to run amlxe-cl. The command line may be found in GUI on Analysis Configuration tab.
Try to start it via command-line. Do you get the same problem?
- Pavel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Pavel,
So I ran it from the command line, it started up fine and then I hit <ctrl-c> after a few seconds. Seemed to work fine and if I open the results in the VTune Amplifier GUI they look ok.
So it looks like it's not an issue with the capture itself, although I don't really know the difference between doing the capture through the GUI and viewing the results versus doing it from the command line and then opening the results separately.
Devin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is not difference in collected data from CLI and GUI. Don't be afraid, the workaround will not affect your experiments.
Could you also send build number of VTune Amplifier? Version of host and target operation systems? If the application is opensource the link to the application?
Best regards,
Pavel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pavel,
I am running VTune Amplifier 2018 Update 2 (build 551022) on MacOS 10.12.5.
The target OS is Centos 7.2.1511 (x86_64).
The problem can be demonstrated with just the standard Linux ffmpeg when using a command such as the following:
ffmpeg -i 'udp://@192.168.1.250:4111?overrun_nonfatal=1&fifo_size=50000' foo.ts
Interestingly, the problem only occurs if video is actually arriving to on that UDP input. If I don't stream to ffmpeg then the GUI doesn't get stuck when stopping collection. Perhaps this is a result of some difference in the thread stacks (i.e. very few threads are created if no network stream is actually being received).
One other thing that is worth noting: While it's stuck at the cancelling collection dialog, the left window that shows the result sets creates a bunch of duplicate entries (e.g. "r045lw" over and over). Not sure why that is.
Thanks,
Devin
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page