in reply to odd line in windows

The likely cause is identified by 

try_pl_f4a3.xs: In function 'get_proc_name':
try_pl_f4a3.xs:35:1: warning: function returns address of local variab
+le

[download]

Which is telling you that this:

char* get_proc_name( int processID )
{
    TCHAR szProcessName[MAX_PATH] = TEXT("<unknown>");

    ...

    return szProcessName;
}

[download]

Is a fundamentally flawed piece of code. You are allocating a string on the stack, and then returning a pointer to it from the function. But when the function returns, the stack is unwound and can be reused by other parts of the code.

The only surprising thing here is that you actually get something returned and it doesn't crash.

You need to correct that by allocating space on the heap using Newx() or Newxc() or Newxz(). See perlapi

That said. I wonder why you aren't using Win32::Process::Info?

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.

Replies are listed 'Best First'.
Re^2: odd line in windows
by xiaoyafeng (Deacon) on Sep 07, 2011 at 09:22 UTC
    Many Thanks, BrowserUk! Returning a variable on stack is a fundamental mistake indeed. I change

    TCHAR szProcessName[MAX_PATH] = TEXT("<unknown>");

    into 
    TCHAR * szProcessName = (TCHAR*) malloc( MAX_PATH * sizeof(TCHAR) );

    [download]

    it looks like working well now. but sequenced question is, how free this memory I allocate in C?

    That said. I wonder why you aren't using Win32::Process::Info?

    I don't using Wi32::Process::Info is because it's running a bit slowly. it uses variable way to get Process info and return too large info to me. In my case, I just want to check process name.



    I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

[reply]
[d/l]
[select]
      I change = TEXT("<unknown>"); into = (TCHAR*) malloc( MAX_PATH * sizeof(TCHAR) ); it looks like working well now. but sequenced question is, how free this memory I allocate in C?

      You should not be using malloc(). Did you miss my mention of Newx(), Newxc() Newxz() and the associated link?

      how free this memory I allocate in C?

      If you followed the link, you would have seen Safefree()

      In my case, I just want to check process name.

      I tend to use tasklist for that:

      perl -E"my @tasks = map[ (split)[0,1] ], `tasklist /nh`; say qq[@$_] f
+or @tasks"

      [download]
      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.
[reply]
[d/l]
[select]
[reply]
      but sequenced question is, how free this memory I allocate in C?

      One way is to create a copy, free the memory, then return the copy.

      The following rewrite of get_proc_name() works for me, and frees the memory: 
      SV * get_proc_name( int processID )
{
    char * szProcessName;
    SV * outsv;
    Newxz(szProcessName, MAX_PATH, char);


    HANDLE hProcess = OpenProcess
                     ( PROCESS_QUERY_INFORMATION |
                     PROCESS_VM_READ,
                     FALSE, processID );


    if (NULL != hProcess )
    {
        HMODULE hMod;
        DWORD cbNeeded;

        if ( EnumProcessModules( hProcess, &hMod, sizeof(hMod), &cbNee
+ded) )
        {
            GetModuleBaseName( hProcess, hMod, szProcessName, MAX_PATH
+ - 1);
        }
        else {
            szProcessName[0] = '#';
            szProcessName[1] = 0;
        }
    }
    else {
       szProcessName[0] = '*';
       szProcessName[1] = 0;
    }

    CloseHandle( hProcess );
    outsv = newSVpv(szProcessName, 0);
    Safefree(szProcessName);
    return outsv;
}

      [download]
      Cheers,
      Rob
[reply]
[d/l]

        You only need do one or the other. Not both.

        That is, if you are going to copy the string into an SV in order to return it, there is no reason not to allocate the local copy on the stack:

        char* get_proc_name( int processID )
{
    TCHAR szProcessName[MAX_PATH] = TEXT("<unknown>");
    SV * outsv;

    ...

    outsv = newSVpv(szProcessName, 0);
    return outsv;
}

        [download]

        You save an alloc and free that way.

        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.
[reply]
[d/l]

In Section Seekers of Perl Wisdom