cygheap version mismatch ?
It looks like I have managed to screw up my cygwin installation more or less completely :o( What I did: I was trying out some of the latest snapshots, and noticed that KDE would not start with them. So I kept trying, changing back and forth between the different cygwin1.dll files, rebooting and running rebaseall -v between tries. Result: Now, whenever I try starting XWin (whether with KDE or without) it will fail with the message such as the following: C:\cygwin\usr\X11R6\bin\XWin.exe (4056): *** cygheap version mismatch detected - 0x6179/0x101. You have multiple copies of cygwin1.dll on your system. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. I have tried putting the original cygwin1.dll back, including reboot and rebaseall -v, but still the same results. As it is, the only thing I can do is run bash in a dos window. There are definitely no multiple copies of that file. I renamed all the other snapshopts to something_else._dll and searched all disks. Any pointers or advice would be greatly appreciated. Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygheap version mismatch ?
Larry Hall lh-no-personal-replies-please at cygwin.com writes: Start here: Problem reports: http://cygwin.com/problems.html Yes thank you, I looked through the FAQ and instructions, and also googled around but didn't find anything specific on this. Also, did you start any Cygwin services? No. No services. But I got it working again now by running setup and reinstalling everything related to X11. Still, there is the nagging doubt about whether I didn't miss a package or two in the reinstall and perhaps have a time-bomb lurking in the depths of the system that may blow up in my face somewhere a little further down the road. I would have preferred to actually understand what was happening - were the files corrupt ? How did it happen ? If they weren't, how would reinstalling the same files fix the problem ? Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygheap version mismatch detected
I seem to have managed to completely crash my cygwin installation :o( After trying some of the recent snapshots I noticed KDE would not start. So I tried with different snapshots (including the original cygwin1.dll) a few times, rebooting and running rebaseall -v between tries. Now neither KDE nor XWin will start at all, instead I get the following message: C:\cygwin\usr\X11R6\bin\XWin.exe (2400): *** cygheap version mismatch detected - 0x6179/0x101. You have multiple copies of cygwin1.dll on your system. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. There are definitely no multiple copies of cygwin1.dll files on the system. I have renamed the other snapshots something_else._dll and searched through all disks just to make sure. I have restored the original cygwin1.dll, rebooted and run rebaseall -v (with no errors) any number of times but the results are still as above. Running from a dos window still works but that's about it. Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
20050208 hyperthreading bug is back ?
Summary: I reported before that the 20050206 snapshot appeared to fix the hyperthreading bug for me. Now it seems that the next snapshot 20050208 broke it again. Test Case: -- Command: find z | while read f; do chown username $f; done; and a longer version of the test case command, (same results): export i=1; find z | while read f; do printf %8i: %s\n $i $f; \ chown username $f; ((i++)); done; Note: z is a directory tree under /cygdrive/c with 4000 odd files in it. Result: --- after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL The first number varies (2, 4, 8) as well as the number after bash which I take it is the pid. NOTE: The error only occurs when I run this from the command prompt. I put the same command in a file (preceded by a #!/bin/bash -line) and called it chownz.bash ./chownz.bash completes as expected . ./chownz.bash also completes as expected The same test runs without problems on the 20050206 snapshot. My system: -- HP Pavilion, P4HT3.2G, 1G memory, 200G SCSI HD $ uname -a CYGWIN_NT-5.1 nodename 1.5.13s(0.118/4/2) 20050208 14:21:58 i686 unknown unknown Cygwin I tried to include the output from 'cygcheck -s -v -r | tee cygcheck.out' but the interface will not accept lines longer than 80 chars. I can mail it across, just let me know. Regards CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 20050208 hyperthreading bug is back ?
Rolf Campbell thats.unpossible at gmail.com writes: CV wrote: after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL And it appears I spoke too early before. I too, still see a problem: 1424 [exiting thread] make 2052 cygthread::stub: erroneous thread activation, name is NULL. None of my simple test cases seems to fail, but in the guts of a 2-hour build, I get that error message and things grind to a halt. OK, but then it would perhaps be interesting to know if the 20050206 snapshot works for you there - or, in case it fails, whether the error is the same or different ? Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes: I'm not naive enough to think that I've solved all of the hyperthreading problems but I would like people to try today's snapshot (or any snapshot newer than today's) and report on whether it solves the problem or not. If it doesn't, please provide as simple a test case as possible so that I can duplicate the problem. Working well here: HP Pavilion with P4HT3.2G. I only ran into the hyperthreading bug the other day when trying to chown a large directory tree. It would bomb out after a minute or two (a few hundred to maybe a thousand files). With the new build (whether stripped with --strip-debug or unstripped) the command completes as expected. Another vote for the silver star ! Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: hyperthreading fix, try #1
CV or254498 at hotmail.com writes: Another vote for the silver star ! Oops, I meant the gold star of course ! Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
connection refused to www.cygwin.com
Apologies if this is slightly off-topic. I am getting The connection was refused when attempting to contact www.cygwin.com in the browser. Is there a problem with the cygwin site ? (The above message is in Netscape, IE claims it was not found, ping works OK) CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FileRunner under cygwin - simple compilation fails.
Igor Pechtchanski pechtcha at cs.nyu.edu writes:
On Wed, 19 Jan 2005, CV wrote:
After running the command gcc -E ext.c -o ext.pre and then
comparing ext.pre with tcl.h I think I can identify some of
the included bits, eg. the following:
You could also just look at the '# line' lines, e.g.,
'# 159 /usr/include/tcl.h 3 4'
Yep, those lines are in there. Quite a number of them in fact.
The most interesting thing is whether Tcl_CreateCommand is declared, and
whether its signature corresponds to its usage in ext.c.
Here are the relevant bits.
I'm afraid I am not conversant enough with pointer and data type
mechanisms in c to make total sense of it. It appears to be fairly
advanced stuff ...
And I am seeing strange behaviour in the program, on one
particular point, though we best not go into details on that
yet as I am not sure it is anything to do with cygwin.
But it would be useful to eliminate the doubt about
these warnings first. If you can see any obvious mistake
below I'd appreciate it.
-- from tclDecls.h, included at pre-compile time
/* 91 */
EXTERN Tcl_Command Tcl_CreateCommand _ANSI_ARGS_((Tcl_Interp * interp,
CONST char * cmdName, Tcl_CmdProc * proc,
ClientData clientData,
Tcl_CmdDeleteProc * deleteProc));
...
Tcl_Command (*tcl_CreateCommand) _ANSI_ARGS_((Tcl_Interp * interp,
CONST char * cmdName, Tcl_CmdProc * proc, ClientData clientData,
Tcl_CmdDeleteProc * deleteProc)); /* 91 */
-
-- usage in ext.c ---
... (declarations at the top of the file)
static int GetTimeFromSecs(ClientData clientData, Tcl_Interp* interp,
int argc, char* argv[]);
static int GetTimeFromSecsSetFormat(ClientData clientData, Tcl_Interp* interp,
int argc, char* argv[]);
static int GetStringFromMode(ClientData clientData, Tcl_Interp* interp,
int argc, char* argv[]);
static int GetUidGidString(ClientData clientData, Tcl_Interp* interp,
int argc, char* argv[]);
... (a little further down)
int
Ext_Init(interp)
Tcl_Interp *interp; /* Interpreter for application. */
{
Tcl_CreateCommand(interp, GetTimeFromSecs, GetTimeFromSecs, NULL, NULL);
Tcl_CreateCommand(interp, GetTimeFromSecsSetFormat,
GetTimeFromSecsSetFormat, NULL, NULL);
Tcl_CreateCommand(interp, GetStringFromMode, GetStringFromMode,
NULL, NULL);
Tcl_CreateCommand(interp, GetUidGidString, GetUidGidString, NULL, NULL);
...
--
and, again, the warnings from the compilation ---
gcc -Wall -fPIC -O3 -I/usr/include -I/usr/include -I/usr/include/X11
-c -o ext.o ext.c
cc1: warning: -fPIC ignored for target (all code is position independent)
ext.c: In function `Ext_Init':
ext.c:95: warning: passing arg 3 of `Tcl_CreateCommand' from
incompatible pointer type
ext.c:96: warning: passing arg 3 of `Tcl_CreateCommand' from
incompatible pointer type
ext.c:97: warning: passing arg 3 of `Tcl_CreateCommand' from
incompatible pointer type
ext.c:98: warning: passing arg 3 of `Tcl_CreateCommand' from
incompatible pointer type
...
--
Don't know, but actually it only refuses to enter the
C:/cygwin/cygdrive directory, where the windows disks
are mounted. It is ok everywhere else.
Ha. /cygdrive is a virtual directory, intended to access Windows disks
from inside Cygwin, not vice versa. Why go to C:/cygwin/cygdrive/c/, when
you can simply go to C:/?
I would have preferred to have a consistent view of the
directory tree from within cygwin, starting from / as
the root, but as I say it's a minor point.
Cheers CV
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: FileRunner under cygwin - simple compilation - Success.
Igor Pechtchanski pechtcha at cs.nyu.edu writes: Arg #3 is a pointer to a function (Tcl_CmdProc). See where that's declared *in the preprocessed file* (so that all macros are expanded) and see if your declarations of GetTimeFromSecs, etc, correspond to it. The most obvious mismatch is probably the const char* argv[] vs. your char* argv[]. OK, this is the definition of Tcl_CmdProc in the preprocessed file: --- typedef int (Tcl_CmdProc) (ClientData clientData, Tcl_Interp *interp, int argc, const char *argv[]); And here is GetTimeFromSecs also from the preprocessed file: --- static int GetTimeFromSecs(ClientData clientData, Tcl_Interp* interp, int argc, char* argv[]); ... so I changed char* argv[] to to const char *argv[] at the affected spots in the source code in ext.c. It now compiles and links without warnings and the application (FileRunner) works with the resulting .dll. I can't be certain yet if it also fixed the problem I was having, since it was intermittent. I can see how this change makes the data types agree and gets rid of the warnings. But I am quite baffled as to why this should be declared as a constant !? That argument seems to be a pointer to an array of input arguments to a function. Surely such a pointer would have to change dynamically during execution and no way could it be constant !? Oh well. These comments sort of give away my level of (in)experience I suppose... :o) Another thing is that, seeing what it was all about, I can't imagine that the warnings actually mattered, or made the resulting .dll work differently in any way (?) Can't be sure if I'm through with this yet but your advice saw me through a couple of initial hurdles in style here. Big THANKS, again, for your excellent help ! Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
FileRunner under cygwin - simple compilation fails.
Hello, FileRunner is a nifty little file manager that I have been using for years under Linux and I would like to have it under cygwin as well. But I am stuck with installation on cygwin because I can't get the included, very simple c-program to compile, probably due to my own cluelessness about where the various libraries live etc. (haven't really compiled anything under cygwin yet) The c-program basically defines a few entry points into TclTk. The rest of FileRunner is written in TclTk. Below is detailed info, including the very simple makefile, what changes I made to it and the output from the compilation attempt. My own ideas about what might be wrong: 1. TclTk libraries not found (?) I would have expected to find them at /usr/lib/Tcl8.4 and .../Tk8.4, but only the Tk one is there and it appears to be almost empty. It only has one file: pkgIndex.tcl I tried pointing the makefile at that directory, and also at /usr/lib directly but the results were the same. Couldn't find these libs anywhere else either. 2. I am not sure if it is enough to just change ext.so to ext.dll in the makefile, as I did, or if any other switches or libraries possibly come into play for compiling dll's. 3. Possibly TclTk8.4 is too new (?) The current version of FileRunner was designed for 8.0. (?) I am probably missing something obvious. Any pointers would be appreciated. And also nice to hear if anyone has got FileRunner working under cygwin. (I tried googling around for any experiences with this but turned up nothing.) My cygwin installation is up to date (done recently) and fairly complete, certainly including everyting to do with TclTk and its associated libraries. TIA CV Here is the detailed info: --- The makefile, based on the one provided for Linux and modified as follows: - Changed the include directories, see below - Also tried with plain /usr/lib as inc-directories, with similar results - Changed ext.so to ext.dll and also symlinked X11 to X11R6 under /usr --- # Change this if you have this stuff somewhere else. # TCLINC = /usr/lib/tcl8.0 # TKINC = /usr/lib/tk8.0 TCLINC = /usr/lib/tk8.4 TKINC = /usr/lib/tk8.4 X11INC = /usr/X11/include CFLAGS = -Wall -fPIC -O3 -I$(TCLINC) -I$(TKINC) -I$(X11INC) CC = gcc all: ext.dll ext.dll: ext.o gcc -shared -Wl,-soname,ext.dll -o ext.dll ext.o --- The output from compilation/linking: --- gcc -Wall -fPIC -O3 -I/usr/lib/tk8.4 -I/usr/lib/tk8.4 -I/usr/X11/include -c -o ext.o ext.c cc1: warning: -fPIC ignored for target (all code is position independent) ext.c: In function `Ext_Init': ext.c:95: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:96: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:97: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:98: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:99: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:100: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:101: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:102: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:103: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:104: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:105: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:106: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:107: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:108: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c:109: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type ext.c: In function `GetEuid': ext.c:567: warning: int format, uid_t arg (arg 3) gcc -shared -Wl,-soname,ext.so -o ext.so ext.o ext.o(.text+0xcac):ext.c: undefined reference to `_Tcl_CreateCommand' ext.o(.text+0xcd2):ext.c: undefined reference to `_Tcl_CreateCommand' ext.o(.text+0xcf8):ext.c: undefined reference to `_Tcl_CreateCommand' ext.o(.text+0xd1e):ext.c: undefined reference to `_Tcl_CreateCommand' ext.o(.text+0xd44):ext.c: undefined reference to `_Tcl_CreateCommand' ext.o(.text+0xd6a):ext.c: more undefined references to `_Tcl_CreateCommand' follow /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../libcygwin.a(pseudo-reloc.o) (.text+0x52): undefined reference to `___RUNTIME_PSEUDO_RELOC_LIST_END__' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3
Re: FileRunner under cygwin - simple compilation fails.
Thanks for your help Igor. Actually I found the answer by googling for ___RUNTIME_PSEUDO_RELOC_LIST__. Someone had that problem fixed by upgrading to the latest binutils. I checked and my binutils was a 2002something version while there is a 2004... one available. What I can't understand is how an old 2002 version of binutils ended up on my system. I installed from scratch over the internet just before christmas umm.. maybe six weeks ago or so and I assumed I got the latest version of everything. I must have assumed wrong !?. (unless the subsequent kde installation set it back ??) I upgraded binutils to the 2004 version with setup and ext.c now compiles. I still get the incompatible pointer type warnings at the compilation stage but it links and creates the .dll with no complaints and the application starts up. It does seem to behave funny, refusing to enter certain directories, but that I'll have to investigate separately. Thanks again. CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FileRunner under cygwin - simple compilation fails.
Igor Pechtchanski pechtcha at cs.nyu.edu writes: Did you check whether tcl.h gets included? If it is, it could be a bug in ext.c. I ran gcc -E as you suggested but was not sure how to interpret the results. Looking at it a bit more closely I think it is clear that tcl.h _does_ get included: After running the command gcc -E ext.c -o ext.pre and then comparing ext.pre with tcl.h I think I can identify some of the included bits, eg. the following: tcl.h --- /* * Procedure types defined by Tcl: */ typedef int (Tcl_AppInitProc) _ANSI_ARGS_((Tcl_Interp *interp)); typedef int (Tcl_AsyncProc) _ANSI_ARGS_((ClientData clientData, Tcl_Interp *interp, int code)); typedef void (Tcl_ChannelProc) _ANSI_ARGS_((ClientData clientData, int mask)); typedef void (Tcl_CloseProc) _ANSI_ARGS_((ClientData data)); typedef void (Tcl_CmdDeleteProc) _ANSI_ARGS_((ClientData clientData)); typedef int (Tcl_CmdProc) _ANSI_ARGS_((ClientData clientData, Tcl_Interp *interp, int argc, CONST84 char *argv[])); ext.pre --- typedef int (Tcl_AppInitProc) (Tcl_Interp *interp); typedef int (Tcl_AsyncProc) (ClientData clientData, Tcl_Interp *interp, int code); typedef void (Tcl_ChannelProc) (ClientData clientData, int mask); typedef void (Tcl_CloseProc) (ClientData data); typedef void (Tcl_CmdDeleteProc) (ClientData clientData); typedef int (Tcl_CmdProc) (ClientData clientData, Tcl_Interp *interp, int argc, const char *argv[]); It does seem to behave funny, refusing to enter certain directories, but that I'll have to investigate separately. Perhaps related to the above warnings? Don't know, but actually it only refuses to enter the C:/cygwin/cygdrive directory, where the windows disks are mounted. It is ok everywhere else. mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /cygdrive/c type user (binmode,noumount) d: on /cygdrive/d type user (binmode,noumount) g: on /cygdrive/g type user (binmode,noumount) h: on /cygdrive/h type user (binmode,noumount) I am a little surprised that FileRunner is working with C:/ as its root directory. I would have preferred to have it use the cygwin / root, and then access windows disks over /cygdrive/c etc. but that's a minor point and it still sort of works: cd / takes you to C:/cygwin. Another funny thing is that cygwin symlinks come up as filename.lnk, but they still seem to work as expected when you click on them. Cheers CV -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
