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

Has anyone encountered or have any pointers to discussion of attempts to use DProf causing Perl to trap?

The code compiles clean under -w and strict. Runs clean both on its own and under debug (-d), but when I try to profile it, perl traps with

Access violation (0xc0000005) at address 0x280742a4.

Stranger still, if I insert a print statement on a previously blank line, I can profile.

If I then comment that line out, I can still profile.

If I remove the print statement but leave the comment, the trap returns.

The commented out print statement will only prevent the trap if it has an argument, and that argument cannot be $/ or $., but can be "" or $^X.

Am I going completely mad? This is repeatable. Any suggestions of how I work out why this occurs?

Is there any way to invoke the profiler but also enter debug mode?

Examine what is said, not who speaks.

Replies are listed 'Best First'.
Re: DProf problem
by chromatic (Archbishop) on Dec 30, 2002 at 05:33 UTC

    It's a known problem. To my knowledge, there's no fix. (Of course, saying that means Rafael Garcia-Suarez, Nick Clark, or Benjamin Goldberg has just posted a patch...) I've had good results from Devel::SmallProf.

[reply]
      There's a "fix" in the presence of Devel::Profiler - a plain module that does the same job as DProf, though not via debugger plugins, and so doesn't tickle any "less stable" parts of the perl source code. It outputs a tmon.out file the same as DProf, so you can run it through dprofpp.
[reply]

      Thanks chromatic. I quite literally thought I was going bananas.

      Had the problem been intermittant rather than reliably reproducable, I might well have taken up psychic healing as a more concrete, down-to-earth occupation.

      Examine what is said, not who speaks.

[reply]
Re: DProf problem
by pg (Canon) on Dec 30, 2002 at 04:19 UTC
    To be frank, I would say this is quite normal, not strange at all

    The access violation message simply indicates that, your program was trying to access some momery, which was not allocated for it or had been freed already. (In this post, whenever I say "your program", it does not just mean the code written by you, but includes all the packages you used, especially your profiling package.)

    Go down to the bottom, Perl program is c program any way. In c, a small careless usage of pointer or any similar mistake, can easily mess up your memory space. It is just so easy.

    Come from a c background, I am not surprised at all to see, that a really slight change to your program, such as add a print statement, or comment out one single line, can "fix" the problem. I have seen this for so many times already. But for sure, that is NOT a fix at all. What happened was that, that small change slightly rearranged your memory space, although your pointer still pointed to a wrong place, but lucky enough, that wrong place was allocated for your program, so your program has every right to access it.

    Update:

    THE REAL PROBLEM IS THE WAY YOU THINKING.

    You first placed a very strong assumption there, saying that Perl is handling everything properly, and your profiling package is also handling things properly. Based on this, then you confirmed to yourself that the error is really strange.

    The right way of thinking is the total opposite:
    1. First you see a problem, and the error message clearly indicates that it is a memory problem. SO THE PROBLEM EXISTS, THAT'S A GIVEN, THAT's THE FACT.
    2. Secondly, as you said, both your experience and my experience confirmed that memory problem comes and goes, and gives people lots of wrong impression.
    3. It only sounds strange if you have a deep assumption that things were being handled properly, there should be no problem. However, we all know that no program is 100% correct.
    4. Yes, it is a commented out line affected the result, so what? Do you know each detail about how it is being handled by Perl? Do you each detail about how it is being handled by your profiling package? There is one thing the same between us, I don't know the details, and you don't know either. Yet there is another thing different between us, you take assumptions, I don't take.
    Also I want to point out that, memory problem is usually not caused by the direct line that trigger the error msg, but could be some line hundred miles away. The reason is that, the line making the mistake, does not neccessary to access unallocated memory itself, but later another victim will access some unallocated memory because of that earlier mistake, and trigger the msg.

    Update 2:

    You said: "In all other circumstances it runs flawlessly?"

    I have two questions for you:
    1. Is it really "flawlessly", or just did not hit the flawed spot? Your program passed 10,000 test cases successfully, can you say for sure that it will pass the 10,001th test case? We know what the answer is. To pass 10,000 test cases flawlessly, is TOTALLY different from "the program is flawless". ANY judgement saying "there IS a flawless program", itself IS flawed.
    2. Even if it is really true that, "In ALL OTHER circumstances it runs flawlessly", does this make it ture that "In ALL circumstances it runs flawlessly"?
[reply]

      Coming from a C background also, I'm also (too:) faliliar with this kind of trap from C-code.

      If you re-read the symptoms I list. The trap is influnced by the presence of commented out code? That is to say, not only does adding a commented out print statement prevent the trap, but value of the arguments to that commented out print statement also influence whether the trap occurs?

      Also note that the program only traps (whether the comment is present or not) when being profiled. In all other circumstances it runs flawlessly?

      Examine what is said, not who speaks.

[reply]

Back to Seekers of Perl Wisdom