child (xterm) fork failure as it loads to different address
Hello group, I have a fresh installation of cygwin/ (cygcheck returns following for cygwin1.dll: cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0 ts=2013-07-22 16:06)/cygwin-X (1.14.2-1 built 2013-07-08) and following happens: upon attempt to execute startxwin.exe get following error, while startxwin attempt to execute xterm: xterm 5508 child_info_fork::abort: C:\nobackup\cygwin\bin\cygz.dll: Loaded to different address: parent(0x32) != child(0x3B) xterm: Error 29, errno 11: Resource temporarily unavailable Reason: spawn: fork() failed while it is clear what happens, what is not clear is how to resolve it, so that it does not happen anymore? /wbr Ariel Burbaickij -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: {cygutils/cygutils-extra/cygutils-x11}-1.4.14-1
Charles Wilson cwilson.fastmail.fm> writes: > * cygdrop: Fix bug in obtaining security token information > Patch from Corinna Vinschen, reported by Achim Gratz. Fix confirmed, thank you very much. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 64-bit gdb: invalid decimal " 0x22DBF0"
On Jul 27 11:30, Daniel Brown wrote:
> I have also ran into this problem, in my case though I have managed
> to reduce the issue down to an fgets call when reading a pipe.
> The following code causes the issue for me if I try and debug it:
>
> #include
> #include
>
> int main(int argc, char** argv) {
> char out[100] = {0};
> FILE *pipe;
>
> if ((pipe = popen("uname -r", "rt")) == NULL)
> fprintf(stderr,"Failed to execute popen command");
>
> if(fgets(out, 100, pipe) == NULL)
> fprintf(stderr,"Failed to read popen buffer");
>
> printf("%s\n", out);
>
> pclose(pipe);
>
> return (EXIT_SUCCESS);
> }
>
> I compile with `gcc -g main.c` then `gdb a.exe` and type `run`, the
> error `invalid decimal " 0x23DBF0"` then pops up.
> I have tried the latest snapshot cygwin1.dll (1.7.23s(0.268/5/3))
> and the error is still there.
This is a problem in GDB, not in the Cygwin DLL. My mistake. I fetched
the official 7.6 version of GDB since it already contained Cygwin x86_64
support so I thought it's sufficient. Unfortunately it doesn't handle
special Cygwin strings in terms of Cygwin signal handling correctly.
I'm just uploading a gdb-7.6.50 version build from current CVS which
should fix this.
Thanks for the reports,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mksh-47-1
Version 47-1 of "mksh" has been uploaded. MirBSD Korn Shell (mksh) is an actively developed free implementation of the Korn Shell programming language and a successor to the Public Domain Korn Shell (pdksh). For a detailed list of changes, please see: https://www.mirbsd.org/mksh.htm#r47 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, lookat the "List-Unsubscribe: " tag in the email header of this message.Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read*all* of the information on unsubscribing that is available starting at this URL. -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: child (xterm) fork failure as it loads to different address
Il 7/29/2013 10:10 AM, Ariel Burbaickij ha scritto: Hello group, I have a fresh installation of cygwin/ (cygcheck returns following for cygwin1.dll: cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0 ts=2013-07-22 16:06)/cygwin-X (1.14.2-1 built 2013-07-08) and following happens: upon attempt to execute startxwin.exe get following error, while startxwin attempt to execute xterm: xterm 5508 child_info_fork::abort: C:\nobackup\cygwin\bin\cygz.dll: Loaded to different address: parent(0x32) != child(0x3B) xterm: Error 29, errno 11: Resource temporarily unavailable Reason: spawn: fork() failed while it is clear what happens, what is not clear is how to resolve it, so that it does not happen anymore? http://cygwin.com/faq.html#faq.using.fixing-fork-failures /wbr Ariel Burbaickij -- otherwise, follow the guideline: Problem reports: http://cygwin.com/problems.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: child (xterm) fork failure as it loads to different address
OK, thank, you, so usual suspects. Now, removing, antivirus and stuff will not be possible in this particular environment but adjustments in the configuration are well possible, provided I will be able to prove to administrators that troubles, indeed, stem from antivirus and co. Now, I see in the FAQ in 4.42 section that these troubles were traced and attributed to antiviri programs. Any more details about how they were traced exactly, so that I can re-trace them too and provide a proof, if needed? Now, this is for one thing. Another one, is the possibility to run Windows 7 (in my case) or any Windows OS, down to and including NT in POSIX-compatible "mode". Is this step expected to solve or at least alleviate all or at least some the troubles about the square peg of fork() into the round whole of Windows? On Mon, Jul 29, 2013 at 1:35 PM, marco atzeri wrote: > Il 7/29/2013 10:10 AM, Ariel Burbaickij ha scritto: > >> Hello group, >> I have a fresh installation of cygwin/ (cygcheck returns following for >> cygwin1.dll: cygwin1.dll - os=4.0 img=1.0 sys=4.0 "cygwin1.dll" v0.0 >> ts=2013-07-22 16:06)/cygwin-X (1.14.2-1 built 2013-07-08) and >> following happens: >> upon attempt to execute startxwin.exe get following error, while >> startxwin attempt to execute xterm: >> >> xterm 5508 child_info_fork::abort: C:\nobackup\cygwin\bin\cygz.dll: >> Loaded to different address: parent(0x32) != child(0x3B) >> xterm: Error 29, errno 11: Resource temporarily unavailable >> Reason: spawn: fork() failed >> >> >> while it is clear what happens, what is not clear is how to resolve >> it, so that it does not happen anymore? > > > http://cygwin.com/faq.html#faq.using.fixing-fork-failures > >> >> /wbr >> Ariel Burbaickij >> >> -- > > > otherwise, follow the guideline: >> >> Problem reports: http://cygwin.com/problems.html > > > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cc1: warning: ../../include/w32api: No such file or directory [enabled by default]
Achim Gratz NexGo.DE> writes:
> The above warning appears when -Wmissing-include-dirs is in effect (and
> aborts compilation if -Werror is also given). The missing include path
> seems to be produced by the following compiler spec:
>
> %(cpp_cpu) [...] %{!nostdinc:%{!mno-win32:-idirafter ../include/w32api%s
> -idirafter ../../include/w32api%s}}
>
> which gets expanded into
>
> -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api
> -idirafter ../../include/w32api
If I crate a link /usr/include -> /include then the warning / error is not
produced. Since I don't think /include is supposed to exist on Cygwin, it
seems the compiler spec is wrong?
Regards,
Achim.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cc1: warning: ../../include/w32api: No such file or directory [enabled by default]
On 7/29/2013 20:19, Achim Gratz wrote:
> Achim Gratz NexGo.DE> writes:
>> The above warning appears when -Wmissing-include-dirs is in effect (and
>> aborts compilation if -Werror is also given). The missing include path
>> seems to be produced by the following compiler spec:
>>
>> %(cpp_cpu) [...] %{!nostdinc:%{!mno-win32:-idirafter ../include/w32api%s
>> -idirafter ../../include/w32api%s}}
>>
>> which gets expanded into
>>
>> -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api
>> -idirafter ../../include/w32api
>
> If I crate a link /usr/include -> /include then the warning / error is not
> produced. Since I don't think /include is supposed to exist on Cygwin, it
> seems the compiler spec is wrong?
>
Honestly, I have no idea, ../../include/w32api sounds too high up the tree.
signature.asc
Description: OpenPGP digital signature
Re: cc1: warning: ../../include/w32api: No such file or directory [enabled by default]
On Jul 29 12:19, Achim Gratz wrote:
> Achim Gratz NexGo.DE> writes:
> > The above warning appears when -Wmissing-include-dirs is in effect (and
> > aborts compilation if -Werror is also given). The missing include path
> > seems to be produced by the following compiler spec:
> >
> > %(cpp_cpu) [...] %{!nostdinc:%{!mno-win32:-idirafter ../include/w32api%s
> > -idirafter ../../include/w32api%s}}
> >
> > which gets expanded into
> >
> > -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api
> > -idirafter ../../include/w32api
>
> If I crate a link /usr/include -> /include then the warning / error is not
> produced. Since I don't think /include is supposed to exist on Cygwin, it
> seems the compiler spec is wrong?
It looks like this is a misbehaviour of gcc 4.7.3. There are
practically always non-existant default include dirs, not only on
Cygwin. If you try the same -Wmissing-include-dirs with gcc 4.8.1 on
x86_64 Cygwin, there won't be such a warning.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cc1: warning: ../../include/w32api: No such file or directory [enabled by default]
On Jul 29 20:32, JonY wrote:
> On 7/29/2013 20:19, Achim Gratz wrote:
> > Achim Gratz NexGo.DE> writes:
> >> The above warning appears when -Wmissing-include-dirs is in effect (and
> >> aborts compilation if -Werror is also given). The missing include path
> >> seems to be produced by the following compiler spec:
> >>
> >> %(cpp_cpu) [...] %{!nostdinc:%{!mno-win32:-idirafter ../include/w32api%s
> >> -idirafter ../../include/w32api%s}}
> >>
> >> which gets expanded into
> >>
> >> -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api
> >> -idirafter ../../include/w32api
> >
> > If I crate a link /usr/include -> /include then the warning / error is not
> > produced. Since I don't think /include is supposed to exist on Cygwin, it
> > seems the compiler spec is wrong?
> >
>
> Honestly, I have no idea, ../../include/w32api sounds too high up the tree.
It might be useful when using a cross toolchain.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: child (xterm) fork failure as it loads to different address
On Jul 29 09:35, Ryan Johnson wrote: > http://cygwin.com/acronyms/#TOFU > > On 29/07/2013 8:15 AM, Ariel Burbaickij wrote: > >OK, thank, you, so usual suspects. Now, removing, antivirus and stuff > >will not be possible in this particular environment but adjustments in > >the configuration are well possible, provided I will be able to prove > >to administrators that troubles, indeed, stem from antivirus and co. > >Now, I see in the FAQ in 4.42 section that these troubles were traced > >and attributed to antiviri programs. Any more details about how they > >were traced exactly, so that I can re-trace them too and provide a > >proof, if needed? > The proof usually goes something like this: > > 1. People report fork() failures on the list, and a correlation is > noted between those failures and presence of app/antivirus X. > 2. It is confirmed (or at least considered highly probable) that X > performs dll injection, the root cause of these sorts of fork() > failures. > 3. Somebody tries disabling/removing X and the fork() failures go away. > 4. X gets added to BLODA and reports of fork() failures, not > attributable to X, disappear from the list. > > Eventually the process repeats when Y appears. There's no Y. The successor of X is allegedly called Wayland. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: child (xterm) fork failure as it loads to different address
http://cygwin.com/acronyms/#TOFU On 29/07/2013 8:15 AM, Ariel Burbaickij wrote: OK, thank, you, so usual suspects. Now, removing, antivirus and stuff will not be possible in this particular environment but adjustments in the configuration are well possible, provided I will be able to prove to administrators that troubles, indeed, stem from antivirus and co. Now, I see in the FAQ in 4.42 section that these troubles were traced and attributed to antiviri programs. Any more details about how they were traced exactly, so that I can re-trace them too and provide a proof, if needed? The proof usually goes something like this: 1. People report fork() failures on the list, and a correlation is noted between those failures and presence of app/antivirus X. 2. It is confirmed (or at least considered highly probable) that X performs dll injection, the root cause of these sorts of fork() failures. 3. Somebody tries disabling/removing X and the fork() failures go away. 4. X gets added to BLODA and reports of fork() failures, not attributable to X, disappear from the list. Eventually the process repeats when Y appears. You could also try enabling BLODA detection [1] and see what turns up, or run the NirSoft DLL injection detector [2]. [1] http://cygwin.com/ml/cygwin/2012-02/msg00797.html [2] http://www.nirsoft.net/utils/injected_dll.html Now, this is for one thing. Another one, is the possibility to run Windows 7 (in my case) or any Windows OS, down to and including NT in POSIX-compatible "mode". From www.cygwin.com: The Cygwin DLL currently works with all recent, commercially released x86 32 bit and 64 bit versions of Windows, starting with Windows XP SP3. So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP SP1/SP2. But if your admins are really so worried about viruses, they won't let you run those ancient operating systems anyway, because MS no longer pushes security patches for them. Given that you seem to have your choice of OS, though, you might try 64-bit cygwin. The sheer amount of address space that becomes available, plus some careful design decisions for placement of cygwin-related dlls in that space, reduces the risk of fork failures considerably. I don't think anybody has reported a fork failure on cygwin64 yet (knock on wood). I recently migrated to 64-bit cygwin with a new Win7/64 install myself, and so far have not had to disable Windows Defender; the latter was a recurring source of trouble for my previous 32-bit cygwin install on Win7/64. If you can't get cygwin64 running, you may be able to convince your admins to whitelist cygwin apps with the AV solution; that has a small chance of stopping the dll injection and allowing fork() to succeed. Don't get your hopes up, though: most AV leave the dll injection in place even when completely disabled system-wide, and just tell the dlls not to do anything (other than stepping on cygwin's toes, of course). Is this step expected to solve or at least alleviate all or at least some the troubles about the square peg of fork() into the round whole of Windows? cygwin64 may do that... downgrading your OS will not. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: child (xterm) fork failure as it loads to different address
>So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP >SP1/SP2. But if your admins are really >so worried about viruses, they won't >let you run those ancient operating systems anyway, because MS no longer >>pushes security patches for them. You misread, I am afraid. I am running Windows 7 here. Question is: Is it expected that turning on POSIX-compatibility mode (possibly with downloading of utilities for UNIX subsystem) should help here or not? Yes, let me try cygwin64 after I am done with rebasing, provided it is still necessary, of course :-) On Mon, Jul 29, 2013 at 3:35 PM, Ryan Johnson wrote: > http://cygwin.com/acronyms/#TOFU > > > On 29/07/2013 8:15 AM, Ariel Burbaickij wrote: >> >> OK, thank, you, so usual suspects. Now, removing, antivirus and stuff >> will not be possible in this particular environment but adjustments in >> the configuration are well possible, provided I will be able to prove >> to administrators that troubles, indeed, stem from antivirus and co. >> Now, I see in the FAQ in 4.42 section that these troubles were traced >> and attributed to antiviri programs. Any more details about how they >> were traced exactly, so that I can re-trace them too and provide a >> proof, if needed? > > The proof usually goes something like this: > > 1. People report fork() failures on the list, and a correlation is noted > between those failures and presence of app/antivirus X. > 2. It is confirmed (or at least considered highly probable) that X performs > dll injection, the root cause of these sorts of fork() failures. > 3. Somebody tries disabling/removing X and the fork() failures go away. > 4. X gets added to BLODA and reports of fork() failures, not attributable to > X, disappear from the list. > > Eventually the process repeats when Y appears. > > You could also try enabling BLODA detection [1] and see what turns up, or > run the NirSoft DLL injection detector [2]. > > [1] http://cygwin.com/ml/cygwin/2012-02/msg00797.html > [2] http://www.nirsoft.net/utils/injected_dll.html > > >> Now, this is for one thing. Another one, is the >> possibility to run Windows 7 (in my case) or any Windows OS, down to >> and including NT in POSIX-compatible "mode". > > From www.cygwin.com: >> >> The Cygwin DLL currently works with all recent, commercially released x86 >> 32 bit and 64 bit versions of Windows, starting with Windows XP SP3. > > So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP > SP1/SP2. But if your admins are really so worried about viruses, they won't > let you run those ancient operating systems anyway, because MS no longer > pushes security patches for them. > > Given that you seem to have your choice of OS, though, you might try 64-bit > cygwin. The sheer amount of address space that becomes available, plus some > careful design decisions for placement of cygwin-related dlls in that space, > reduces the risk of fork failures considerably. > > I don't think anybody has reported a fork failure on cygwin64 yet (knock on > wood). I recently migrated to 64-bit cygwin with a new Win7/64 install > myself, and so far have not had to disable Windows Defender; the latter was > a recurring source of trouble for my previous 32-bit cygwin install on > Win7/64. > > If you can't get cygwin64 running, you may be able to convince your admins > to whitelist cygwin apps with the AV solution; that has a small chance of > stopping the dll injection and allowing fork() to succeed. Don't get your > hopes up, though: most AV leave the dll injection in place even when > completely disabled system-wide, and just tell the dlls not to do anything > (other than stepping on cygwin's toes, of course). > > >> Is this step expected to >> solve or at least alleviate all or at least some the troubles about >> the square peg of fork() into the round whole of Windows? > > cygwin64 may do that... downgrading your OS will not. > > Ryan > > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: child (xterm) fork failure as it loads to different address
OK, for the record: looks like rebasing did help quite a bit here. /wbr Ariel Burbaickij On Mon, Jul 29, 2013 at 3:35 PM, Ryan Johnson wrote: > http://cygwin.com/acronyms/#TOFU > > > On 29/07/2013 8:15 AM, Ariel Burbaickij wrote: >> >> OK, thank, you, so usual suspects. Now, removing, antivirus and stuff >> will not be possible in this particular environment but adjustments in >> the configuration are well possible, provided I will be able to prove >> to administrators that troubles, indeed, stem from antivirus and co. >> Now, I see in the FAQ in 4.42 section that these troubles were traced >> and attributed to antiviri programs. Any more details about how they >> were traced exactly, so that I can re-trace them too and provide a >> proof, if needed? > > The proof usually goes something like this: > > 1. People report fork() failures on the list, and a correlation is noted > between those failures and presence of app/antivirus X. > 2. It is confirmed (or at least considered highly probable) that X performs > dll injection, the root cause of these sorts of fork() failures. > 3. Somebody tries disabling/removing X and the fork() failures go away. > 4. X gets added to BLODA and reports of fork() failures, not attributable to > X, disappear from the list. > > Eventually the process repeats when Y appears. > > You could also try enabling BLODA detection [1] and see what turns up, or > run the NirSoft DLL injection detector [2]. > > [1] http://cygwin.com/ml/cygwin/2012-02/msg00797.html > [2] http://www.nirsoft.net/utils/injected_dll.html > > >> Now, this is for one thing. Another one, is the >> possibility to run Windows 7 (in my case) or any Windows OS, down to >> and including NT in POSIX-compatible "mode". > > From www.cygwin.com: >> >> The Cygwin DLL currently works with all recent, commercially released x86 >> 32 bit and 64 bit versions of Windows, starting with Windows XP SP3. > > So no, Windows NT will not work. Neither will Win95/98/2000. Nor will XP > SP1/SP2. But if your admins are really so worried about viruses, they won't > let you run those ancient operating systems anyway, because MS no longer > pushes security patches for them. > > Given that you seem to have your choice of OS, though, you might try 64-bit > cygwin. The sheer amount of address space that becomes available, plus some > careful design decisions for placement of cygwin-related dlls in that space, > reduces the risk of fork failures considerably. > > I don't think anybody has reported a fork failure on cygwin64 yet (knock on > wood). I recently migrated to 64-bit cygwin with a new Win7/64 install > myself, and so far have not had to disable Windows Defender; the latter was > a recurring source of trouble for my previous 32-bit cygwin install on > Win7/64. > > If you can't get cygwin64 running, you may be able to convince your admins > to whitelist cygwin apps with the AV solution; that has a small chance of > stopping the dll injection and allowing fork() to succeed. Don't get your > hopes up, though: most AV leave the dll injection in place even when > completely disabled system-wide, and just tell the dlls not to do anything > (other than stepping on cygwin's toes, of course). > > >> Is this step expected to >> solve or at least alleviate all or at least some the troubles about >> the square peg of fork() into the round whole of Windows? > > cygwin64 may do that... downgrading your OS will not. > > Ryan > > > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
problem with 'patch' version 2.7.1-1 in Apache OpenOffice build under Windows
Hi, I am Oliver-Rainer Wittmann, a software developer working on Apache OpenOffice. I am not subscribed to this mailing cygwin at cygwin dot com. Thus, please include my mail address in your replies - Thx in advance. I just want to inform you that version 2.7.1-1 of 'patch' breaks the current Apache OpenOffice build under Windows. It is caused by the fact that a non-CRLF patch could not be applied to a CRLF file. I have seen that this has been already reported on this list - see thread [Bug with Cygwin's 'quilt' is actually in 'patch'] As Apache OpenOffice is built on different platforms (Windows, MacOS, Linux, ...) and developers are working on different platforms it can happen that patches and files got different line endings. Thus, Apache OpenOffice is hit by the change in new cygwin 'patch'. Question: Is it still possible to change the line ending of a certain line in a file from CRLF to non-CRLF with 'patch' version 2.7.1-1? Best regards, Oliver. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem with 'patch' version 2.7.1-1 in Apache OpenOffice build under Windows
On Jul 29 16:17, Oliver-Rainer Wittmann wrote: > Hi, > > I am Oliver-Rainer Wittmann, a software developer working on Apache > OpenOffice. > I am not subscribed to this mailing cygwin at cygwin dot com. Thus, > please include my mail address in your replies - Thx in advance. > > I just want to inform you that version 2.7.1-1 of 'patch' breaks the > current Apache OpenOffice build under Windows. > It is caused by the fact that a non-CRLF patch could not be applied > to a CRLF file. dos2unix? > I have seen that this has been already reported on this list - see > thread [Bug with Cygwin's 'quilt' is actually in 'patch'] > > As Apache OpenOffice is built on different platforms (Windows, > MacOS, Linux, ...) and developers are working on different platforms > it can happen that patches and files got different line endings. > Thus, Apache OpenOffice is hit by the change in new cygwin 'patch'. > > Question: > Is it still possible to change the line ending of a certain line in > a file from CRLF to non-CRLF with 'patch' version 2.7.1-1? This is upstream choice. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
setup.exe annoying behavior
I'm running setup.exe to update my Cygwin installation. I'm also running a number of Cygwin commands at the same time. Every time setup.exe tries to update a DLL that's in use, I get a pop-up message like: Unable to extract /usr/bin/cygFOO-1.dll -- the file is in use. Please stop all Cygwin processes and select "Retry", or select "Continue" to go on anyway (you will need to reboot). with buttons [Retry] and [Continue]. What I'd like to do is select [Continue] automatically for all remaining DLLs, so the update will finish without any further interaction. Instead, I have to manually click the [Continue] button for each conflicting DLL. I'm sure this isn't recommended, and I know I'll have to reboot when the update is done, but if I can do it manually I should be able to do it automatically. Can a third button be added that automatically continues the entire update, or perhaps an option on one of the preceding screens? -- Keith Thompson -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem with 'patch' version 2.7.1-1 in Apache OpenOffice build under Windows
I forgot the CC in my first reply, sorry. I extended my reply a bit. On Jul 29 16:17, Oliver-Rainer Wittmann wrote: > Hi, > > I am Oliver-Rainer Wittmann, a software developer working on Apache > OpenOffice. > I am not subscribed to this mailing cygwin at cygwin dot com. Thus, > please include my mail address in your replies - Thx in advance. > > I just want to inform you that version 2.7.1-1 of 'patch' breaks the > current Apache OpenOffice build under Windows. > It is caused by the fact that a non-CRLF patch could not be applied > to a CRLF file. dos2unix? > I have seen that this has been already reported on this list - see > thread [Bug with Cygwin's 'quilt' is actually in 'patch'] > > As Apache OpenOffice is built on different platforms (Windows, > MacOS, Linux, ...) and developers are working on different platforms > it can happen that patches and files got different line endings. > Thus, Apache OpenOffice is hit by the change in new cygwin 'patch'. > > Question: > Is it still possible to change the line ending of a certain line in > a file from CRLF to non-CRLF with 'patch' version 2.7.1-1? This is an upstream choice. What you can do: - Use dos2unix. - Use a temporary text mount http://cygwin.com/cygwin-ug-net/using-utils.html#mount - Discuss with the patch maintainers why they refuse to patch a UNIX file with a DOS patch and vice versa. I guess it's a problem with mixing the line endings. If you have a file with UNINX line endings and a patch containing DOS lines, what is the end result supposed to be? Are the CRs to be kept intact or not? Since patch doesn't know what the input is about, there's no way to be sure what behaviour is right or wrong. Something like that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cannot build debug/-Zi using VS 2010 SP1 via ssh with public key auth from local administrator account
On Jul 26, 2013, at 4:29 PM, Larry Hall (Cygwin) wrote: >> >> Here is the source of the problem, and I'm virtually certain that these >> problems occurred >> as a result of running setup.exe on the two machines as part of the upgrade >> (note that I did not, for various reasons, run setup.exe on the two machines >> that still work). >> Here are the USER* variables on machines (a) and (b), the two problem >> machines, >> when logging in via ssh/pub key: > > How did you install? Did you pick "Just For Me" or "All Users". The > latter is required for pubkey authentication. You can also check if > password authentication resolves the problem. > I installed for all users. I already mentioned that password authentication worked in a previous post. The fix I found is to use passwd -R, since cyglsa-config is not working. I'm going to open a new thread regarding cyglsa-config. Thanks! smime.p7s Description: S/MIME cryptographic signature
cyglsa-config not working properly in cygwin 1.7.22
Hello all - In the process of trying to diagnose problems building debug with MSVC 2010 SP1 over ssh/pubkey, I discovered that cyglsa-config does not work on a fresh install of cygwin on: - XP SP3 32-bit - Vista 64-bit I have two other XP SP3 machines that continue to correctly build debug over ssh/pubkey, after upgrading from MSVC 2008 to MSVC 2010 SP1, without making any changes to cygwin. These two machines are running cygwin 1.7.5. The simple method I discovered to work around this problem is to use "passwd -R", but I've never had to do this in the past. In all cases, working or failing, the accounts are local with administrator privileges. The effect of "passwd -R" is easily verifiable: AFTER APPLICATION OF cyglsa-config: $ set | grep USER (output trimmed) USER=gessh USERDOMAIN='NT AUTHORITY' USERNAME=SYSTEM AFTER APPLICATION of passwd -R (which is the same as running from an interactive cygwin terminal or from ssh using password authentication): $ set | grep USER (output trimmed) USER=gessh USERDOMAIN=NIVEN USERNAME=gessh Both of the failing machines, prior to reinstalling cygwin, had been used daily for building debug with MSVC 2008 over ssh/pubkey for several years, and cyglsa-config was used (and required) on both initially to accomplish this, without the use of "passwd -R". Any ideas? Thanks - J. P. Abelanet smime.p7s Description: S/MIME cryptographic signature
gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal " 0x22DBF0"]
On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed
to reduce the issue down to an fgets call when reading a pipe.
The following code causes the issue for me if I try and debug it:
#include
#include
int main(int argc, char** argv) {
char out[100] = {0};
FILE *pipe;
if ((pipe = popen("uname -r", "rt")) == NULL)
fprintf(stderr,"Failed to execute popen command");
if(fgets(out, 100, pipe) == NULL)
fprintf(stderr,"Failed to read popen buffer");
printf("%s\n", out);
pclose(pipe);
return (EXIT_SUCCESS);
}
I compile with `gcc -g main.c` then `gdb a.exe` and type `run`, the
error `invalid decimal " 0x23DBF0"` then pops up.
I have tried the latest snapshot cygwin1.dll (1.7.23s(0.268/5/3))
and the error is still there.
This is a problem in GDB, not in the Cygwin DLL. My mistake. I fetched
the official 7.6 version of GDB since it already contained Cygwin x86_64
support so I thought it's sufficient. Unfortunately it doesn't handle
special Cygwin strings in terms of Cygwin signal handling correctly.
I'm just uploading a gdb-7.6.50 version build from current CVS which
should fix this.
Confirmed that this problem is fixed [1]... however, my original STC
still hangs because gdb somehow interferes with the choreography of
SIGTSTP between victim and its owning shell.
With default signal handling (SIGTSTP stop print pass) gdb breaks in
when the victim receives ^Z, but both gdb and the victim hang once gdb
continues; gdb cannot be interrupted with ^C [2]. Killing gdb allows the
victim to finish backgrounding itself, apparently none the worse for wear.
With handle SIGTSTP nostop noprint pass, gdb doesn't break in any more,
but both gdb and the victim still hang on ^Z. This time, killing gdb
also silently kills the app, with the shell reporting exit code 0 and no
job completion notice (presumably because the victim didn't finish
backgrounding itself before being killed).
Running under linux/gdb, the STC behaves as expected, breaking in after
the shell reports that the victim has backgrounded. You'd want to nostop
SIGTSTP, SIGTTIN and SIGCONT to keep the debugger from getting
underfoot, though.
(changing the subject line to reflect the new issue, since it's probably
not directly related to the original problem)
[1] BTW, did you intend for a gdb release announcement to go out? None
came that I can see, though the mirrors seem to have picked it up.
[2] As usual, gdb only breaks in response to ^C if you invoke it
directly from cmd.exe, but the above hang causes it to ignore ^C even then.
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Windows 8 Terminal Shortcut Start
On 7/28/2013 10:45 AM, Robert Pendell wrote: On Sat, Jul 27, 2013 at 11:59 AM, Sander Torfs <> wrote: Do this. Right click the icon, choose open file location, delete the file from there. I assume that's what you wanted and not just to unpin it from the start screen. Really though. This isn't a Cygwin issue. It's more a Windows 8 issue and there are plenty of forums for that. I think the original poster may want to remove all of cygwin, not just the start menu icon, and was surprised that there appears to be no uninstall script. However, if I am wrong, that does sound like good advice as to how to remove the start menu icon. Regards -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cc1: warning: ../../include/w32api: No such file or directory [enabled by default]
Corinna Vinschen writes: > It looks like this is a misbehaviour of gcc 4.7.3. There are > practically always non-existant default include dirs, not only on > Cygwin. If you try the same -Wmissing-include-dirs with gcc 4.8.1 on > x86_64 Cygwin, there won't be such a warning. I have no idea if that should be considered a bug or not, but the combination "-Werror -Wmissing-include-dirs" is rendered useless due to this. Since it most assuredly doesn't point to a system path it uses the current working directory instead in the final stage — so after expansion the driver inserts a literal "-I ../../include/w32api", which might silently pull in the wrong includes if the user happens to have some directory like that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem with 'patch' version 2.7.1-1 in Apache OpenOffice build under Windows
Greetings, Oliver-Rainer Wittmann! > I am Oliver-Rainer Wittmann, a software developer working on Apache > OpenOffice. > I am not subscribed to this mailing cygwin at cygwin dot com. Thus, > please include my mail address in your replies - Thx in advance. When you're posting to a mailing list, you're expected to read the reply from a list. Please, don't make a problem for other people out of your personal preferences. Yes, I can set up my mailer to send a copy of my reply to a list, but other people may not have such luxury, and will be forced to do manual work to manage message destination, if their mail client allow such fiddling at all. > I just want to inform you that version 2.7.1-1 of 'patch' breaks the > current Apache OpenOffice build under Windows. > It is caused by the fact that a non-CRLF patch could not be applied to a > CRLF file. It was a deliberate change to prevent potential damage that could be caused by such patching. If you sure want to patch such a file, you can always run d2u on both files to convert them to consistent line endings. And your source files SHOULD be all with the same line endings, unless there's a special requirements for it. (I.e. windows batch files do not work well with LF endings, but then, a patch file WILL have same endings. Else it just won't work at all.) > I have seen that this has been already reported on this list - see > thread [Bug with Cygwin's 'quilt' is actually in 'patch'] > As Apache OpenOffice is built on different platforms (Windows, MacOS, > Linux, ...) and developers are working on different platforms it can > happen that patches and files got different line endings. Thus, Apache > OpenOffice is hit by the change in new cygwin 'patch'. Patch file may have any line endings. As long as they are consistent, this is not an issue. But this should not be a case for source files, which all SHOULD have consistent line endings. > Question: > Is it still possible to change the line ending of a certain line in a > file from CRLF to non-CRLF with 'patch' version 2.7.1-1? d2u filename will strip CR's from a file. Even erratic ones. -- WBR, Andrey Repin (anrdae...@freemail.ru) 29.07.2013, <18:59> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cyglsa-config not working properly in cygwin 1.7.22
On Jul 29 10:50, J. P. Abelanet wrote: > Hello all - > > In the process of trying to diagnose problems building debug with MSVC 2010 > SP1 over ssh/pubkey, > I discovered that cyglsa-config does not work on a fresh install of cygwin on: > - XP SP3 32-bit > - Vista 64-bit > I have two other XP SP3 machines that continue to correctly build debug over > ssh/pubkey, > after upgrading from MSVC 2008 to MSVC 2010 SP1, > without making any changes to cygwin. These two machines are running cygwin > 1.7.5. > > The simple method I discovered to work around this problem is to use "passwd > -R", > but I've never had to do this in the past. In all cases, working or failing, > the accounts are local > with administrator privileges. The effect of "passwd -R" is easily > verifiable: > > AFTER APPLICATION OF cyglsa-config: > > $ set | grep USER (output trimmed) > USER=gessh > USERDOMAIN='NT AUTHORITY' > USERNAME=SYSTEM > > AFTER APPLICATION of passwd -R (which is the same as running from an > interactive > cygwin terminal or from ssh using password authentication): > > $ set | grep USER (output trimmed) > USER=gessh > USERDOMAIN=NIVEN > USERNAME=gessh > > Both of the failing machines, prior to reinstalling cygwin, had been used > daily for building debug with MSVC 2008 over ssh/pubkey > for several years, and cyglsa-config was used (and required) on both > initially to accomplish > this, without the use of "passwd -R". > > Any ideas? No. I can confirm that this happens, and it seems the cyglsa.dll doesn't get loaded at all. But as for the reason, I have no idea. It's the same source code we're using for ages. We switched the compiler to build it, but that's it. So, for some reason, when building the stuff with mingw-w64-gcc, the result is not runnable. Sorry, but I'm at a loss right now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cyglsa-config not working properly in cygwin 1.7.22
On Jul 29, 2013, at 11:58 AM, Corinna Vinschen wrote: > > No. I can confirm that this happens, and it seems the cyglsa.dll > doesn't get loaded at all. But as for the reason, I have no idea. > It's the same source code we're using for ages. We switched the > compiler to build it, but that's it. So, for some reason, when > building the stuff with mingw-w64-gcc, the result is not runnable. > > Sorry, but I'm at a loss right now. > Thanks for the quick reply. If in the future you have any ideas, I'll be happy to test them out. Thanks for a great product overall - J. P. smime.p7s Description: S/MIME cryptographic signature
Re: cyglsa-config not working properly in cygwin 1.7.22
On Jul 29 13:21, J. P. Abelanet wrote: > On Jul 29, 2013, at 11:58 AM, Corinna Vinschen wrote: > > > > > No. I can confirm that this happens, and it seems the cyglsa.dll > > doesn't get loaded at all. But as for the reason, I have no idea. > > It's the same source code we're using for ages. We switched the > > compiler to build it, but that's it. So, for some reason, when > > building the stuff with mingw-w64-gcc, the result is not runnable. > > > > Sorry, but I'm at a loss right now. > > > Thanks for the quick reply. If in the future you have any ideas, > I'll be happy to test them out. I think I found the problem. The older compiler didn't reorder functions for optimization purposes, but the new one does. The entry point for the cyglsa DLL was not explicitely mentioned, but it was based on the fact that it is the first function in the source code. However, the new compiler reorders function by default with -O2 optimization. So the entry point was not at the start of the executable anymore and the LSA failed to load the cyglsa DLL. I changed the Makefile to specify the entry point of the DLL explicitely to make sure the right function is called at load time. This seems to work again in my testing on 32 and 64 bit, but more testing never hurts. So I'd like to ask you to check the today's developer snapshot from http://cygwin.com/snapshots/ and copy the cyglsa DLL from the snapshot into /bin/cyglsa. Given that the DLL there isn't loaded, you should be able to overwrite it, like this: On a 32 bit OS: cp /bin/cyglsa.dll /bin/cyglsa/ On a 64 bit OS: cp /bin/cyglsa64.dll /bin/cyglsa/ Kep in mind that the x86 snapshots contains both DLLs, while the x86_64 snapshot only contains the 64 bit DLL. > Thanks for a great product overall - Thanks to you for the report! The today's 32 and 64 bit snapshots should be uploaded in an hour at the latest. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal " 0x22DBF0"]
On Jul 29 12:01, Ryan Johnson wrote:
> On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
> >On Jul 27 11:30, Daniel Brown wrote:
> >>I have also ran into this problem, in my case though I have managed
> >>to reduce the issue down to an fgets call when reading a pipe.
> >>The following code causes the issue for me if I try and debug it:
> >>
> >>#include
> >>#include
> >>
> >>int main(int argc, char** argv) {
> >> char out[100] = {0};
> >> FILE *pipe;
> >>
> >> if ((pipe = popen("uname -r", "rt")) == NULL)
> >> fprintf(stderr,"Failed to execute popen command");
> >>
> >> if(fgets(out, 100, pipe) == NULL)
> >> fprintf(stderr,"Failed to read popen buffer");
> >>
> >> printf("%s\n", out);
> >>
> >> pclose(pipe);
> >>
> >> return (EXIT_SUCCESS);
> >>}
> >>
> >>I compile with `gcc -g main.c` then `gdb a.exe` and type `run`, the
> >>error `invalid decimal " 0x23DBF0"` then pops up.
> >>I have tried the latest snapshot cygwin1.dll (1.7.23s(0.268/5/3))
> >>and the error is still there.
> >This is a problem in GDB, not in the Cygwin DLL. My mistake. I fetched
> >the official 7.6 version of GDB since it already contained Cygwin x86_64
> >support so I thought it's sufficient. Unfortunately it doesn't handle
> >special Cygwin strings in terms of Cygwin signal handling correctly.
> >
> >I'm just uploading a gdb-7.6.50 version build from current CVS which
> >should fix this.
> Confirmed that this problem is fixed [1]... however, my original STC
> still hangs because gdb somehow interferes with the choreography of
> SIGTSTP between victim and its owning shell.
>
> With default signal handling (SIGTSTP stop print pass) gdb breaks in
> when the victim receives ^Z, but both gdb and the victim hang once
> gdb continues; gdb cannot be interrupted with ^C [2]. Killing gdb
> allows the victim to finish backgrounding itself, apparently none
> the worse for wear.
I'm not sure if ^Z can reliably work in the GDB scenario. That's
Chris' domain, but AFAICS, the fact that GDB calls the inferior
process with CreateProcess, the job control facility of the shell
will be broken.
> [1] BTW, did you intend for a gdb release announcement to go out?
> None came that I can see, though the mirrors seem to have picked it
> up.
No. Next time I will.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal " 0x22DBF0"]
On 29/07/2013 3:11 PM, Corinna Vinschen wrote:
On Jul 29 12:01, Ryan Johnson wrote:
On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed
to reduce the issue down to an fgets call when reading a pipe.
The following code causes the issue for me if I try and debug it:
#include
#include
int main(int argc, char** argv) {
char out[100] = {0};
FILE *pipe;
if ((pipe = popen("uname -r", "rt")) == NULL)
fprintf(stderr,"Failed to execute popen command");
if(fgets(out, 100, pipe) == NULL)
fprintf(stderr,"Failed to read popen buffer");
printf("%s\n", out);
pclose(pipe);
return (EXIT_SUCCESS);
}
I compile with `gcc -g main.c` then `gdb a.exe` and type `run`, the
error `invalid decimal " 0x23DBF0"` then pops up.
I have tried the latest snapshot cygwin1.dll (1.7.23s(0.268/5/3))
and the error is still there.
This is a problem in GDB, not in the Cygwin DLL. My mistake. I fetched
the official 7.6 version of GDB since it already contained Cygwin x86_64
support so I thought it's sufficient. Unfortunately it doesn't handle
special Cygwin strings in terms of Cygwin signal handling correctly.
I'm just uploading a gdb-7.6.50 version build from current CVS which
should fix this.
Confirmed that this problem is fixed [1]... however, my original STC
still hangs because gdb somehow interferes with the choreography of
SIGTSTP between victim and its owning shell.
With default signal handling (SIGTSTP stop print pass) gdb breaks in
when the victim receives ^Z, but both gdb and the victim hang once
gdb continues; gdb cannot be interrupted with ^C [2]. Killing gdb
allows the victim to finish backgrounding itself, apparently none
the worse for wear.
I'm not sure if ^Z can reliably work in the GDB scenario. That's
Chris' domain, but AFAICS, the fact that GDB calls the inferior
process with CreateProcess, the job control facility of the shell
will be broken.
I'm talking about the case where gdb attaches to a running proccess... I
don't know how you could ever handle ^Z in a process gdb started.
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cyglsa-config not working properly in cygwin 1.7.22
On Jul 29 21:08, Corinna Vinschen wrote: > On Jul 29 13:21, J. P. Abelanet wrote: > > On Jul 29, 2013, at 11:58 AM, Corinna Vinschen wrote: > > > > > > > > No. I can confirm that this happens, and it seems the cyglsa.dll > > > doesn't get loaded at all. But as for the reason, I have no idea. > > > It's the same source code we're using for ages. We switched the > > > compiler to build it, but that's it. So, for some reason, when > > > building the stuff with mingw-w64-gcc, the result is not runnable. > > > > > > Sorry, but I'm at a loss right now. > > > > > Thanks for the quick reply. If in the future you have any ideas, > > I'll be happy to test them out. > > I think I found the problem. The older compiler didn't reorder > functions for optimization purposes, but the new one does. The entry > point for the cyglsa DLL was not explicitely mentioned, but it was based > on the fact that it is the first function in the source code. > > However, the new compiler reorders function by default with -O2 > optimization. So the entry point was not at the start of the executable > anymore and the LSA failed to load the cyglsa DLL. I changed the > Makefile to specify the entry point of the DLL explicitely to make sure > the right function is called at load time. > > This seems to work again in my testing on 32 and 64 bit, but more > testing never hurts. So I'd like to ask you to check the today's > developer snapshot from http://cygwin.com/snapshots/ and copy the cyglsa > DLL from the snapshot into /bin/cyglsa. Given that the DLL there isn't > loaded, you should be able to overwrite it, like this: > > On a 32 bit OS: > > cp /bin/cyglsa.dll /bin/cyglsa/ > > On a 64 bit OS: > > cp /bin/cyglsa64.dll /bin/cyglsa/ > > Kep in mind that the x86 snapshots contains both DLLs, while the x86_64 > snapshot only contains the 64 bit DLL. > > > Thanks for a great product overall - > > Thanks to you for the report! The today's 32 and 64 bit snapshots > should be uploaded in an hour at the latest. Snapshots are up. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb hangs on ^Z [was: Re: 64-bit gdb: invalid decimal " 0x22DBF0"]
On 29/07/2013 3:13 PM, Ryan Johnson wrote:
On 29/07/2013 3:11 PM, Corinna Vinschen wrote:
On Jul 29 12:01, Ryan Johnson wrote:
On 29/07/2013 7:06 AM, Corinna Vinschen wrote:
On Jul 27 11:30, Daniel Brown wrote:
I have also ran into this problem, in my case though I have managed
to reduce the issue down to an fgets call when reading a pipe.
The following code causes the issue for me if I try and debug it:
#include
#include
int main(int argc, char** argv) {
char out[100] = {0};
FILE *pipe;
if ((pipe = popen("uname -r", "rt")) == NULL)
fprintf(stderr,"Failed to execute popen command");
if(fgets(out, 100, pipe) == NULL)
fprintf(stderr,"Failed to read popen buffer");
printf("%s\n", out);
pclose(pipe);
return (EXIT_SUCCESS);
}
I compile with `gcc -g main.c` then `gdb a.exe` and type `run`, the
error `invalid decimal " 0x23DBF0"` then pops up.
I have tried the latest snapshot cygwin1.dll (1.7.23s(0.268/5/3))
and the error is still there.
This is a problem in GDB, not in the Cygwin DLL. My mistake. I
fetched
the official 7.6 version of GDB since it already contained Cygwin
x86_64
support so I thought it's sufficient. Unfortunately it doesn't handle
special Cygwin strings in terms of Cygwin signal handling correctly.
I'm just uploading a gdb-7.6.50 version build from current CVS which
should fix this.
Confirmed that this problem is fixed [1]... however, my original STC
still hangs because gdb somehow interferes with the choreography of
SIGTSTP between victim and its owning shell.
With default signal handling (SIGTSTP stop print pass) gdb breaks in
when the victim receives ^Z, but both gdb and the victim hang once
gdb continues; gdb cannot be interrupted with ^C [2]. Killing gdb
allows the victim to finish backgrounding itself, apparently none
the worse for wear.
I'm not sure if ^Z can reliably work in the GDB scenario. That's
Chris' domain, but AFAICS, the fact that GDB calls the inferior
process with CreateProcess, the job control facility of the shell
will be broken.
I'm talking about the case where gdb attaches to a running proccess...
I don't know how you could ever handle ^Z in a process gdb started.
Just to be extra clear, the scenario is:
1. start STC in terminal A
2. start gdb in terminal B and attach it to the STC
3. type ^Z in terminal A
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cyglsa-config not working properly in cygwin 1.7.22
On Jul 29, 2013, at 2:26 PM, Corinna Vinschen wrote: >> >> I think I found the problem. The older compiler didn't reorder >> functions for optimization purposes, but the new one does. The entry >> point for the cyglsa DLL was not explicitely mentioned, but it was based >> on the fact that it is the first function in the source code. >> >> However, the new compiler reorders function by default with -O2 >> optimization. So the entry point was not at the start of the executable >> anymore and the LSA failed to load the cyglsa DLL. I changed the >> Makefile to specify the entry point of the DLL explicitely to make sure >> the right function is called at load time. >> >> This seems to work again in my testing on 32 and 64 bit, but more >> testing never hurts. So I'd like to ask you to check the today's >> developer snapshot from http://cygwin.com/snapshots/ and copy the cyglsa >> DLL from the snapshot into /bin/cyglsa. Given that the DLL there isn't >> loaded, you should be able to overwrite it, like this: >> >> On a 32 bit OS: >> >> cp /bin/cyglsa.dll /bin/cyglsa/ >> >> On a 64 bit OS: >> >> cp /bin/cyglsa64.dll /bin/cyglsa/ >> >> Kep in mind that the x86 snapshots contains both DLLs, while the x86_64 >> snapshot only contains the 64 bit DLL. >> >>> Thanks for a great product overall - >> >> Thanks to you for the report! The today's 32 and 64 bit snapshots >> should be uploaded in an hour at the latest. > > Snapshots are up. > Thanks again for responding so quickly. My quick test did not work, but perhaps I misunderstood. I did the following: - Set "passwd -R" to blank value - Download, but not install, http://cygwin.com/snapshots/x86/cygwin-inst-20130729.tar.bz2 - Extract /bin/cyglsa*.dll from the snapshot, overwriting the existing files - cp /bin/cyglsa.dll /bin/cyglsa/, since this is a 32-bit OS - Do not reboot, or run cyglsa-config, or anything else ssh niven (using pub key) $ set | grep USER USER=gessh USERDOMAIN='NT AUTHORITY' USERNAME=SYSTEM Did I miss a step, or should I try something more aggressive? Thanks! J. P. smime.p7s Description: S/MIME cryptographic signature
Re: cyglsa-config not working properly in cygwin 1.7.22
On Jul 29 14:53, J. P. Abelanet wrote: > > On Jul 29, 2013, at 2:26 PM, Corinna Vinschen wrote: > > >> > >> I think I found the problem. The older compiler didn't reorder > >> functions for optimization purposes, but the new one does. The entry > >> point for the cyglsa DLL was not explicitely mentioned, but it was based > >> on the fact that it is the first function in the source code. > >> > >> However, the new compiler reorders function by default with -O2 > >> optimization. So the entry point was not at the start of the executable > >> anymore and the LSA failed to load the cyglsa DLL. I changed the > >> Makefile to specify the entry point of the DLL explicitely to make sure > >> the right function is called at load time. > >> > >> This seems to work again in my testing on 32 and 64 bit, but more > >> testing never hurts. So I'd like to ask you to check the today's > >> developer snapshot from http://cygwin.com/snapshots/ and copy the cyglsa > >> DLL from the snapshot into /bin/cyglsa. Given that the DLL there isn't > >> loaded, you should be able to overwrite it, like this: > >> > >> On a 32 bit OS: > >> > >> cp /bin/cyglsa.dll /bin/cyglsa/ > >> > >> On a 64 bit OS: > >> > >> cp /bin/cyglsa64.dll /bin/cyglsa/ > >> > >> Kep in mind that the x86 snapshots contains both DLLs, while the x86_64 > >> snapshot only contains the 64 bit DLL. > >> > >>> Thanks for a great product overall - > >> > >> Thanks to you for the report! The today's 32 and 64 bit snapshots > >> should be uploaded in an hour at the latest. > > > > Snapshots are up. > > > Thanks again for responding so quickly. My quick test did not work, but > perhaps I misunderstood. > I did the following: > - Set "passwd -R" to blank value > - Download, but not install, > http://cygwin.com/snapshots/x86/cygwin-inst-20130729.tar.bz2 > - Extract /bin/cyglsa*.dll from the snapshot, overwriting the existing files > - cp /bin/cyglsa.dll /bin/cyglsa/, since this is a 32-bit OS > - Do not reboot, or run cyglsa-config, or anything else You *must* reboot. LSA only picks up the authentication package DLLs at boot time. Sorry for missing that in my instruction. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cyglsa-config not working properly in cygwin 1.7.22
On Jul 29, 2013, at 3:22 PM, Corinna Vinschen wrote: > On Jul 29 14:53, J. P. Abelanet wrote: >> >> On Jul 29, 2013, at 2:26 PM, Corinna Vinschen wrote: >> >>>> >>>> I think I found the problem. The older compiler didn't reorder >>>> functions for optimization purposes, but the new one does. The entry >>>> point for the cyglsa DLL was not explicitely mentioned, but it was based >>>> on the fact that it is the first function in the source code. >>>> >>>> However, the new compiler reorders function by default with -O2 >>>> optimization. So the entry point was not at the start of the executable >>>> anymore and the LSA failed to load the cyglsa DLL. I changed the >>>> Makefile to specify the entry point of the DLL explicitely to make sure >>>> the right function is called at load time. >>>> >>>> This seems to work again in my testing on 32 and 64 bit, but more >>>> testing never hurts. So I'd like to ask you to check the today's >>>> developer snapshot from http://cygwin.com/snapshots/ and copy the cyglsa >>>> DLL from the snapshot into /bin/cyglsa. Given that the DLL there isn't >>>> loaded, you should be able to overwrite it, like this: >>>> >>>> On a 32 bit OS: >>>> >>>> cp /bin/cyglsa.dll /bin/cyglsa/ >>>> >>>> On a 64 bit OS: >>>> >>>> cp /bin/cyglsa64.dll /bin/cyglsa/ >>>> >>>> Kep in mind that the x86 snapshots contains both DLLs, while the x86_64 >>>> snapshot only contains the 64 bit DLL. >>>> >>>>> Thanks for a great product overall - >>>> >>>> Thanks to you for the report! The today's 32 and 64 bit snapshots >>>> should be uploaded in an hour at the latest. >>> >>> Snapshots are up. >>> >> Thanks again for responding so quickly. My quick test did not work, but >> perhaps I misunderstood. >> I did the following: >> - Set "passwd -R" to blank value >> - Download, but not install, >> http://cygwin.com/snapshots/x86/cygwin-inst-20130729.tar.bz2 >> - Extract /bin/cyglsa*.dll from the snapshot, overwriting the existing files >> - cp /bin/cyglsa.dll /bin/cyglsa/, since this is a 32-bit OS >> - Do not reboot, or run cyglsa-config, or anything else > > You *must* reboot. LSA only picks up the authentication package DLLs > at boot time. Sorry for missing that in my instruction. That fixed it!!! Thanks again for the quick response. I'll upgrade to 1.7.23 when it becomes available. J. P. Abelanet smime.p7s Description: S/MIME cryptographic signature
Re: [ANNOUNCEMENT] Updated: mingw64-*-{gcc,headers,runtime,pthreads}, New package: mingw64-*-winpthreads
Hi, After removing 4.8-cmodel-medium.patch and 4.8-duplicate-symbols.patch for 32bit cygwin, 2nd stage libgcc fails with spawn error, "C compiler cannot create executables". Running the compile command manually does show it running cc1, but hangs indefinitely, adding -v causes it to emit xgcc: error: unrecognized command line option ‘-v’. Piping the C files over stdin and adding -xc makes it run, but it never does produce any output file. It does print some Execution times statistics. I'm not sure what's going on. signature.asc Description: OpenPGP digital signature
