GammaRay - Introspection/Debugging Tool for Qt Applications

Peter K├╝mmel syntheticpp at
Tue Nov 1 20:56:53 GMT 2011

On 01.11.2011 08:58, Volker Krause wrote:
>> I've also tried to attach to console apps without success.
>> Then I realized that you use the hijacked process to show
>> the GammaRay mainwindow which is not possible in a
>> QCoreApplication executable.
>> So I wonder how difficult it would be to run GammaRay in a
>> different process? Then an IPC mechanism is needed for all
>> the information. Would this be fast enough? Do you plan
>> to add this in future?
> I'd love to have that, for console apps, remote debugging on an embedded
> system, and for less interference with the debugged process :)

Couldn't you reuse some IPC parts from KDAB's canceled test tool ;)

> You can probably get a large amount of the features by having some kind of
> network transparent QAbstractItemModel adapter. But some feature need direct
> memory access, like rendering of a second QGraphicsScene view, unless you want
> to send pixmaps over IPC.

Sounds manageable.

>> Is there a single point where all the information of
>> the target process goes through or is it all over the place?
>> I assume at least each plugin pulls information by itself.
> Most of it goes through probe.cpp and the object models provided by it,
> however all the plug-ins access raw QObject pointers they retrieve from those
> models (and thus are bound to the same process).

OK, but when the plugins also support ipc, it should be possible to remote
debug/monitor for instance a state machine.


>> And how much does the current code depend on x86/64?
>> Would it be hard to support PPC?
> There are two injectors that are very architecture specific ("windll" on
> Windows/MSVC and "preload" on Mac), they assume a specific layout in memory
> and rewrite assembly code to intercept function calls.
> All other injectors should be architecture independent ("preload" on Linux,
> "gdb" on any Unix and "style" everywhere), but I don't think they have been
> tested yet on non-x86 either.
> Probably something I should document in the wiki...
> regards
> Volker

More information about the kde-core-devel mailing list