Apache OpenOffice (AOO) Bugzilla – Issue 51560
Build with cygwin 1.5.18 fails in instsetoo_native
Last modified: 2017-05-20 10:29:14 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.
Created attachment 27695 [details] "Minimal" testcase
Just to let you know, the problem is fixed in the current snapshots and will be fixed in cygwin 1.5.19.
FYI. Snaphots: <http://cygwin.com/snapshots/>
reproduced on WinXP after letting it process this single line for almost 3 hours :/
Note that the freezing can also be undone by catting /proc/$pid/cmdline for the frozen process...
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
*** Issue 54485 has been marked as a duplicate of this issue. ***
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.
try to replace your "cygwin1.dll" in "/bin" with the latest snapshot of this dll provided here: <http://cygwin.com/snapshots/>
Thank you for helping me. I have already built project instsetoo_native.
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.
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
@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"?
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.
Created attachment 32943 [details] cygcheck -svr
Created attachment 32944 [details] log from failing dmake
> 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.
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)
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
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).
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?
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.
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.
*** Issue 66359 has been marked as a duplicate of this issue. ***
*** Issue 72036 has been marked as a duplicate of this issue. ***
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.