Fun with slave-driving programs

This week in the evenings, I’ve been banging on the inter-process communication (IPC) bug to try and get it working for me, with little success. I finally remembered about noon today that your standard output stream is buffered. So now my blocked testcase has been hit with a plunger (pun intended).

So among the several things I tried was a NS_ERROR break in the IPC code, along
with GDB, the GNU Debugger. Here’s roughly how it turned out…

GDB:  What'cha doing?
XPCShell:  Watching the Web, having a bug.
GDB:  True, true.
(phone rings)
XPCShell:  Hold on... Hello?
run_test():  Whassup???
XPCShell:  Whassup???
run_test(): Hey, where's Perl?
XPCShell: Let me check.  (shouting) Yo, Perl!  Hey, pick up the phone!
IPC:  Avon calling...
Perl: Just a minute... let me start up... (grumbles)  Hello?
XPCShell: Whassup???
Perl: Whuzzuuuuuuuuuuuup?
run_test:  Whassup???
Perl: aaaa
XPCShell: aaaa
run_test: aaaa
IPC: aaaa
GDB: (click)
XPCShell: aaaa
IPC: aaaa... assertion!  *cough* *cough* *hack*
(silence)
Perl: ...
XPCShell: ...
run_test: ...
Perl:  ...
run_test: ...
XPCShell:  It wasn't me.
(user quits XPCShell, and the party ends.)

(With apologies to Budweiser, Shaggy and of course, Charles Stone III. Can we get a
Red vs Blue PSA on this?)

While I wrote this to let off some steam, the important thing here is how GDB —
and XPCShell — reacted when the assertion tripped: GDB remained attached, but
for some reason when the assertion tripped, GDB didn’t break on it and XPCShell
didn’t stop executing. GDB’s “set detach-on-fork off” (which GDB itself
suggested) didn’t help much.

This presents an interesting problem. Assertions are fatal, but XPCShell didn’t
die from it in this case and GDB didn’t pick up on it.

I’ll file a bug on it later, if I can be convinced that I didn’t miss something with GDB. GDB and I have not always understood each other.

That may change. The big reason I undertook IPC is to wrap GDB in a Mozilla app for debugging other Mozilla apps. You would be wise in asking, “Why another debugger? We have Eclipse, GDB, WinDbg, XCode, Visual C++…” The answer is two-fold. One, it would be a common platform using technology Mozilla developers are very familiar with. Two, it’s way past time we built a XPCOM debugger – something that can take the native C/C++ stack and translate it into a multiple-language stack (JavaScript, C++, Python if Mark Hammond’s feeling generous, et cetera).

Linux and Mac have GDB, and Windows has a little-known equivalent called CDB. If I can drive them via IPC, then I can write a common interface for components to drive them. One more layer of abstraction, and I can translate js_Interpret, js_Invoke frames in the C++ stack into JS frames in a XPCOM stack. From there, we’re rolling.

I’m tentatively calling this project Coroner. We’ll see how it goes.

One thought on “Fun with slave-driving programs”

Comments are closed.