Also discovered that the debugger stub doesn't properly handle doing a fork() in Perl. For example, if you do the following:
print "Starting up\n";
my $pid = fork();
if (!defined($pid)) {
print "fork failed";
exit 1;
}
if ($pid == 0) {
while (1) {
print "I am the parent\n";
sleep 3;
}
} else {
while (1) {
print "I am the child\n";
sleep 1;
}
}
If you try to debug this program, both processes will be updating the Komodo debugger IDE simultaneously and the IDE will become quite confused. I discovered this the hard way when I set a breakpoint in my server code, the code stopped, and then the execution pointer in the IDE continued to move because the other process was updating it.
I have written a preliminary patch which overloads CORE::fork in a begin block. Looks like it is basically working (a second debug connection is established for the child and appears to work as I would expect it) but I have a bug to work out where Log4Perl is failing now as a result of my change.
Also, still having more problems where the DBGP source command isn't working as expected, so when I browse the stack the IDE shows the wrong source files. I already fixed a similar issue in the debugger stub, but it looks like there is another case I didn't see before. Seems reproducible though, so I should be able to trace through it.
The globals window doesn't appear to work at all. I haven't even looked at that yet.
And browsing the stack only shows the local variables for the innermost frame. Was planning on looking at integrating the debugger stub with the CPAN PadWalker module so you could see the locals at any frame. Looks like the IDE fully supports it and is sending the proper DBGP commands, so if I get the stub to return the proper content, I am relatively confident that the IDE will render it properly.
On one hand, I think Komodo is a great product and the developer has been very helpful on the forums. On the other hand, I really wasn't expecting so many integration problems. Most of these are pretty straightforward to fix but the $295.00 pales in comparison to the cost of the amount of time I have burned over the last four days.
In a bit of irony, I have done all the work using the evaluation version since I wasn't going to buy any licenses until I was confident the debugger would work with our application. Maybe I can trade the half a dozen bug fixes I have made for a license key.
