in reply to How to find perl line after segfault.

Is it possible to find the perl line number, with backtrace, if possible, of where the error occurred?

Perl doesn't catch segfaults; so by the time it has occurred, perl has lost control and can do nothing.

Otherwise, maybe I should run Devel::Trace, or something similiar, while testing.

Devel::Trace slows things down horribly and produces reams of output. Try Devel::CallTrace instead.

A faulting program:

#! perl -slw use strict; sub segfault { my $x = unpack 'P', \ ""; } sub a { segfault(); } sub b { a(); } sub c{ b(); } c();

A run under Devel::CallTrace:

C:\test>perl -d:CallTrace junk.pl Devel::CallTrace::import (c:/perl64/site/lib/Devel/CallTrace.pm:75-78 +) CODE(0x276280) CODE(0x2762f8) strict::import (c:/perl64/lib/strict.pm:34-37) main::c (junk.pl:10-10) main::b (junk.pl:9-9) main::a (junk.pl:8-8) main::segfault (junk.pl:4-6)

Then, if the faulting subroutine is large, you can enable Devel::Trace on entry and disable it on exit to that one subroutine to get you down to the line number.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

Replies are listed 'Best First'.
Re^2: How to find perl line after segfault.
by Steve_BZ (Chaplain) on Feb 10, 2015 at 12:53 UTC

    Hi BrowserUK,

    It look perfect. Although the code calls scroll up the screen like lightning, I could write them to a file for post-mortem examination. In fact the last few lines would probably be enough.

    I'll see if I can play with it.

    Thanks very much.

    Regards

    Steve

      Although the code calls scroll up the screen like lightning, I could write them to a file for post-mortem examination.

      tee is your friend.

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

        Hi QM,

        It looks like the printouts are produced by CallTrace, So I'd have to modify CallTrace to use 'tee', is that what you are suggesting?

        As it's being called with -d, I don't imagine tee in the child program or the parent program will make much difference.

        At the moment CallTrace writes to STDERR, but it could be tee'd to another file too, do you think?

        Regards

        Steve.

      Generally, when tracking down a segfault, all you are interested in is the last few lines of the output telling you which sub faulted; and possibly how you got there; so I set it running and minimise the session. When I go back a while later, the information I need is left right there on the last line (or last few lines) of the screen.

      If you do redirect to a file, then tail theLog gives you the same information.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

        Hi Browser UK,

        perl -d:CallTrace i-Mage.pl 2> trace.txt

        absolutely did the job and found the problem immediately. It was a Wx::Timer process that I had forgotten about starting off a little early. There seemed to be very little performance overhead, maybe the program loaded a bit slower but after that it seemed about the same as always.

        Now I'd like to call it from open3 like this:

        my @array = qw(perl -d:CallTrace i-Mage.pl); my $child_pid = open3( '<&STDIN', ">trace.txt", *CHILD_ERROR, @array );

        The code starts, but there is no sign of "trace.txt".

        Not sure where I'vwe gone wrong.

        Regards

        Steve.