I'm trying to profile CPU utilization for my project using DTrace. I just followed the script
The problem is that it doesn't show the functions names. The stacks.out file looks like that:
CPU ID FUNCTION:NAME
0 73700 :tick-60s
node`_ZN2v86Object3GetENS_6HandleINS_5ValueEEE+0x1
node`_ZN4node7TCPWrap12OnConnectionEP11uv_stream_si+0x14b
node`uv__server_io+0xbf
node`uv__io_poll+0x259
node`uv_run+0xda
node`_ZN4node5StartEiPPc+0x16d
node`main+0x1b
node`_start+0x83
1
node`_ZN4node6Buffer4FillERKN2v89ArgumentsE+0x22b
0x82474d1b
0x8241ee9c
0x8241e624
0x8241e30f
0x82426abd
0x82419e4e
0x82419948
0x82413fc3
0x8d20e501
0x82416f65
0x82413f98
0x8243e7d3
0x824186c0
0x8246e8cf
0x8d221899
0x8d21308a
node`_ZN2v88internalL6InvokeEbNS0_6HandleINS0_10JSFunctionEEENS1_INS0_6ObjectEEEiPS5_Pb+0x101
node`_ZN2v88internal9Execution4CallENS0_6HandleINS0_6ObjectEEES4_iPS4_Pbb+0xc9
node`_ZN2v88Function4CallENS_6HandleINS_6ObjectEEEiPNS1_INS_5ValueEEE+0x10b
node`_ZN4node12MakeCallbackEN2v86HandleINS0_6ObjectEEENS1_INS0_8FunctionEEEiPNS1_INS0_5ValueEEE+0x4c
node`_ZN4node12MakeCallbackEN2v86HandleINS0_6ObjectEEENS1_INS0_6StringEEEiPNS1_INS0_5ValueEEE+0x66
node`_ZN4node10StreamWrap12OnReadCommonEP11uv_stream_si8uv_buf_t14uv_handle_type+0x14f
node`_ZN4node10StreamWrap6OnReadEP11uv_stream_si8uv_buf_t+0x2e
node`uv__read+0x281
node`uv__stream_io+0x131
node`uv__io_poll+0x259
node`uv_run+0xda
node`_ZN4node5StartEiPPc+0x16d
node`main+0x1b
node`_start+0x83
1
The flame graph shows hex (ie. "0x82474d1b") as functions calls and not the actual function name.
I'm using OmniOS (illumos based OS) vagrant box r151002 and did this (https://gist.github.com/dalssoft/5595688) to build node.js 32bits on OmniOS.
Any thoughts?
I had similar issues when writing my blog post about using openindiana and node.js together.
http://blog.nearform.com/blog/node-openindiana.html
I found being explicit with the cpu arch was the way to resolve it.
./configure --with-dtrace --dest-cpu=x64
Don't forget to demangle the c++ symbols too
c++filt < stacks.out > demangled.out
Related
I amm writing a little python script that will grab information from VMs of Windows that I am running.
At the moment I can list the processes on a 32bit XP machine with the following method:
http://code.activestate.com/recipes/305279/
Is it possible to somehow detect the version of windows running and excute a different method for getting the processes on a 64bit machine, I am trying to get the processes from a 64Bit Vista and 64bit Windows 7.
Any ideas?
If you don't want to rely on any extra installed modules then you can parse the output of wmic, e.g.:
c:\> wmic process get description,executablepath
...
explorer.exe C:\Windows\explorer.exe
cmd.exe C:\Windows\SysWOW64\cmd.exe
conhost.exe C:\Windows\system32\conhost.exe
...
Reference: http://geekpedia.wordpress.com/2008/08/18/use-command-line-to-track-windows-processes/
There is another recipe on activestate that does a similar thing, but uses the Performance Data Helper library (PDH) instead.
I have tested this on my Windows 7 64bit machine and it works there - so presumably the same function will work on both 32bit and 64 bit windows.
You can find the recipe here: http://code.activestate.com/recipes/303339/
Another method is using WMI, there is an example here in Python using the wmi module:
http://timgolden.me.uk/python/wmi/cookbook.html
import wmi
c = wmi.WMI ()
for process in c.Win32_Process ():
print process.ProcessId, process.Name
The cleanest way I found to solve this was to use the psutil library as recommended by Robert Lujo:
psutil.process_iter()
Note that it returns a generator object, issuing a process object at a time. For example if you need the list of process names, you can do something like:
[p.name() for p in psutil.process_iter()]
For similar purposes I have used psutil library. Some hints:
list processes with psutil.pids() (reference)
inspect process information with process = psutil.Process(pid) (reference)
do process.kill or process.terminate()
Installation on windows - pip will do installation from the source (which means compiling), so you probably want to download binary installation from https://pypi.python.org/pypi/psutil/#downloads.
You should be able to do this by exposing Windows Management Instrumentation within each VM. This tool gives you access to a bunch of system data, including processes, see http://technet.microsoft.com/en-us/library/cc757287%28WS.10%29.aspx
You should be able to popen one of the commands in the preceding link to get the info you're looking for.
So I am a newbie to OpenModelica. I have a bit of experience using LMS Amesim. I created my first simple model using OM and simulated it from within the OMeditor.
When I switch to the plot window, there are NO output variables to plot. That tells me that the simulation may not have run. However, no error messages popped up. When I checked the model, I found it to be fine (not overconstrained or underconstrained).
What gives? This is OM 1.14 on Linux Ubuntu 16.04.
My Modelica file is a simple 2nd order system with feedback control is available via pastebin here or may be downloaded here via google drive link
The messages that I have from the output window are:
/tmp/OpenModelica_drN/OMEdit/Feedback/Feedback -port=35318 -logFormat=xmltcp -override=startTime=0,stopTime=100,stepSize=0.2,tolerance=1e-6,solver=dassl,outputFormat=csv,variableFilter=.* -r=/tmp/OpenModelica_drN/OMEdit/Feedback/Feedback_res.csv -w -lv=LOG_STATS -inputPath=/tmp/OpenModelica_drN/OMEdit/Feedback -outputPath=/tmp/OpenModelica_drN/OMEdit/Feedback
The initialization finished successfully without homotopy method.
The simulation finished successfully.
This was a bug. Should be fixed now:
https://trac.openmodelica.org/OpenModelica/ticket/5251
I have a very strange problem with the constructor of AptPkg::Cache object in the precise package of libapt-pkg-perl (v. 0.1.25).
The perl script is designed to download a debian package for three different architectures (i386, armel, armhf). For each architecture I do the following:
Configure AptPkg::Config '$_config' with the right parameters and package-lists for the desired architecture.
Create the cache object with AptPkg::Cache->new .
Call the method AptPkg::Cache->policy to create the AptPkg::Policy object.
Call the method AptPkg::Policy->candidate("program-name") .
Download the package for the selected architecture.
This works very well with Ubuntu Lucid, but with Ubuntu Precise I can only download the package for the first architecture defined. For the other two architectures there will be no installation candidate (method AptPkg::Policy->candidate("Package-Name") doesn't return an object).
I tried to build a workaround and I found one solution how the script works for all three architectures, without problems, in precise:
If I create the cache object (with AptPkg::Cache->new) twice in a row it works and the script downloads the debian package for all three architectures:
my $cache = AptPkg::Cache->new;
$cache = AptPkg::Cache->new;
I'm sure that the problem has something to do with the method AptPkg::Cache->new because I checked everything else, what could cause the problem, twice. All config-variables are set correctly and I even get a different Hash for AptPkg::Cache->new for each architecture, but it seems that I am overlooking something important.
I'm not very familiar with perl, so I am asking you guys if someone can explain why the script works with the workaround but not without it. Further it looks quite strange if you have the same line of code twice in your script.
Maybe you hit this bug - https://bugs.launchpad.net/ubuntu/+source/libapt-pkg-perl/+bug/994509
There is a script there to test if you're affected. If it's something else consider submitting a bug report.
edit: Just saw this is 11 months old :/
All standards compliant applications in Linux store a desktop schema in /usr/share/applications/. In my particular use case, I have a WnckWindow data structure and I can get a pid from that. Using this pid, I can extract the command line from the proc.
Unfortunately, it seems that the proc command line entry does not match the desktop schema launch parameters. For example, the 'thunderbird' application is launched via /usr/bin/thunderbird but this is just a shell script which activates the real executable: /usr/lib/thunderbird-8.0/thunderbird-bin.
The real executable cannot be launched directly as it is dependent on the library paths configured in the /usr/bin/thunderbird script. Does anyone have any advice on how to match process id numbers to the appropriate desktop schema without getting caught by the issue I've described?, Thanks.
Ok, well, it appears that there's no nice way of solving this using the pid, however, it is relatively easy to match the Wnck windows class to application desktop schemas. The Wnck windows class needs to be preprocessed a little first to ensure that the filter works but it's pretty trivial stuff. Once you've got a good set of target strings, eg 'Thunderbird' or 'Google' + 'Chrome', you can use the system application menu API to zero in on a likely candidate, for example, by using garcon on Xfce.
I am trying to get some information about the flow of a large program. KCachegrind used to be great for this in the past. But the latest version (0.6kde) I have on my system (Kubuntu 10.10) won't display the call tree and caller map. It only draws a box with the current function, but no arrows and no callers. Here's the console output:
kcachegrind(27917)/kdecore (services) KMimeTypeFactory::parseMagic: Now parsing "/usr/share/mime/magic"
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/cosmin/.config/ibus/bus
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
CallGraphView::refresh
CallGraphView::refresh: Started process 0x1346f50, 'dot -Tplain'
CallGraphView::readDotOutput: QProcess 0x1346f50
CallGraphView::dotExited: QProcess 0x1346f50
I have dot (graphviz) installed, and the application was compiled with -g -O0.
Do you have any idea where the problem could be?
Oops... I was calling valgrind --tool=cachegrind instead of valgrind --tool=callgrind.