google / orbit Goto Github PK

Currently it is possible to flush all loaded symbols for the current session by selecting a new process in the process listing. Instead we suggest a workflow where each session is locked to a process once a selection is confirmed. This will also allow things such as auto-loading PDBs, recording/serializing data related to that process into the session, such as PDB references, exe/PDB hash agreements, etc.

UI indicates that it has loaded the PDB successfully, but it does not display anything.
The same program built with VS 2015 just works.

I would like to profile my project, but after loading my project and the pdb file nothing show up in the right hand side of the screen.

I noticed that I was getting a folder named OrbitProfiler at the root of my C: drive after launching Orbit. After looking through the source code it seems like this was intentional. This is usually considered poor form, and I would appreciate if you would make use of the actual %APPDATA% directory instead (CSIDL_APPDATA instead of CSIDL_COMMON_APPDATA).

Currently the sample data is listed in a flat manner similar to Very Sleepy, but it should be possible to build a tree based on recorded callstacks. A stretch goal might be to create an event stack also using implicit spans from the samples, although it would be inaccurate without correct prolog/epilog hooks.

Currently there are no user interface elements for starting/stopping a capture, and the default commands are case-sensitive, which is awkward/confusing.

There is a partial "Pdb" implementation on Linux that was temporarily put inside Module.cpp. We need to rename the class ("DebugInfo"?) and properly separate the Linux and Windows implementations.

It's very easy to attempt to get contextual information for a marker in the capture view and have the right-click behavior turn into a selection that zooms into a super tiny bit of the frame, and then you spend a long time zooming back out to see anything. Short cuts to zoom fully out would be useful if they don't exist (I suppose ‘A’ works but that also translates in time).

This happens e.g. when trying to load symbols of a large binary. For my case there was a package of about 30mb in the message queue that was not send to the Windows client.

For example correlation between capture and sampling/callstacks; I'd like to be able to right-click on a hooked function listed in the capture and "go to" it in the sampling view automatically

After some runs of Orbit, I can not start it again until I reboot my system. The error message is the following:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
TcpEntity::TcpEntity() /usr/local/google/home/kuebler/Documents/develop/orbitprofiler/OrbitCore/TcpEntity.cpp(17) TID: 4018819904
TcpServer::TcpServer() /usr/local/google/home/kuebler/Documents/develop/orbitprofiler/OrbitCore/TcpServer.cpp(27) TID: 4018819904
virtual void TcpEntity::Start() /usr/local/google/home/kuebler/Documents/develop/orbitprofiler/OrbitCore/TcpEntity.cpp(31) TID: 4018819904
void TcpServer::Start(short unsigned int) /usr/local/google/home/kuebler/Documents/develop/orbitprofiler/OrbitCore/TcpServer.cpp(52) TID: 4018819904
terminate called after throwing an instance of 'std::system_error'
  what():  bind: Address already in use

The sampling profiler currently runs at 2KHz by default but can actually range from 1KHz to 8KHz. We should be able to tweak the rate.

When zooming in vertically and then zooming back out, the capture page data doesn't anchor at the top of the view so the contents will often scroll off the top of the viewable area. Without scroll-bars it's non-intuitive that you have to drag it back down.

ETW provides quite a bit of information about context switches that we can easily expose (NewThreadId, OldThreadId, NewThreadPriority, OldThreadPriority, PreviousCState, OldThreadWaitReason, OldThreadWaitMode, OldThreadState, OldThreadWaitIdealProcessor, NewThreadWaitTime).

If you launch Orbit, click on the sampling tab and try to switch the CallStack ("<" or ">") the App just crashes. If there are no call stacks available, the buttons should be not clickable.

Feature request.
I certainly need this awesome profiler on my Debian and I think I'm not alone. :) So I propose to port it to Linux together. For the beginning, I could add a CMake-based build.

Sometimes it is not possible to hook a function (in most cases, because of not running Orbit as root). In these cases it would be nice, if there is a prompt saying that it is not possible to hook the function and also give the reason for that.

Trying to build and ran into a few small problems:

The checked-in OrbitQt.vcxproj has absolute dir references to D:\git\Orbit, and D:/git/Orbit, as well as relative references to ..\..\Orbit -- doing a straight string replace of those in the vcxproj file with .. causes everything to build fine.

Also, external/glew-1.13.0/lib is missing -- glew needs to be rebuilt using the VS2015 toolchain from glew-1.13.0/build/vc12.

After fixing both of those, builds cleanly. Happy to provide a patch/PR for OrbitQt.vcxproj if that'd be easier.

In my HyperV VM, running Windows 10 Professional as the guest OS, running Orbit and selecting the capture tab (and doing nothing else) causes Orbit to immediately exit.

The host OS is also Windows 10 professional, and running Orbit there works fine.

If you don't have access to HyperV, it might be easy to test this using a free Azure account.

Would be cool to get some capture-wide statistics of instrumented functions. The idea is that I might want to get a general idea of average characteristics of certain instrumented functions across an entire capture.

Possible statistics:

• Total count per instrumented function
• Average time per instrumented function
• Min/Max per instrumented function
• Std deviation per instrumented function

The notification window always pops up... should probably ignore the version check if the version is dev :)

If we follow the workflow idiom described in the previous issue, it should be possible to support automatic loading of symbols from PDB, since the session will be "locked" to a particular executable.

Most sampling profilers will attempt to match sample data against at least the disassembly view since it tracks 1:1; with some work this could also be accommodated in the source view provided accurate debug data from the PDB.

Visual Studio is happy to permit volatile registers to remain live across a call if it has full visibility into the descendant call chain. This can happen with translation-unit local functions that are not inlined into callers. The trampolines should probably save/restore all ABI volatiles.

I have the following code :

#include <iostream>
using namespace std;
int fib(int n)
{
	if (n <= 1)
		return n;
	return fib(n - 1) + fib(n - 2);
}

int main()
{
	for (auto i = 0; i < 10000000; i++) {
		int n = 20;
		cout << fib(n);
	}
	getchar();
	return 0;
}

(thanks https://www.geeksforgeeks.org/program-for-nth-fibonacci-number/)

If I hook main and fib, I would expect to waste all my time in main, I don't, if I checked the live tab the main function did consume any time.
Moreover orbit crashed my exe.

On linux, the "Pdb Size" is always 0 B. Also the UI should be renamed, e.g. to "Binary Size".

Currently Orbit displays thread ids, but many applications use RaiseException or SetThreadDescription mechanisms to set human-readable thread names, which Orbit should attempt to scrape and display.

On Windows you can right-click on a probe of a dynamically instrumented function and get the callstack of that call. This should be also possible in the Linux and remote version.

Callstack window, for instance, never seems to display file/line data, even though it is loaded when you select Visualize and see the dump in the output window.

I would love to be able to export the sampling data to a csv file.

Not sure if this is being tracked anywhere already, but the context switch info (present in the Windows version) would be very useful for tracking how process threads get scheduled on the CPUs.

When selecting a process, Pdb::LoadPdb gets called even before "load symbols"/"load PDB" gets selected for a concrete binary. At these calls a_PdbName is empty and the subsequent calls to nm and bpftrace fails.

ETW won't work without admin privileges, make sure the user knows about it

If you use 'Open PDB' from the File menu to try to, say, load a PDB for kernel32.pdb, it seems to override all Module listings in the sampling view, for instance. If you re-select the process and then re-load the PDB through the Modules window, it seems to fix that. Find PDB from modules for kernel32.dll doesn't seem to cause this same issue. It seems Open PDB is a legacy static analysis entry-point, and can create confusion with the more typical process based workflow.

On Windows, all events (samples, callstack, dynamically instrumented functions) are received and displayed live. This should also be possible on the Linux and remote version.

We actually name our PDB something different from our exe

(sounds odd I know but we name the PDB to be the same as the final release name app.pdb) but the name of the exe we build during development contains other information in its name to allow side by side development

app.debug.x86.exe
app.release.x64.exe

This is because the PDB name and the exe are joined at birth so when after we release our code, other tools like crash handlers, debuggers can find PDB and exe (because we name app.release.x64.exe to be app.exe and now both app.exe and app.pdb have the same prefix)

But this means when users use orbit during development in their area, they are constantly having to rename the binary from app.release.x64.exe to app.exe in order to match the PDB

I believe (and you know I should have checked in the code here first!), but I believe you are using the .exe name to find the .pdb name rather than looking inside the .exe or .dll to extract the PDB name

If that is the case, then the following blog might help. (not by me!) because I believe the PDB name is embedded inside the .exe

http://geekswithblogs.net/vaibhavgaikwad/archive/2011/12/12/148010.aspx

If I've got that wrong you can reject this, but if that's the case it's not finding the PDB correctly ;-)

Currently the capture timeline doesn't display the thread names or ids (normally shown on the left side regardless of timeline position). Nor does it have deterministic coloring; in most profilers this is either user-configured via some mapping mechanism, or deterministically generated via a hash of the name or id.

Would be useful to get client-side feedback about server-side symbol querying and transport back to client.

Right now, this remote symbol load workflow is kinda ok because I can monitor the server-side service spewing output. But ideally, I'd only have to be looking at the client.

Sometimes hooked functions will cause callstacks to stop having valid full backtraces. See attached file for an example.

Sometimes, the instrumented functions have very long names (usually because of namespaces). Sometimes the long names don't fit in the instrumented function view, and sometimes they crowd out the time spent in the instrumented function.

Some ideas, not exclusive:

• Multi-line display of instrumented functions. Could be tied to the vertical zoom feature.
• Always show the time, and clip the function name
• Full function-name pops up as hover text

First of all: Amazing work, this looks great and has been working flawlessly in my (limited) test runs!

While it's not absolutely necessary it would be nice to be able to set the working directory of a program you launch via Orbit.

Cheers, Dario

Latest master (63f023d) crashes on startup when you don't have a params file because it then tries to save the file, which in turn triggers a notification to the UI which hasn't yet been initialized. Specifically
orbitmainwindow.cpp:44 calls OrbitApp::Init() which triggers the UI notification before it calls:

GOrbitApp->AddUiMessageCallback( [this]( const std::wstring & a_Message ) { this->OnReceiveMessage( a_Message ); } ); on line 59 to initialize the callback.

Since this callback has not been set, a std::bad_call exception is thrown from OrbitApp::SendToUiNow.

I built with VS2015 Release x64 and Qt 5.9.3.

When selecting "Load Symbols", the UI freezes for over 10 seconds (mostly due to nm) for a ~ 16 mb binary. It would be desirable to have this async.

Currently saving and loading a session does not save and restore the executable, path, and arguments, which is useful for repeated runs of analysis against the same executable.

Currently function disassembly is transmitted along the connection transport, but it should be possible to permit the application to load a local executable for disassembly display if we store the exe and PDB hashes in the session.

I realise this isn't necessarily the best place for this, but the download linked on this page is limited to ~400kbps. It could be hosted as a github release - which for me is an instant download on a file 5 times the size

When playing with the new headless mode, I found that there is a fair amount of UI lag from input to something happening on screen. It's not consistent, and most of the time, it's quite responsive. But quite regularly, input processing seems to hang for about a second.

After poking around, I found that this only happens when the UI client is connected to a remote service. If I start the client without an active connection, the UI is very snappy. If I have it connected to a remote service, without even having started any profiling actions, the UI will lag.

Video of issue: https://photos.app.goo.gl/CTj2UhbkoTtba4ou5

Currently you must manually select a PDB file to load per process module. It would be useful if you could instead point out a symbol store directly containing multiple PDB files and have Orbit locate the appropriate one for the module. Later, with automatic symbol load support, this could also operate via symbol stores, servers.