http://www.perlmonks.org?node_id=1075116


in reply to Perl 5.8.8 on Windows, Hang in I/O operations using perlembed

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

Replies are listed 'Best First'.
Re^2: Perl 5.8.8 on Windows, Hang in I/O operations using perlembed
by perlstart_08 (Initiate) on Feb 17, 2014 at 18:47 UTC

    @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