Can you modify the code in the program or at least add a statement to the invocation? If so, here are some hints from an older perlmonks post: https://www.perlmonks.org/?node_id=640319 Maybe you could catch a signal and invoke one of the methods described in the post. There is Devel::STrace if you can handle the volume of information. Since it doesn't die, I'm not sure Carp::Always would be of much help except in a signal handler you set up. Does that help any? -john On 9/28/2018 12:39 PM, Warren Young wrote:
On Sep 28, 2018, at 1:13 AM, Stefan Hornburg (Racke) <racke@linuxia.de> wrote:
At any rate, you can strace the Dancer process(es) and see what system calls it does. I’m quite familiar with strace, but I rejected that out of hand at the time, since most Perl code is running way above the OS’s syscall interface.
There are only a couple of cases I can think of where what it says might help. E.g. stuck on accept(2).
No, I really do want to be able to produce a Perl-level stack trace, on demand, without killing the program, as via Carp::confess().
It looks like “perl -d” can’t attach to a running program, either, which would let me use some of these fine Perl modules to produce a backtrace.
I found a partial solution, though:
https://metacpan.org/pod/App%3a%3aStacktrace
Unfortunately for me, it requires Perl 5.10, and this problem happened on a box that’s still running 5.8. (Don’t ask, can’t avoid that.) _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my blog posts at blog.learningtree.com Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.