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

Hi all,

We are running Perl 5.8.8 on Windows 2008

We have a c++ application which uses perlembed to run perl scripts within C++ application. The code is proprietary so can't share the stack trace below Perl_call_sv.

The hang is seen below. Can you please help with any pointers to see why the thread is hung and any tracing mechanism to see the file name.

I tried to use PERLIO_DEBUG=test.txt but the problem is we are a multi threaded application; each thread is running different perl script and only the below thread is hung. test.txt contains traces from all the threads making debugging it more difficult.

ntdll!NtReadFile+0xa
KERNELBASE!ReadFile+0x7a
kernel32!ReadFile+0x59
msvcr80!putch+0x33b
msvcr80!read+0x10e
msvcr80!filbuf+0x8e
msvcr80!fread_nolock_s+0x1ea
msvcr80!fread_s+0x90
msvcr80!fread+0x18
libperl!PerlIO_setpos+0x38e
libperl!Perl_reentrant_size+
libperl!Perl_runops_standard
libperl!Perl_call_sv+0x780

[download]

Replies are listed 'Best First'.
Re: Perl 5.8.8 on Windows, Hang in I/O operations using perlembed
by BrowserUk (Patriarch) on Feb 15, 2014 at 18:43 UTC
    test.txt contains traces from all the threads making debugging it more difficult.

    I strongly suggest that you add some perl level tracing in the scripts that uses threads->tid; as (the first) part of each trace message.

    Trying to debug threaded apps with traces that mix the thread's output together without identification is a fool's errand.

    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".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
Re: Perl 5.8.8 on Windows, Hang in I/O operations using perlembed (input)
by tye (Sage) on Feb 15, 2014 at 17:12 UTC

    Windows's ReadFile() is waiting for data to arrive. It looks like a very mundane situation. You don't say anything about what kind of construct you are trying to read from so nobody is likely to be able to tell you more than just that.

    - tye        

[reply]

      Actually, I take that back. I don't see any correct way for PerlIO_setpos() to end up calling fread().

      My first guess is that the pointers in a PerlIO_func struct got shifted or you are using parts of multiple, incompatible versions of Perl so that an attempt to call the function held in the PerlIO_func.Seek slot actually ends up calling the code that should be pointed at by the PerlIO_func.Read slot.

      - tye        

[reply]
Re: Perl 5.8.8 on Windows, Hang in I/O operations using perlembed
by bulk88 (Priest) on Feb 17, 2014 at 02:39 UTC
    You probably have a pipe or socket as a handle. There was no data in the buffer. Therefore you will block until data is written to the pipe/socket, or the other side handle is closed. Unless you provide the pure perl line we can't really help you (in the watch window look at my_perl->Icurcop on threaded perls, or PL_curcop (I think, I rarely use no-threads perl) to find out where you are pure-perl wise). Also your callstack is probably garbage due to a lack of symbol files. That looks like a VC callstack, when there are symbols, the c funtion prototypes and their values are shown, when there are no symbols you get a function name and 1 hex offset. Also, if the function is NOT exported, and you do not have symbols, the name on the function can be completely wrong. The "name" you see without symbols, follows this algorithm, take the instruction pointer, then look at the export table of the DLL, find the nearest previous function call instruction pointer wise, use its name, then write the offset to the instruction pointer. msvcr80 looks correct, so does kernel32 and ntdll. Those 3 used stripped symbols (semi-private). libperl is probably guessed. All 4 functions you showed are exported from perl51*.dll. Some of the msvcr80 functions are not exported, so there a symbol file took effect. All functions Perl_runops_standard will call, begin with Perl_pp_*. Perl_runops_standard will never call Perl_reentrant_size. Either a tailcall happened (symbols won't help you), or frame pointer omission (more likely this scenario, symbols for libperl.dll will help).
[reply]

      @tye - I'm a newbie in the C++, Perl integration world. I will replicate the issue with Perl PDB file and then see if i can get a proper stack

      @BrowserUK - Thanks for your inputs. We will try to add thread level trace in PERLIO_DEBUG and verify the thread which is waiting on Read call

      @bulk88 - Thanks for your inputs. We are just running a process and getting the output via pipe in one case and in another case we are writing it to a file. open(MAIL, "| /bin/mailx -s test user\@localhost ") We will use the perl PDB to get the correct stack trace. We will use the combination of Perl debug tracing as listed below and PERLIO_DEBUG option to narrow down the issue

      set PERLDB_OPTS= N f A L=listing

      I will update with my research and findings

[reply]

Back to Seekers of Perl Wisdom