Re: screen reattach not working?
I have tried with an user that is in administrators group and it still doesn't work. and the cat socket error really is no such device or address and the same is reported in rxvt so I guess we can't conclude from that that permissions are a problem. What other info can I provide? Should I strace screen and send the output? Has anyone got screen reattach working under Vista? On 2007-10-04, Damjan Lango wrote: I tried sshing in over putty and also from a linux gnome-term on a different machine. Btw, I'm using Vista, is this a problem perhaps? Also the user I'm ssh-ing into does not have administrator privleges, might try changing that. I tried to do a cat /tmp/uscreens/S-name/socket-name and it says permission denied CYGWIN is set to ntsec tty /etc/passwd is created using mkpasswd -l and ssh confugred using ssh-host-config -y or what was that command again what else could be interesting? I think that screen does bad at error reporting either it doesn't say anything or it blurps some strange messages like, you die in a dungeon or something. btw, after checking processes with ps I can see that screen and bash are running, i just can't attach to that screen session. -- 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: screen reattach not working?
Andrew Schulman wrote: Andrew Schulman wrote: Hi! What is the current status of screen reattach? For me it does not work under the default cygwin bash shell, which uses cmd console afaik and it does not work under cygwin sshd. The only way it works is under cygwin rxvt. I would most like to use it under sshd. What's the magic to make it work? :) Hi Damjan. There's information about this in /usr/share/doc/screen/README.Cygwin. Read that, but the short version is that all features of screen are supposed to work correctly in a DOS console with CYGWIN=tty (set before you open the console), and in rxvt, PuTTYcyg, and xterm. I'm not sure about an ssh session. If it will work from a DOS console with CYGWIN=tty, it should work fine from ssh. I have read the screen/README.Cygwin and couldn't find a solution. I have set the CYGWIN=tty ntsec but it does not work anywhere except rxvt. -- 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: screen reattach not working?
Correction: besides rxvt, screen also works in xterm. However I can't get screen working in the default cygwin CMD console running bash and also can't get it working over ssh. On 2007-10-05, Damjan Lango wrote: I have read the screen/README.Cygwin and couldn't find a solution. I have set the CYGWIN=tty ntsec but it does not work anywhere except rxvt. -- 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: screen reattach not working?
Another update on my screen adventures, please accept my apologies since i'm posting so frequently. I have removed completely the /tmp/uscreens/S-Damjan directory and it's contents and killed all the cygwin processes. Now screen reattaching works in CMD cygwin bash window as well (and rxvt and xterm) But still no luck with ssh. If I run screen under ssh, then detach it and then try to re-attach under ssh nothing happens, screen -r just exits with no message. If I try to attach to that screen from a local CMD bash window I get the following message: Suddenly the Dungeon collapses!! - You die... btw ps -e under ssh and under local cmd window do not show the same processes even though id reports the same user. It seems to me that there might be some problem with privileges under ssh or something? what else can I try? :) On 2007-10-05, Damjan Lango wrote: Correction: besides rxvt, screen also works in xterm. However I can't get screen working in the default cygwin CMD console running bash and also can't get it working over ssh. On 2007-10-05, Damjan Lango wrote: I have read the screen/README.Cygwin and couldn't find a solution. I have set the CYGWIN=tty ntsec but it does not work anywhere except rxvt. -- 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/
rxvt default font awful
rxvt default font setting is awful, at least on vista. Here is a screenshot: http://damjan.lango.googlepages.com/rxvt-font.jpg comparing the default font with some other font settings (terminal, lucida console, 7x14) rxvt --help which should report used resources says: $ rxvt --help 21 | grep font: font: fontname app-defaults/Rxvt has: Rxvt*font: -bitstream-bitstream vera sans mono-medium-r-normal--*-160-*-*-m-*-iso8859-1 I guess the bad looking font is because I do not have this font installed on the system, does it come with cygwin? I haven't found a package for that. I suggest changing the default font setting for cygwin rxvt. -- 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: Unknown user after logging into sshd under Vista
Daniel Noll wrote: On Friday 05 October 2007 13:07:41 Larry Hall (Cygwin) wrote: OK, we now know the symptoms and the problem. But we don't have any basic configuration information to do some simple triage with. In short: Problem reports: http://cygwin.com/problems.html Please read and follow the above guidelines, paying particular attention to the part about *attaching* cygcheck output. In the absence of the above, my WAG is that the user you are logging in as (domain user perhaps?) is not in your '/etc/passwd' file. See 'man passwd' and the Cygwin Users Guide http://cygwin.com/cygwin-ug-net/ for more details. Ditto for '/etc/group'. Okay. Firstly we have this little error that comes straight after running it: [501] [EMAIL PROTECTED]:~ cygcheck -s -v -r cygcheck.out 'id' program not found 'id' program not found This suggests your installation isn't complete. It's hard to say how incomplete without the full cygcheck output but why don't you just try re-running 'setup.exe' and walking through all the pages and see if you can find 'id' after that. I'm wondering if some postinstall scripts didn't run. If that doesn't work, look in '/etc/postinstall' for any scripts there that don't have a '.done' suffix. Make a note of these and try running them yourself. See if that helps. If not, report what you did and saw. It does then run, but it recurses forever on one of Windows' (many :-/) recursive registry nodes. I've attached the portion of the file before this takes place, in the hope that the stuff which comes after won't be needed. Yikes! Never seen or heard of this before. This doesn't strike me as a 'Good Thing'(tm). I don't know if it's coming into play here or not but it doesn't give me a warm, fuzzy feeling. /etc/passwd looks like this: snip /etc/group has: Yeah these look OK. It looks like you're working on your on machine outside of any Windows domain. That's useful info (though not clearly pointing to a solution). -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: screen reattach not working?
As I see you're requesting cygcheck -s -v -r output for other problems, I'm attaching it here as well if it helps with my ssh / screen reattach problem. btw, when cygcheck completed, it also reported: 'id' program not found 'id' program not found but id is working fine: $ id uid=1000(Damjan) gid=513(None) groups=513(None),544(Administrators),545(Users) $ type id id is hashed (/usr/bin/id) On 2007-10-05, Damjan Lango wrote: Another update on my screen adventures, please accept my apologies since i'm posting so frequently. I have removed completely the /tmp/uscreens/S-Damjan directory and it's contents and killed all the cygwin processes. Now screen reattaching works in CMD cygwin bash window as well (and rxvt and xterm) But still no luck with ssh. If I run screen under ssh, then detach it and then try to re-attach under ssh nothing happens, screen -r just exits with no message. If I try to attach to that screen from a local CMD bash window I get the following message: Suddenly the Dungeon collapses!! - You die... btw ps -e under ssh and under local cmd window do not show the same processes even though id reports the same user. It seems to me that there might be some problem with privileges under ssh or something? what else can I try? :)| cygcheck.out Description: Binary data -- 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: Does Cygwin run on Windows 2003 64 bit?
[EMAIL PROTECTED] wrote: Can you please tell me if Cygwin is expected to run on Windows 2003 64 bit Enterprise Edition? Yes (but Cygwin won't magically be 64-bit). I use Cygwin on a 2k3 r2 x64 box to create a unix-like build environment (that matches the other platforms we support). Note that currently there is no 64-bit version of GCC available for Windows, AFAIK. This message is [snip] Such disclaimers are against list policy, see http://sourceware.org/lists.html (@ CGF: time to add a new expression to the trap?) -- Matthew Non sequitor. Your facts are out of order. -- Nomad -- 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: Does Cygwin run on Windows 2003 64 bit?
On Fri, Oct 05, 2007 at 10:43:08AM -0500, Matthew Woehlke wrote: [EMAIL PROTECTED] wrote: Can you please tell me if Cygwin is expected to run on Windows 2003 64 bit Enterprise Edition? Yes (but Cygwin won't magically be 64-bit). I use Cygwin on a 2k3 r2 x64 box to create a unix-like build environment (that matches the other platforms we support). Note that currently there is no 64-bit version of GCC available for Windows, AFAIK. This message is [snip] Such disclaimers are against list policy, see http://sourceware.org/lists.html (@ CGF: time to add a new expression to the trap?) Yep. Thanks for the catch. It's now in. Second time in a week. cgf -- 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: Debugging with cygwin tools
I'm having the exact same problem on win64 with gdb. The PATH variable has been set manually to avoid possible syntax errors, but the same problem exists when I don't shorten the PATH. Cygcheck doesn't list any dlls as missing. gdb works on my win32 computer. Any other ideas? Doug $ uname -a CYGWIN_NT-5.2-WOW64 c4 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin [EMAIL PROTECTED] /cygdrive/k/factor $ export PATH=/cygdrive/k/windows/system32:/usr/bin [EMAIL PROTECTED] /cygdrive/k/factor $ cygcheck.exe gdb.exe Found: K:\cygwin\bin\gdb.exe K:/cygwin/bin/gdb.exe K:\cygwin\bin\cygwin1.dll K:\WINDOWS\system32\ADVAPI32.DLL K:\WINDOWS\system32\ntdll.dll K:\WINDOWS\system32\KERNEL32.dll K:\WINDOWS\system32\RPCRT4.dll K:\WINDOWS\system32\Secur32.dll K:\cygwin\bin\cygiconv-2.dll K:\cygwin\bin\cygintl-3.dll K:\cygwin\bin\cygncurses-8.dll K:\WINDOWS\system32\COMDLG32.DLL K:\WINDOWS\system32\msvcrt.dll K:\WINDOWS\system32\SHLWAPI.dll K:\WINDOWS\system32\GDI32.dll K:\WINDOWS\system32\USER32.dll K:\WINDOWS\system32\COMCTL32.dll K:\WINDOWS\system32\SHELL32.dll K:\cygwin\bin\tcl84.dll K:\cygwin\bin\tk84.dll K:\WINDOWS\system32\IMM32.DLL [EMAIL PROTECTED] /cygdrive/k/factor $ cygcheck.exe ./factor-nt.exe .\factor-nt.exe K:\WINDOWS\system32\msvcrt.dll K:\WINDOWS\system32\KERNEL32.dll K:\WINDOWS\system32\ntdll.dll K:\WINDOWS\system32\SHELL32.DLL K:\WINDOWS\system32\GDI32.dll K:\WINDOWS\system32\USER32.dll K:\WINDOWS\system32\ADVAPI32.dll K:\WINDOWS\system32\RPCRT4.dll K:\WINDOWS\system32\Secur32.dll K:\WINDOWS\system32\SHLWAPI.dll .\factor-nt.dll [EMAIL PROTECTED] /cygdrive/k/factor $ gdb ./factor-nt GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin... (gdb) run Starting program: /cygdrive/k/factor/factor-nt.exe Error: dll starting at 0x77d41000 not found. Segmentation fault (core dumped) [EMAIL PROTECTED] /cygdrive/k/factor $ -- View this message in context: http://www.nabble.com/Debugging-with-cygwin-tools-tf4568124.html#a13064545 Sent from the Cygwin Users mailing list archive at Nabble.com. -- 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: Debugging with cygwin tools
Doug Coleman wrote: I'm having the exact same problem on win64 with gdb. The PATH variable has been set manually to avoid possible syntax errors, but the same problem exists when I don't shorten the PATH. Cygcheck doesn't list any dlls as missing. gdb works on my win32 computer. Any other ideas? [snip] Error: dll starting at 0x77d41000 not found. Segmentation fault (core dumped) Same exact location. Can you run 'info files' before 'run'? What dll is in that address? -- René Berber -- 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: Cygwin speed
I had come across with the following problem: after upgrading Cygwin from
version 1.5.19-4 to 1.5.24-2 my application (relational database)
began to function several times slower. The reason was a slowdown of
a function, which performs rebalancing of table index tree; this function
calls write() function very many times, at each call 4 bytes are updated
in index file (row number in tree node). To test performance of write()
function I created the following test program:
#include fcntl.h
#include unistd.h
int main(int argc, char **argv)
{
char chunk[64]=;
int i, fd;
if ((fd=open(tst_chunks.bin,
O_CREAT|O_WRONLY|O_TRUNC,
0666))0) return 1;
for (i=0; i100; i++)
if (write(fd,chunk,sizeof(chunk))!=sizeof(chunk)) return 1;
close(fd);
return 0;
}
When launched on Celeron 1.3MHz via time -p, it works:
on 1.5.24-2 : 48 seconds;
on 1.5.19-4 : 18 seconds.
After investigating differences between 1.5.24-2 and 1.5.19-4 I have found
out, that the problem is in function sig_dispatch_pending(), which is
called in the beginning of writev() function, which is called from write().
In function sig_dispatch_pending() the following has been changed:
void __stdcall
sig_dispatch_pending (bool fast)
{
if (exit_state || _my_tls == _sig_tls || !sigq.start.next) //
version 1.5.19-4
// if (exit_state || _my_tls == _sig_tls) //
version 1.5.24-2
{
//...
return;
}
//...
sig_send (myself, fast ? __SIGFLUSHFAST : __SIGFLUSH);
}
When make this modification in sources for 1.5.24-2 and rebuild cygwin1.dll,
my test program begins to work as fast as on 1.5.19-4. In message
http://cygwin.com/ml/cygwin-developers/2006-07/msg00034.html
Brian Ford pointed to the following description of a change between
1.5.19-4 and 1.5.24-2:
2006-02-24 Christopher Faylor cgf at timesys dot com
* sigproc.cc (sigheld): Define new variable.
- (sig_dispatch_pending): Don't check sigq since that's racy.
(sig_send): Set sigheld flag if __SIGHOLD is specified, reset it if
__SIGNOHOLD is specified. Ignore flush signals if we're holding
signals.
I think, that maybe checking of sigq is a little bit racy, but it turns,
that getting rid of such a cheap check results in a great slowdown of
sig_dispatch_pending() function for most calls, when there are no pending
signals.
Maybe introducing a critical section or some other synchronization
mechanism would be a solution.
Oleg Volkov
--
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: Debugging with cygwin tools
René Berber-2 wrote: Doug Coleman wrote: I'm having the exact same problem on win64 with gdb. The PATH variable has been set manually to avoid possible syntax errors, but the same problem exists when I don't shorten the PATH. Cygcheck doesn't list any dlls as missing. gdb works on my win32 computer. Any other ideas? [snip] Error: dll starting at 0x77d41000 not found. Segmentation fault (core dumped) Same exact location. Can you run 'info files' before 'run'? What dll is in that address? -- René Berber Here is 'info files' in gdb. There have been other posts about the same problem, but no resolution afaik: http://cygwin.com/ml/cygwin/2007-03/msg00182.html $ gdb ./factor-nt GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin... (gdb) info files Symbols from /cygdrive/k/factor/factor-nt.exe. Local exec file: `/cygdrive/k/factor/factor-nt.exe', file type pei-i386. Entry point: 0x401280 0x00401000 - 0x004017b8 is .text 0x00402000 - 0x00402030 is .data 0x00403000 - 0x00403040 is .rdata 0x00404000 - 0x00404380 is .bss 0x00405000 - 0x0040509b is .edata 0x00406000 - 0x0040631c is .idata 0x00407000 - 0x0041dd04 is .rsrc 0x0041e000 - 0x0041e094 is .reloc (gdb) run Starting program: /cygdrive/k/factor/factor-nt.exe Error: dll starting at 0x77d41000 not found. Segmentation fault (core dumped) [EMAIL PROTECTED] /cygdrive/k/factor $ -- View this message in context: http://www.nabble.com/Debugging-with-cygwin-tools-tf4568124.html#a13065449 Sent from the Cygwin Users mailing list archive at Nabble.com. -- 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: Debugging with cygwin tools
René Berber-2 wrote: Doug Coleman wrote: I'm having the exact same problem on win64 with gdb. The PATH variable has been set manually to avoid possible syntax errors, but the same problem exists when I don't shorten the PATH. Cygcheck doesn't list any dlls as missing. gdb works on my win32 computer. Any other ideas? [snip] Error: dll starting at 0x77d41000 not found. Segmentation fault (core dumped) Same exact location. Can you run 'info files' before 'run'? What dll is in that address? -- René Berber So I attached to the running process and that works! Here is an info files from that. I also tried adding /cygdrive/k/WINDOWS/syswow64 to PATH -- it still errors at 0x77d41000. Doug $ gdb ./factor-nt 4496 GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin... Attaching to program `/cygdrive/k/factor/factor-nt.exe', process 4496 Loaded symbols for /cygdrive/k/WINDOWS/system32/ntdll.dll Loaded symbols for /cygdrive/k/WINDOWS/syswow64/kernel32.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /cygdrive/k/WINDOWS/syswow64/advapi32.dll Loaded symbols for /cygdrive/k/WINDOWS/syswow64/rpcrt4.dll Loaded symbols for /cygdrive/k/WINDOWS/syswow64/secur32.dll Loaded symbols for /usr/bin/cygintl-8.dll Loaded symbols for /usr/bin/cygiconv-2.dll Loaded symbols for /usr/bin/cygreadline6.dll Loaded symbols for /usr/bin/cygncurses-8.dll Loaded symbols for /cygdrive/k/WINDOWS/syswow64/user32.dll Loaded symbols for /cygdrive/k/WINDOWS/syswow64/gdi32.dll Loaded symbols for /cygdrive/k/WINDOWS/system32/imm32.dll [Switching to thread 4496.0xccc] (gdb) info files Symbols from /cygdrive/k/factor/factor-nt.exe. Win32 child process: Using the running image of attached thread 4496.0xccc. While running this, GDB does not access memory from... Local exec file: `/cygdrive/k/factor/factor-nt.exe', file type pei-i386. Entry point: 0x401280 0x00401000 - 0x004017b8 is .text 0x00402000 - 0x00402030 is .data 0x00403000 - 0x00403040 is .rdata 0x00404000 - 0x00404380 is .bss 0x00405000 - 0x0040509b is .edata 0x00406000 - 0x0040631c is .idata 0x00407000 - 0x0041dd04 is .rsrc 0x0041e000 - 0x0041e094 is .reloc 0x7d61 - 0x7d695e57 is .text in /cygdrive/k/WINDOWS/system32/ntdll.dll 0x7d6a - 0x7d6a3600 is .data in /cygdrive/k/WINDOWS/system32/ntdll.dll 0x7d6b - 0x7d6de250 is .rsrc in /cygdrive/k/WINDOWS/system32/ntdll.dll 0x7d6e - 0x7d6e32ac is .reloc in /cygdrive/k/WINDOWS/system32/ntdll.dll 0x7d4d - 0x7d55305e is .text in /cygdrive/k/WINDOWS/syswow64/kernel32.dll 0x7d56 - 0x7d562600 is .data in /cygdrive/k/WINDOWS/syswow64/kernel32.dll 0x7d57 - 0x7d5da6c8 is .rsrc in /cygdrive/k/WINDOWS/syswow64/kernel32.dll 0x7d5e - 0x7d5e6294 is .reloc in /cygdrive/k/WINDOWS/syswow64/kernel32.dll 0x61001000 - 0x610fcaf4 is .text in /usr/bin/cygwin1.dll 0x610fd000 - 0x610ff710 is .autoload_text in /usr/bin/cygwin1.dll 0x6110 - 0x6110af70 is .data in /usr/bin/cygwin1.dll 0x6110b000 - 0x6113e520 is .rdata in /usr/bin/cygwin1.dll 0x6113f000 - 0x611483d0 is .bss in /usr/bin/cygwin1.dll 0x61149000 - 0x61150c9b is .edata in /usr/bin/cygwin1.dll 0x61151000 - 0x61151448 is .rsrc in /usr/bin/cygwin1.dll 0x61152000 - 0x6116210c is .reloc in /usr/bin/cygwin1.dll 0x61163000 - 0x61163104 is .cygwin_dll_common in /usr/bin/cygwin1.dll 0x61165000 - 0x6117 is .idata in /usr/bin/cygwin1.dll 0x6117 - 0x6120 is .cygheap in /usr/bin/cygwin1.dll 0x77f51000 - 0x77fbff79 is .text in /cygdrive/k/WINDOWS/syswow64/advapi32.dll 0x77fc - 0x77fc2600 is .data in /cygdrive/k/WINDOWS/syswow64/advapi32.dll 0x77fc4000 - 0x77fe50c8 is .rsrc in /cygdrive/k/WINDOWS/syswow64/advapi32.dll 0x77fe6000 - 0x77fea2e8 is .reloc in /cygdrive/k/WINDOWS/syswow64/advapi32.dll 0x7da3 - 0x7dabce60 is .text in /cygdrive/k/WINDOWS/syswow64/rpcrt4.dll 0x7dac - 0x7dac69a6 is .orpc in /cygdrive/k/WINDOWS/syswow64/rpcrt4.dll 0x7dad - 0x7dad0800 is .data in /cygdrive/k/WINDOWS/syswow64/rpcrt4.dll 0x7dae - 0x7dae0408 is .rsrc in /cygdrive/k/WINDOWS/syswow64/rpcrt4.dll 0x7daf - 0x7daf4d8c is .reloc in /cygdrive/k/WINDOWS/syswow64/rpcrt4.dll 0x7d8e - 0x7d8ee699 is .text in /cygdrive/k/WINDOWS/syswow64/secur32.dll 0x7d8f - 0x7d8f0600 is .data in /cygdrive/k/WINDOWS/syswow64/secur32.dll 0x7d90 - 0x7d900418
Re: Debugging with cygwin tools
Doug Coleman wrote: Here is 'info files' in gdb. There have been other posts about the same problem, but no resolution afaik: http://cygwin.com/ml/cygwin/2007-03/msg00182.html Yes, same problem. $ gdb ./factor-nt GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-cygwin... (gdb) info files Symbols from /cygdrive/k/factor/factor-nt.exe. Local exec file: `/cygdrive/k/factor/factor-nt.exe', file type pei-i386. Entry point: 0x401280 0x00401000 - 0x004017b8 is .text 0x00402000 - 0x00402030 is .data 0x00403000 - 0x00403040 is .rdata 0x00404000 - 0x00404380 is .bss 0x00405000 - 0x0040509b is .edata 0x00406000 - 0x0040631c is .idata 0x00407000 - 0x0041dd04 is .rsrc 0x0041e000 - 0x0041e094 is .reloc (gdb) run Definitely something is very wrong, it doesn't show any of the dll. My only guess, by the 0x77d41000 address, is that one of the Windows dll can't be loaded... don't know how to fix it. Same probem has been reported in MingW: https://sourceforge.net/tracker/?func=detailatid=102435aid=1500271group_id=2435 the most recent message (2 months ago) even mentions a patch, but its not there. -- René Berber -- 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: Debugging with cygwin tools
Doug Coleman wrote: So I attached to the running process and that works! Nice one, nothing maps to the infamous address (in fact everyting is way above that -- with one more digit in the address), seems like the gdb bug report at MingW might be in the right track. Here is an info files from that. I also tried adding /cygdrive/k/WINDOWS/syswow64 to PATH -- it still errors at 0x77d41000. $ gdb ./factor-nt 4496 GNU gdb 6.5.50.20060706-cvs (cygwin-special) ... -- René Berber -- 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: Problems compiling grep and friends
Dave, I'm not sure what to do. I see you attached a diffs file. Is there a utility such as patch that I can use to apply those diffs? What would be the command? Thanks, Siegfried On 04 October 2007 22:13, Siegfried Heintze wrote: Siegfried wrote: OK, I tried that. See below for the results. Looks like we have the same problem. I whipped this up against grep-2.5.1a-3. It might just apply cleanly to the version you're working with; make sure it gets all the $(DESTDIR)/ instances and changes them to $DDSLASH. It WFM: -- 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: Bad EXE format (error 193)
On 05 October 2007 03:28, Lynn Winebarger wrote: [ Cc'ing the mailing list back in. ] On 10/4/07, Lynn Winebarger wrote: On 10/4/07, Dave Korn wrote: Yes, why not; feel free to send them both to me, off list. Can't promise I'll spot anything, but I'll take a look. (My first WAG would be that the sassy assembler does something different from other w32 assemblers and that's where the trouble is coming from). Many thanks, Dave, I will send them tonight. And they are attached. Thanks! Lynn Well, this was a weird one. I think the underlying problem must be a bug in larceny's final link stage during the build. First, this command made your binary executable for me: objcopy -R .comment larceny.bin larceny2.exe To work this out, I looked at the headers to the binary you sent, using both GNU (objdump -x) and MS (dumpbin /all). Here's the output from editbin; objdump shows all the same information in a slightly different form. Microsoft (R) COFF/PE Dumper Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file larceny.bin PE signature found File Type: EXECUTABLE IMAGE FILE HEADER VALUES 14C machine (x86) 8 number of sections 47059D7D time date stamp Fri Oct 05 03:12:13 2007 2E000 file pointer to symbol table 6EA number of symbols E0 size of optional header 107 characteristics Relocations stripped Executable Line numbers stripped 32 bit word machine OPTIONAL HEADER VALUES 10B magic # (PE32) 2.56 linker version 23200 size of code 9800 size of initialized data 3000 size of uninitialized data 1000 entry point (00401000) 1000 base of code 25000 base of data 40 image base (0040 to 00435FFF) 1000 section alignment 200 file alignment 4.00 operating system version 1.00 image version 4.00 subsystem version 0 Win32 version 36000 size of image 2B8 size of headers 44EB4 checksum 3 subsystem (Windows CUI) 0 DLL characteristics 20 size of stack reserve 1000 size of stack commit 10 size of heap reserve 1000 size of heap commit 0 loader flags 10 number of directories 0 [ 0] RVA [size] of Export Directory 32000 [ 860] RVA [size] of Import Directory 0 [ 0] RVA [size] of Resource Directory 0 [ 0] RVA [size] of Exception Directory 0 [ 0] RVA [size] of Certificates Directory 0 [ 0] RVA [size] of Base Relocation Directory 0 [ 0] RVA [size] of Debug Directory 0 [ 0] RVA [size] of Architecture Directory 0 [ 0] RVA [size] of Global Pointer Directory 0 [ 0] RVA [size] of Thread Storage Directory 0 [ 0] RVA [size] of Load Configuration Directory 0 [ 0] RVA [size] of Bound Import Directory 0 [ 0] RVA [size] of Import Address Table Directory 0 [ 0] RVA [size] of Delay Import Directory 0 [ 0] RVA [size] of COM Descriptor Directory 0 [ 0] RVA [size] of Reserved Directory Looking at the headers, and comparing them to the output from a 'hello world' C executable, one thing stood out: 2B8 size of headers That's been 400 in every other program I've looked at. It also meant something to me, because I had tried experimentally attempting to relink the larceny binary with the MS linker (link) just in case it could smooth out something that was malformed, and it had mentioned 2B8 in the error message: C:\link larceny.bin /OUT:lar2.exe Microsoft (R) Incremental Linker Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. larceny.bin : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2B8 C:\ So, what's at offset 0x2B8 in the larceny binary? It turns out to be: SECTION HEADER #1 .comment name 1F virtual size FFC0 virtual address (1 to 1001E) 208 size of raw data 2B8 file pointer to raw data (02B8 to 04BF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 0 flags RAW DATA #1 1: 00 54 68 65 20 4E 65 74 77 69 64 65 20 41 73 73 .The Netwide Ass 10010: 65 6D 62 6C 65 72 20 30 2E 39 38 2E 33 39 00embler 0.98.39. ... some kind of comment/id section left behind by nasm. Ok, fair enough, but why would that make the file invalid? Well,
RE: Problems compiling grep and friends
On 05 October 2007 23:16, Siegfried Heintze wrote: Dave, I'm not sure what to do. I see you attached a diffs file. Is there a utility such as patch that I can use to apply those diffs? What would be the command? There's a utility *exactly* such as patch that you can use to apply those diffs, it's patch! Place the diffs file in the grep top-level source directory, cd into that directory in a shell and run patch --dry-run -p0 diffs.txt which will do a quick trial run. You may see some output about matched at ... offset or fuzz, but that's ok, as long as there are no rejections. If it looks ok, apply the patch for real by running patch -p0 diffs.txt Then reconfigure and re-build, and you should be ok. cheers, DaveK -- Can't think of a witty .sigline today -- 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: Bad EXE format (error 193)
I forgot to cc the list, but the origin of the issue might be of interest to someone. On 10/5/07, Dave Korn [EMAIL PROTECTED] wrote: Well, this was a weird one. I think the underlying problem must be a bug in larceny's final link stage during the build. First, this command made your binary executable for me: objcopy -R .comment larceny.bin larceny2.exe [Detailed analysis omitted] So, the file is regarded as malformed by the loader because it contains a section that isn't correctly aligned to the file alignment. I don't know how it got that way, but it's clearly inconsistent. It might be that the section was supposed to have EXCLUDE or some other flag that would have made the loader not care, I don't know, but since it's just a comment section, discarding it with objdump -R does the job nicely. Thanks, Dave! With that information, I have tracked down the problem. The original Makefile uses nasm -o foo.o foo.asm -f elf -g. I had subsequently changed this to -f gnuwin32 (no -g), but the make clean did not actually erase that particular object file. The comment only appears in files made with -f elf and -g (at least, it doesn't appear with -f gnuwin32 -g, or -f win32 -g). The section has alignment 2**0, compared to 2**2 of every other section. I'm surprised ld (or collect2, I don't know how different they are) did not at least complain about this if it wasn't willing to pad the section. Thanks, Lynn -- 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: Does Cygwin run on Windows 2003 64 bit?
Matthew Woehlke wrote: [EMAIL PROTECTED] wrote: Can you please tell me if Cygwin is expected to run on Windows 2003 64 bit Enterprise Edition? Yes (but Cygwin won't magically be 64-bit). I use Cygwin on a 2k3 r2 x64 box to create a unix-like build environment (that matches the other platforms we support). Note that currently there is no 64-bit version of GCC available for Windows, AFAIK. Off topic and incorrect, as the mingw one offered by FX Coudert worked for me. I'd continue dreaming of a 64-bit Cygwin, if I thought that might come true. I'm making another effort to build and test gcc for cygwin (32-bit) under cygwin on Windows XP64. You'll be able to judge the success by whether it shows up on gcc-testsuite. libdecnumber configure went bad on me several times, but I doubt cygwin is strictly to blame. -- 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/
