Back to Blog home

Remote QtScript Debugging Rises from its Cold Grave

Published on Tuesday June 16, 2009 by Kent Hansen in Labs Qt Qt Script | Comments

Remember the times when the QtScript debugger was nothing but a maverick project on Trolltech Labs, and you could run the debugger as a stand-alone application? When the debugger was finally integrated into Qt for the 4.5 release, that feature had mysteriously disappeared. Well, today I'm happy to tell you it's been resurrected -- not as part of Qt (yet, at least; that depends on the interest), but right here on the Labs. It needs to be compiled against the latest and greatest qt/master sources, and getting it to link can be quirky (it needs some symbols that aren't exported from Qt by default -- see the project page for details)... Let me know how you get on.

The debugger application embeds a QScriptRemoteTargetDebugger object.

QScriptRemoteTargetDebugger debugger;
debugger.attachTo(host, port);

The debugger emits an attached() signal when it's attached to the target, or an error() signal if it fails to connect. Other than that, the API mirrors that of QScriptEngineDebugger; by default, the standard debugger window is shown when the target's script evaluation is suspended, but you also have access to the individual debugger widgets and actions if you want to create a custom configuration. A "reference implementation" of a debugger can be found in the examples/debugger directory.

So how does your application's script engine become a target that can hook up with a remote debugger? By adding lines like these:

QScriptDebuggerEngine debuggerEngine;
debuggerEngine.setTarget(scriptEngine);
debuggerEngine.listen();

The listen() function tells the debugger engine to wait for the debugger (UI) to initiate the connection; you can do it the other way around (have the debugger wait for the target to connect) by calling listen() on the debugger side and connectToDebugger() on the target side. The debugger engine emits a connected() signal when a connection has been established, or an error() signal if there's a problem.

Once you're connected, your application can start evaluating scripts as usual; the debugger engine will suspend evaluation and communicate with the debugger as necessary. There's an example application in the examples/debuggee directory that demonstrates this. To try it, first start examples/debuggee, then start examples/debugger.

The current implementation uses QDataStream with the debugger's own internal types to transport data from one end to the other; I'd like to also add support for protocols like those of GDB and Xdebug, so that other debugging tools could be used. It would be fun to see if Qt Creator's existing GDB integration can be utilized for QtScript debugging too. :-) Anyways, happy remote debugging! Comments and suggestions concerning API, functionality and protocols are welcome.

Subscribe to Our Blog

Stay up to date with the latest marketing, sales and service tips and news.

The blog comment system has been migrated to a new platform. If you face any issues, please let us know via feedback@qt.io.