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

Does anyone know how to convince the perl debugger to put a breakpoint on waitpid()?

The reason I ask is I've got a program that does a lot of parallel work with fork() and it manages its own children. Unfortunately a module it uses (VM::EC2) was just updated on my system with the most recent version and it seems to now be reaping my child processes for me. I suspect that its happening somewhere deep in the bowels of module dependencies and grepping the code wasn't helpful. I'm hoping to catch the culprit by breaking on waitpid() and taking a look at the stack.

Replies are listed 'Best First'.
Re: Breakpoint on waitpid()?
by MidLifeXis (Monsignor) on Nov 06, 2014 at 17:37 UTC

    Not sure if you can monkeypatch a core sub, but a search might find something useful. Hook::LexWrap or something else similar may also be useful.

    You may also be able to find the change in the source that caused the issue. Found in the Developing section of VM::EC2. You can use git to help find the change by using git-bisect to repeatedly run a test script to identify the problematic commit and see what actually changed.

    Update: Add comment on git-bisect

    --MidLifeXis

[reply]
Re: Breakpoint on waitpid()? (override)
by tye (Sage) on Nov 06, 2014 at 19:38 UTC

    You can globally replace waitpid() with a Perl wrapper and then put a breakpoint in that wrapper. Something like: 

    BEGIN { *CORE::GLOBAL::waitpid = sub($$) { CORE::waitpid( $_[0], $_[1]
+ ) }; }

    [download]

    Update: Added the 'prototype' from prototype('CORE::waitpid') so parsing of code isn't changed by this override.

    - tye        

[reply]
[d/l]
[select]
      Thanks. The BEGIN did the trick and helped find the bug which not surprisingly turned out to be in my code.
[reply]

Back to Seekers of Perl Wisdom