multithreaded debugging

Razvanica has asked for the wisdom of the Perl Monks concerning the following question:

Hello all,
Apparently Tuesday is just as bad. I have this subroutine:

sub StartErrorGuardian
{
    my ($this, $pm) = @_;
    $this->Log("INFO","CWAPP: Starting error guardian\n");
    $continue_flag = 1;
    if ($this->{bThreadStarted} == 0) {
        $this->{bThreadStarted} = 1;
        my $pid= fork();
        if (not defined $pid) {
            $this->Log("ERROR","CWAPP: Could not start error guardian\
+n");
            return 0;
        } 
        if ($pid == 0) {
            $this->Guardian();
        } else {
            return $pid;
        }
    }
    return 0;
}
[download]

which creates (or should create) a child to handle with the Guardian subroutine.

sub Guardian
{
my ($this) = @_;
  my $i = 0;
  while (1)
  {
    {#find any message-box with class #32770 [usually infos and errors
+] and press it's child OK button
      @err_window = FindWindowLike(undef, "", "#32770");
      foreach (@err_window)
      {
        SetForegroundWindow($_);
        SetActiveWindow($_);
        PushChildButton( $err_window[$i], "OK", 0.25 );
      PushChildButton( $err_window[$i], "Abort", 0.25 );
      }

    sleep 1;
  }
}
[download]

If I call the first subroutine from a normal script, everything goes just fine. If I make a fork() and call StartErrorGuardian from the child, nothing happens. And I meen literally nothing. The line my $pid= fork() just blocks the script. It does not pass it. I also tried using Parallel::ForkManager and threads but I get the same result.
So, what I would want to do would be to view some process information before the fork() line. Some kind of debugging, as running the script with -d just crashes at the first fork(). Any suggestions?
Thanks.

Comment on multithreaded debugging Select or Download Code

Replies are listed 'Best First'.
Re: multithreaded debugging by andyford (Curate) on Aug 28, 2007 at 20:24 UTC
Sounds to me like you need to post a complete program that demonstrates the error, otherwise we're either guessing or trying to write a wrapper around your subs which may or may not be similar to what you're actually doing. Also, while you're crafting a minimal test case, put in lots more print statements and don't forget to "use strict" and "use warnings". non-Perl: Andy Ford	[reply]
Re^2: multithreaded debugging by Razvanica (Novice) on Aug 29, 2007 at 09:05 UTC
Thanks Andy I cannot post my complete program because it involves many packages and it would be just a waist of time for you to try and assemble it. I tried to re-create the situation with a simple example but in my example things worked just fine. I realize it is difficult for you to spot an error like this and that's why I am asking if there is a way to debug it myself. I have a line in my code where the interpretor just blocks. It doesn't return an error and it doesn't pass this line. So the question is what can I do to see what's wrong whit it. Thanks.	[reply]
Re: multithreaded debugging by moritz (Cardinal) on Aug 29, 2007 at 09:23 UTC
The line my $pid= fork() just blocks the script. What does it mean? does your program eat up all CPU time? or none at all? Did you insert a `print STDERR "before the fork\n";` and `print STDERR "after the fork\n"` directly before and after that line? And which operating system and perl distribution do you use? Perl 6 in German -- Difficult Sudoku	[reply] [d/l] [select]
Re^2: multithreaded debugging by Razvanica (Novice) on Aug 29, 2007 at 09:58 UTC
Hello moritz My program consumes 0 CPU time and it just prints before the fork if I use your example. I am using ActivePerl 5.8.8 on an WindowsXP OS.	[reply]
Re: multithreaded debugging by BrowserUk (Patriarch) on Aug 29, 2007 at 16:35 UTC
Is that call to fork, the only call to fork in your program? Does this happen the first time you execute that line of code? If not, how many times have you successfully executed that line before it fails? Tip: If you have not already done so, start the task manager, select the "Processes" tab; click View->Select columns... and ensure that "thread count" is checked, click OK. If the "threads" column is off the right hand side of the page, you can drag the column left into a convenient place. Add `print "Check?"; <STDIN>;` before the fork. That will allow you to check the task manager before/after each fork. Beyond that, the most likely scenario is that one or more of the modules you have loaded is not thread-safe.(You do realise that under win32 fork is threads->create in disguise?). Each time you call fork, Perl will CLONE everything you currently have running into a new interpreter. Many modules, and especially many XS and C components of modules are simply not set up for this and get very confused when their resources are CLONED. Also, if you are using objects (for example `$this` in your sample code), then each of your "forks" will get its own copy of each existing object. However, if one or more of those objects contain, or make use of a process global resource--filehandles, sockets, non=thread-safe C libraries etc.--then you are likely to have invisible and unarchitected interactions between the CLONED object instances that think that they are running standalone in separate processes by are not. I wish I could say that life were simpler or better if you switch your program to using threads--but it isn't. There is still no way to create a virgin thread, or defeat the CLONING mechanism. You do however exercise at least some control over when threads are created, and therefore what gets loaded into them. With care, it is possible to resolve most problems onec you understand that you are not operating in a normal forking environment. Not much help I know, but no one is listening. Rather than giving the programmer the ability to control what gets loading when, 'they' appear to insist on trying to pursue the threads are forks mechanism and are adding more CLONING rather than less. Stupid, but true. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l] [select]