Issue 51560

Summary: Build with cygwin 1.5.18 fails in instsetoo_native
Product: Build Tools Reporter: quetschke
Component: codeAssignee: quetschke
Status: CLOSED FIXED QA Contact: issues@tools <issues>
Severity: Trivial    
Priority: P3 CC: davidf, hans-joachim.lankenau, issues, storangen
Version: 680m113   
Target Milestone: ---   
Hardware: All   
OS: Windows, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
"Minimal" testcase
none
cygcheck -svr
none
log from failing dmake none

Description quetschke 2005-07-04 23:52:50 UTC
The W32-tcsh build fails in instsetoo_native with:

... generating setup.ini ...
... copying files into installation set ...
... creating ddf files ...
... creating log file log_SRC680__en-US.log 
... packaging installation set ... 
... makecab.exe (1) ...
(-- nothing, build hangs --)

The following attachment is a standalone testcase, unfortunately it depends on
the absolute path it resides in. To reproduce unpack perlfreeze.zip to d: then
do:
$ cd /cygdrive/d/perlfreeze
$ ./perltest.pl

and see it hang. (In cygwin bash, without OOo build environment set.)

P.S.: Using cygwin 1.5.17 works around this problem.

P.P.S: If you cannot unpack to d: choose a diffrent location and change
openofficeorg_q4.ddf accordingly.
Comment 1 quetschke 2005-07-04 23:53:36 UTC
Created attachment 27695 [details]
"Minimal" testcase
Comment 2 quetschke 2005-07-20 18:45:32 UTC
Just to let you know, the problem is fixed in the current snapshots and
will be fixed in cygwin 1.5.19.
Comment 3 quetschke 2005-07-20 18:47:02 UTC
FYI. Snaphots: <http://cygwin.com/snapshots/>
Comment 4 christianjunker 2005-07-20 18:47:23 UTC
reproduced on WinXP after letting it process this single line for almost 3 hours :/
Comment 5 davidfraser 2005-09-07 18:53:05 UTC
Note that the freezing can also be undone by catting /proc/$pid/cmdline for the
frozen process...
Comment 6 davidfraser 2005-09-08 08:13:01 UTC
Correction: the freezing that can be undone with catting /proc/$pid/cmdline only
works for freezes elsewhere (such as in building extras), not for the makecab
freeze in instsetoo_native
Comment 7 hjs 2005-09-12 13:35:32 UTC
*** Issue 54485 has been marked as a duplicate of this issue. ***
Comment 8 hunglm 2005-09-15 09:40:41 UTC
I have tried with Cygwin 1.5.18 but it stills error. Now, I don't know how to 
make a Setup file. I wants to build a new Setup with language is Vietnamese. I 
have met the errors when I build module instsetoo_native. Please see issue 
#54634.
Comment 9 hjs 2005-09-15 10:59:34 UTC
try to replace your "cygwin1.dll" in "/bin" with the latest snapshot of this dll
provided here:
<http://cygwin.com/snapshots/>
Comment 10 hunglm 2005-09-21 07:20:21 UTC
Thank you for helping me. I have already built project instsetoo_native.
Comment 11 hunglm 2005-09-21 07:21:25 UTC
Thank you for helping me. I have already built project instsetoo_native.
Comment 12 quetschke 2005-12-30 23:58:41 UTC
For the record: Even with a current snapshot some hangs were seen on one system
but could be cured by starting the following command in a new cygwin bash
window:

$ ls /proc/*/fd

If whoever reads this issue (and is not ause ;) ) can reproduce the hang and the
"unhang" with the ls command, please provide details.

CC'ing Henrik as he might actually be the second one.
Comment 13 hesu2 2005-12-31 00:55:52 UTC
I get the hanging in dmake. sed is always shown by ps when hanging (and not
otherwise).

$ ls /proc/*/fd
Unhang dmake for a few seconds (until next sed?)

$ uname -a
CYGWIN_NT-5.1 Ettan 1.5.19s(0.149/4/2) 20051227 16:45:51 i686 unknown unknown Cygwin

/Henrik
Comment 14 quetschke 2005-12-31 01:42:13 UTC
@hesu2: Please try the 24.12.2005 snapshot. I try to reproduce with the 29.12.2005
snapshot.

What hardware is your system? Are you building on a local harddrive? Can you post
(attach) the output of "cygcheck -svr"?
Comment 15 hesu2 2006-01-05 22:24:30 UTC
I've changed to use the 24.12.2005 snapshot. It does not work better.

By running the command below, in a separate bash window, while running dmake I
can build several projects:
$ while true; do ls /proc/*/fd; sleep 2; done

I've had problems coming this far.
cygwin (?) does not seem stable. The configure command coredumps now and then,
but can work just by rerunning the same command line a few times. I get the
impression that the bash window with the loop can disturb the tcsh window.

This is the command line I use currently:

./configure --with-cl-home="/cygdrive/c/Program/Microsoft Visual Studio .NET
2003/Vc7" --with-jdk-home="/cygdrive/c/Program/Java/jdk1.5.0_03"
--with-use-shell=tcsh --with-midl-path="/cygdrive/c/Program/Microsoft Platform
SDK/Bin" --with-csc-path="/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.4322"
--with-frame-home="/cygdrive/c/Program/Microsoft.NET/SDK/v1.1"
--with-ant-home="/cygdrive/c/Program/apache-ant-1.6.5"
--with-extra-dotnet-files="/cygdrive/c/Program/Microsoft Visual C++ Toolkit
2003/include" --with-extra-dotnet-files="/cygdrive/c/Program/Microsoft Visual
C++ Toolkit 2003/lib" --enable-cl-standard

The first --with-extra-dotnet-files is overridden by the second, therefore I
patch winenv.set by:
1. Adding as second last to ILIB: c:\\Program\\MICROS~3\\include; 
2. Appending to CC and CXX -I/cygdrive/c/Program/MICROS~3/include 

I did 2, to make guw.pl find yvals.h. I have very different versions of yvals.h
and don't know whick one to use ("Microsoft Visual C++ Toolkit 2003" or
"Microsoft Platform SDK"). 

I've finally reached the compilation of autodoc/source/display/html in
'build_instsetoo_native'. And there I get compilation errors (see end of
attached dmake-log). I think I've mixed to many h-files and libraries.

I'll attach the cygcheck -svr output below.
Comment 16 hesu2 2006-01-05 22:28:59 UTC
Created attachment 32943 [details]
cygcheck -svr
Comment 17 hesu2 2006-01-05 22:29:56 UTC
Created attachment 32944 [details]
log from failing dmake
Comment 18 quetschke 2006-01-05 22:59:47 UTC
> I've had problems coming this far.

>>This<< is not very specific ;)

> cygwin (?) does not seem stable. The configure command coredumps now and then,
> but can work just by rerunning the same command line a few times. I get the
> impression that the bash window with the loop can disturb the tcsh window.
Guess why I'm asking for small (Not needing an OOo environment) reproducible
testcases. I'm 1000 miles away from my windows boxes therefore I cannot do
any debugging on snapshot problems. But be assured, it works for me. No cores
here. (With 20051224 snapshot, I had problems with a later one).

Btw. they are called snapshots because they are not stable ;) 

The rest of your report is not specific to the topic of this issue, I will not
comment much on it, but let me repeat: The VCTK is not functional, I didn't rip
it out of configure because I hoped I could make it usable but it might have
some rough edges.

Re --with-extra-dotnet-files, the structure of configure allows to use each
switch only once. If you use one twice, the second wins.

So, what would really helpfull now is a small testcase (a shellscrip, programm)
that hangs reproducible on your system. (One of a few hundred tries is enough,
but it must show the problems somehow.) If configure hangs for you: great! It's
a script, strip it down until you find the offending sequence.

Btw., configure cannot core dump, it's a script. (I might be wrong here, but
I never heard about a script that coredumped.) But it might be worth looking
at the core files that you find.
Comment 19 hesu2 2006-01-05 23:21:16 UTC
I just retried configure from my only cygwin window (bash). Below is my result
from ./configure, I don't know the name of the core dump (I've searched for
filenames containing "core"). I don't know how to make the script show more
details (like @echo ON in make). I cannot be more specific.

Admin@Ettan ~/OpenOffice/config_office
$ ./configure --with-cl-home="/cygdrive/c/Program/Microsoft Visual Studio .NET
2003/Vc7" --with-jdk-home="/cygdrive/c/Program/Java/jdk1.5.0_03" --wit
h-use-shell=tcsh --with-midl-path="/cygdrive/c/Program/Microsoft Platform
SDK/Bin" --with-csc-path="/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v1.1.
4322" --with-frame-home="/cygdrive/c/Program/Microsoft.NET/SDK/v1.1"
--with-ant-home="/cygdrive/c/Program/apache-ant-1.6.5" --with-extra-dotnet-files
="/cygdrive/c/Program/Microsoft Visual C++ Toolkit 2003/include"
--with-extra-dotnet-files="/cygdrive/c/Program/Microsoft Visual C++ Toolkit 2003/lib
" --enable-cl-standard
Segmentation fault (core dumped)


Comment 20 hesu2 2006-01-05 23:31:22 UTC
I just found the file sh.exe.stackdump, created about the time I ran configure
as above.
It looks like this, anything I can do to pin it down more?

Exception: STATUS_ACCESS_VIOLATION at eip=6106EEC7
eax=18CA0000 ebx=18EAEE8B ecx=7C801898 edx=00000000 esi=18EAEE8C edi=18EAEF30
ebp=18EAEF68 esp=18EAEE60 program=C:\cygwin\bin\sh.exe, pid 1368, thread proc_waiter
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
18EAEF68  6106EEC7  (610FE4CC, 18EAFBB8, 7C8399F3, 7C802608)
18EAEF98  61002EA2  (000006D0, FFFFFFFF, 00000000, 00000000)
18EAFFB4  610036D9  (00000000, 00000000, 00000000, 00000000)
End of stack trace
Comment 21 quetschke 2006-01-06 00:21:58 UTC
Yes, I forgot to tell you that the cores are called *.stackdump :)

First I would go to the latest snapshot. Debugging old snapshots is, most of the
time, only of limited interest to the developer.

Then I would start shortening the configure script until only the failing part
remains. As you didn't post any output after the configure call I would assume
that something at the beginning fails. Have a look at config.log.

For making bash scripts more verbose look at "man bash" (sh == bash). But in
this case this might not help you as configure is haevily redirecting its
output.

If you would have a bash/sh with debug information you could use addr2line to
get the failing position in the code (but you don't).
Comment 22 hesu2 2006-01-06 00:52:32 UTC
I'll switch back to the latest snapshot later.

>As you didn't post any output after the configure call I would assume that
something at the beginning fails. Have a look at config.log.

I didn't even get a new config.log.

$ man bash
given as the first command after tha failing configure, seemed to hang. It took
a long time to start a new shell, 100% CPU load. 
ctrl-c gave this:
$ man bash
      8 [unknown (0xC58)] sh 2608 child_copy: stack write copy failed,
0x22D950..0x230000, done 0, windows pid 2283652, Win32 error 5
sh: fork: No error
Error executing formatting or display command.
System command (cd "/usr/share/man" && (echo ".ll 13.5i"; echo ".nr LL 13.5i";
echo ".pl 1100i"; /usr/bin/cat '/usr/share/man/man1/bash.1'; echo ".\\\
""; echo ".pl \n(nlu+10") | /usr/bin/tbl | /usr/bin/nroff -c -mandoc 2>/dev/null
| /usr/bin/less -isrR) exited with status 32768.
No manual entry for bash

(later man bash worked properly)
I've seen "child_copy: stack write copy failed" many times, is it due to ctrl-c? 
Comment 23 hesu2 2006-01-06 00:59:38 UTC
Looked a little more at the load.
It is explorer.exe that consumes a lot of cpu after a failing configure (the
prompt is displayed in the bash window) and during a hanging "man bash".

It takes a minute or two for the load to get normal again.
Comment 24 quetschke 2006-01-20 03:45:41 UTC
The original problem of this issue is solved with the current cygwin 1.5.19
version.

If the hanging stuff that can be cured with
$ ls /proc/*/fd
still occurs please open a new issue.
Comment 25 quetschke 2006-06-12 19:17:21 UTC
*** Issue 66359 has been marked as a duplicate of this issue. ***
Comment 26 Martin Hollmichel 2007-06-08 14:46:48 UTC
*** Issue 72036 has been marked as a duplicate of this issue. ***
Comment 27 bjoern.michaelsen 2009-07-20 16:25:00 UTC
Moving comments about this isse from the wiki related here...

*  With cygwin 1.5.18, makecab.exe hangs when run from the build process (but it
works fine when run standalone). So you definitely want to use a snapshot and
avoid cygwin 1.5.18, unless you enjoy wasting half a week of your life debugging
like I did ... 

* With later Cygwin versions (various 1.5.19 and 1.5.20 snapshots) hangs have
been noticed at least by me (User:TorLillqvist) at various stages of the build
on a hyperthreading (Pentium 4) machine, while doing the same build using the
exact same Cygwin version on a single-processor machine worked fine. So it might
be a good idea to turn off hyperthreading.