This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bash problems, strace, performance, etc. Solved! (?)


I think I *may* have figured out what the problem
was! There *may* have been a "ghost" open window, each, of Adobe
Acrobat Reader (AAR) for 'cpan.1.pdf', and 'cpanp.1.pdf', for
prior versions of these renderings that I had created. The two
AAR tasks may not have shown up on the task bar, because that
sometimes happens on Vista. I don't know why. If I had looked in
Task Manager Processes tab, I might have been able to see them
there, but I never looked. I know they did not show up in the
Task Manager Application tab, or the Task Bar, because I looked
in both places. I looked at the Processes tab but I was looking
for Cygwin apps, not AAR.

I just did two things which lead me to the above conclusion:

*  I was able to run 'man2pdf' successfully on 'cpan.1' and
  'cpanp.1' without incident or delays.

* When I went to 'mv' the resulting PDFs ('cpan.1.pdf', and
  'cpanp.1.pdf') the command line hung, just as the other scripts
  had in my first report (before the crashes). Then, I noticed an
  open AAR window to one of the two PDFs. When I closed the AAR
  window, the 'mv' immediately completed successfully.

My interpretation of the original script crash is that somehow
AAR ties up a file (locking?) in a way that Cygwin does not
recognize, and Cygwin code trying to deal with the file
eventually times out, causing the prior error message, 'strace',
and crash of the app.

This means (a) that my prior suspicions were wrong, and
(b) performance was never an issue except for the resulting
effects, after the crash.

Also, thinking back this same kind of thing may have bitten
me before. This kind of thing might make sense for the FAQ?
I'm always aware of my anti-virus as a potential snag, I've
completely spaced on these errant ghost app sessions, such
as Adobe Reader, in this case.

See my comments, below.

On 10/21/2010 7:40 PM, Cyrille Lefevre wrote:

> Le 21/10/2010 23:22, Lee D. Rothstein a écrit :

>> On 10/21/2010 1:22 AM, Cyrille Lefevre wrote:

>>> seems to work here ! even on cpan.1 generated from pod2man...
>> Just curious, what part of 'man2pdf' did you run that indicates
>> that it works on your system? (Commands and options, would be
>> most helpful.)

I am baffled by the following command line*s*:

> dos2unix < man2pdf > /usr/local/bin/man2pdf

'man2pdf' was pure LF terminated lines when it left here.

> perl -pi -e 's/=letter/=a4/' /usr/local/bin/man2pdf

You use a4 paper and you changed the format; good point; I missed
that for I18N.

> echo echo /tmp > /usr/local/bin/tmpdir

'tmpdir' is a command, not a "place'. $TMPDIR is a place, that
the script 'tmpdir' considers as the master temp dir if
available. You do not have a copy of 'tmpdir'.

> echo > /usr/local/bin/man_blrm

'man_blrm' is my 'gawk' script that removes superfluous (only)
blank lines from a man page source that the Postscript
rendering in 'groff' barfs on.

> echo 'case $1 in *.*) echo ${1##*.} ;; esac' \

>> /usr/local/bin/fn_ext_last

Yes, shell wild cards are another way of getting the file name
extension. But, I'm not sure they work with multiple file name
extensions, as in 'cpan.1.pdf'.

> chmod +x /usr/local/bin/man2pdf /usr/local/bin/tmpdir \
> /usr/local/bin/man_blrm /usr/local/bin/fn_ext_last
> mkdir -p /tmp/man/man1
> cd /tmp/man

> pod2man /usr/lib/perl5/5.10/ > man1/cpan.1

I wasn't using 'pod2man' to generate the "pages". 'pod2man' had
already been done by the responsible person for the Perl
packages. I was using these installed 'man' "page" to generate PDFs

can't follow the following, at all:

> MANPATH=$PWD man2pdf cpan.1

'MANPATH' on my system is a list of all the master man directories,
some of which, on my system, are not standard, i.e.:

$ echo $MANPATH

/local/man:/local/usr/man:/usr/local/man:/usr/share/man: ...

> cd /usr/lib/perl5/5.10/pods
> ls |
> sed 'h;s|\.pod|.1|;x;G;s|\n| > /tmp/man/man1/|;s|^|eval pod2man |' |

I am not creating pods. I'm taking man page (groff) sources and
rendering them to PDF.

> parallel # see attachment, please, keep the copyright, thanks :-)

Again, performance is not the issue; crashing is.

When I have some time, I'll look at your parallelization stuff,
it's interesting. However, I'm almost never concerned with performance
unless I have a rogue app somewhere.

>>> do you have bash-completion, if yes, get rid of it and try again.
>> Bash completion is installed on my system but never loaded; i.e.,
>> /etc/bash_completion is not sourced in '~/.bashrc', or
>> '~/.profile', or anywhere else.
>> Why do you think this is the cause of the problem?
> bcoz bash-completion is known to cause performance problem to bash...

>> You might be combining two parts of my report in a
>> misleading way. The slowdown was due to the errant Bash
>> sessions not the cause of them. A reboot eventually returned
   ^^^^^^^^ script invocations
>> the system to its normal sluggish state (for Cygwin on a 64-bit
>> version of Windoze). Or, what don't I understand?

Again, you're focusing on performance; I was looking for help
WRT the crash. But, I think I've figured it out, now.

> bash is also known to be a *piece of crap* in I/O, done.

Doesn't matter.

> no problem, here, except a windows memory exhausted ! then bash died...
> almost the first time I see this windows box !!!

Not following the above.

> well, and how do you expect I test your man2pdf script the right way w/
> these missing pieces ?

That was *extremely* dumm of me. Sorry. If you're interested, I'll
send you the pointers to all the pieces once I post them at Club-G.

Thanks, the interchange forced me to look at it again.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]