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

From XS code, I'd like to obtain the address of either the earliest allocated (lowest memory position) SV*, or some other address below which no memory will be dynamically allocated. Any suggestions of a variable accessible from XS code that fits the bill?

The reason is that some coderefs, for example *DynaLoader::, have links in their opcode chains (as traversed by Devel::Size), that are invalid:

C:\Perl\packages\Devel-Size-X>perl -Mblib -MPOSIX -MDevel::Size=total_ +size -wle" print total_size( *DynaLoader:: )" Devel::Size: Calculated sizes for compiled regexes are incompatible, a +nd probably always will be op_last:019D7014 baseop->op_next: 000000D5 ignored! op_last:0189669C baseop->op_next: 000000D3 ignored! op_last:01892C7C baseop->op_next: 00000084 ignored! 69229

In this case I have observed opcode->op_next with values of 0xD5, OxD3, Ox84. Whilst these are obviously erroneous, there are others like 0x00035ffe somewhere in *POSIX:: that look reasonable, but none the less point to pieces of virual memory that do not exist in the process address space, and so attempting to indirect through them is a walk into oblivion.

So my idea is to find some existing XS-accessible variable who's address is a reasonable lower bound below which D::S will not walk. Whilst this will not prevent all traps through uninitialised pointers, from observations, it would catch a large majority of those that I've seen.

Suggestions?


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."

Replies are listed 'Best First'.
Re: [XS]:The address of the first dynamically allocated SV*?
by jettero (Monsignor) on Oct 05, 2008 at 10:23 UTC
    I'm thinking something like the SV finder from perl-src/sv.c might do the trick...
    for (sva = PL_sv_arenaroot; sva; sva = (SV*)SvANY(sva)) { svend = &sva[SvREFCNT(sva)]; for (sv = sva + 1; sv < svend; ++sv) { if (SvROK(sv)) { // find addr } } }

    Am I way off?

    -Paul

Re: [XS]:The address of the first dynamically allocated SV*?
by Anonymous Monk on Oct 05, 2008 at 12:44 UTC

    I think you should ask on P5P, but you should realize that like you cant necessarily assume that all of the pointers in the optree are valid post compilation. One of the processes in the compilation phase may leave these pointers undefined, for instance if they have been optimised away.

    Also, be aware that data pointed to by the optree may not be allocated via SV allocation, as the memory will be shared memory and not process specific memory.

    demerphq

      but you should realize that like you cant necessarily assume that all of the pointers in the optree are valid post compilation.

      The optree traversal code already exists in D::S, I'm not adding to or changing it, only trying to handle the exceptions that can arise from it.

      be aware that data pointed to by the optree may not be allocated via SV allocation

      I was aware the idea was a bit hookey and wouldn't handle some situations, only the preponderance of those I had encountered.

      I also knew there is a better way, try{ } catch { }, but I couldn't get that to work. Turns out I was missing something simple and it is now working, so I can ditch the low-tide mark idea.

      Now all I need is to figure out the gcc/posix equivalent of MSC __try{} __except()?


      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.