Re: Changing Home Directory
On 25/7/2011 05:00, ScKaSx wrote: Hi All, I just installed Cygwin and found that my home directory is defined by Windows HOME environment variable. My question is how I can change my cygwin home directory without changing the Windows HOME variable, in other words to use /etc/mkpasswd? Cheers! I had this problem regularly when working with Active Directory domains. I wanted everything kept in c:\cygwin\home for portability. To do this, I just modified the file "/etc/passwd" to provide a new cygwin path. Regards, Jason. -- 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: I want to use DLL compiled with Cygwin with VC(VS2008).
On 14/02/2011 05:03, Y.Hosoi wrote:
Thank you.
However, it did not move well.
If test.dll is done in LoadLibrary, Access Violation is generated.
Are you still amused something?
[main source code]
#include "stdafx.h"
#include "windows.h"
#ifdef __cplusplus
extern "C"{
#endif
typedef int (*TFUNC)(void);
typedef void (*Tinit)(void);
int _tmain(int argc, _TCHAR* argv[])
{
int i;
HINSTANCE h;
HINSTANCE hInstDLL;
Tinit init;
TFUNC DllFunction;
DWORD ErrNo;
h = LoadLibrary( TEXT( "cygwin1.dll" ) );
init = (Tinit)GetProcAddress( h, "cygwin_dll_init" );
init();
hInstDLL = LoadLibrary( TEXT( "test.dll" ) ); /* !Access
Violation! */
if( hInstDLL == NULL )
{
ErrNo = GetLastError();
return 0;
}
DllFunction = (TFUNC)GetProcAddress( hInstDLL, "hello" );
i = DllFunction();
FreeLibrary( hInstDLL );
FreeLibrary( h );
return 0;
}
#ifdef __cplusplus
}
#endif
Try the following code. This was pulled from the Cygwin sources. There
is a test case that does exactly this, loads cygwin1.dll dynamically.
You need to make sure you allocate stack. This was compiled with MINGW.
This is part of a larger program, so it might need some adjustments. The
function cygloadCRTStartup() is pretty much from the sources.
Note that the entry point needs to be set with the linker option:
-Wl,-entry -Wl,_cygloadCRTStartup@0
#include
#include
#include "getopt.h"
#define CYGHELP_SUCCESS EXIT_SUCCESS
#define CYGHELP_ARG_ERROR 1
#define CYGHELP_DLL_NOT_FOUND 100
#define CYGHELP_DLL_NOT_SUPPORTED 101
#define CYGHELP_INTERNAL_ERROR255
typedef void(__cdecl cdi_t)(void);
typedef void(__cdecl cctfwp_t)(const char *path, char *win32path);
typedef void(__cdecl cctfpp_t)(const char *path, char *posixpath);
int mainCRTStartup ();
int __stdcall cygloadCRTStartup ()
{
char padding[32768];
size_t delta;
intresult;
char block[32768];
char *stackbase;
char *_stackbase;
char *_end;
_end = padding + sizeof(padding);
#ifdef __GNUC__
__asm__ (
"movl %%fs:4, %0"
:"=r"(stackbase)
);
#else
__asm {
mov eax, fs:[4];
mov stackbase, eax;
}
#endif
_stackbase = stackbase;
// We've gotten as close as we can to the top of the stack. Even
// subverting the entry point, though, still doesn't get us there-- I'm
// getting 64 bytes in use before the entry point. So we back up the
data
// there and restore it when the destructor is called:
if ((_stackbase - _end) != 0) {
delta = (_stackbase - _end);
memcpy (block, _end, delta);
}
result = mainCRTStartup ();
memcpy(_end, block, delta);
return result;
}
int main(int argc, char **argv)
{
HMODULE cygwinDll;
DWORD winres;
cdi_t *cygwin_dll_init;
cctfwp_t *cygwin_conv_to_full_win32_path;
cctfpp_t *cygwin_conv_to_full_posix_path;
const char *dll = "cygwin1.dll";
const char *ppath = NULL;
const char *wpath = NULL;
charmodule[MAX_PATH];
charbuff[MAX_PATH];
int i;
int c;
// Get any options the user provides
opterr = 0;
while ((c = getopt(argc, argv, "c:p:w:")) != -1) {
switch (c) {
case 'c':
dll = optarg;
break;
case 'p':
ppath = optarg;
break;
case 'w':
wpath = optarg;
break;
case '?':
if (optopt == 'c') {
fprintf(stderr, "Option -%c requires the full name for the Cygwin
DLL\n", optopt);
} else if (optopt == 'p') {
fprintf(stderr, "Option -%c requires the Posix path to convert\n",
optopt);
} else if (optopt == 'w') {
fprintf(stderr, "Option -%c requires the Windows path to convert\n",
optopt);
} else {
fprintf(stderr, "Unknown option -%c\n", optopt);
}
return CYGHELP_ARG_ERROR;
default:
fprintf(stderr, "Argument %c given, unknown handler\n",
c);
return CYGHELP_INTERNAL_ERROR;
}
}
// Load the library and determine the full path to the library (as
// determined by windows)
cygwinDll = LoadLibrary(dll);
if (!cygwinDll) {
fprintf(stderr, "Couldn't f
Re: Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
On 02/12/2010 18:59, Corinna Vinschen wrote: On Dec 2 14:23, Jason Curl wrote: One of my use cases is to test a particular interface if it has an IP address or not (due to DHCP, AutoIP, etc.). Then on definition of an address, I can trigger a process. This assumes that the interface names remains constant. So a dynamically changing interface name is something I'd like to NOT see. Huh? My proposal does exactly that. It would always return unique interface names. Maybe I don't understand your proposal. You want to assign an index name based on the IPv4 address. The "UUID:Index" is the complete interface name. It's unique for that IPv4 address, but as soon as its IP changes, so does the interface name. Then I think ioctl(SIOCGIFCONF) would also need to follow this behaviour. ioctl(SIOCGIFxxx) would also need to accept the interface names given. Then there will be maximum compatibility in my source with how other OSes work. getifaddrs() returns a name, this same name can be used with ioctl(). (note 1) I have an embedded device that I connect to my PC via Ethernet. When I physically connect it, I want to start a process. That process should be started, when a specified interface receives an IPv4 address, is IFF_UP and has a IFF_LINK. So I need to poll this interface. With Linux, QNX, FBSD, Solaris, I don't even need to use getifaddrs() or ioctl(SIOCGIFCONF), I can poll it directly with ioctl(SIOCGIFADDR) as normally the interfaces don't have an alias. With Cygwin 1.7.7 I can obtain a complete list once, use SIOCGIFFRNDLYNAM to find the interface name and then poll (only with SIOCGIFCONF, not with getifaddrs(), my original problem). Cygwin 1.5.x was problematic, except if I had precisely only one interface, but generally the names were static, so in practice it worked. Now with the proposal, I need to obtain a complete list of all interfaces every time I poll, perform a check against SIOCGIFFRNDLYNAM, because the name of the interfaces themselves change. (note 1) I would not like to make assumptions about the format of the Cygwin interface name to get the ioctl() value from getifaddrs(). This places an unnecessary burden on Cygwin developers that this format remains the same always. Cygwin 1.9 might have a better idea yet, breaking my code. Thus my suggestion that ioctl() from Cygwin support this ":index" format, which it currently doesn't, also in 1.7.7. The solution that I do prefer, is one similar to QNX. QNX behaves differently to Linux, but could be the simplest implementation for Cygwin. If an interface has aliases, it simply has multiple records in getifaddrs(). The ioctl() interface returns the main/preferred address. Cygwin could return the first AF_INET record in this case. Here's the problem. Windows does not mark an IPv4 address as preferred address, nor does it always return the addresses in the order you'd expect. Actually, it appears as if the addresses of an interface are always returned in ascending order (on W7, at least). So, following your proposal, if you add an address which is numerically lower than the other addresses, the next call to ioctl(SIOCGIFADDR) would return the new address. If you remove the address again it would return the old address again. From my POV this is as much surprising as the current behaviour. Hence my proposal. That's why it is now a good time to move to getifaddrs() as recommended in general for systems that support it. The programmer can remove this issue because they get a complete list. Even on Linux, QNX, FreeBSD, Solaris, ioctl() can't guarantee atomicity. With ioctl() interface may change sometime between queries. getifaddrs() offers the potential for atomicity. And they all provide getifaddrs(). This issue will also only be apparent if the user has multiple IPv4 addresses assigned to a single interface. I'm also assuming, that IP address orders will only change if there is a change in the system configuration. So such a surprise won't occur too often. But importantly, interface names are known in advance with ioctl() without having to use SIOCGIFCONF. And it provides for the minimalistic amount of change to Cygwin, remains compatible with other OSes and mappings continue to work with names returned by getifaddrs() and ioctl() - always. Jason. -- 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: Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
Jason Curl arcor.de> writes:
> Corinna Vinschen cygwin.com> writes:
> > So, for the above interface we get
> >
> > 371D57D9-0FF3-402C-AB69-E88FF9D85BC3:f36e.1
> >
> > as the unique alias name for the given IPv4 address.
> >
>
> The solution that I do prefer, is one similar to QNX. QNX behaves differently
> to Linux, but could be the simplest implementation for Cygwin. If an
> interface
> has aliases, it simply has multiple records in getifaddrs(). The ioctl()
> interface returns the main/preferred address. Cygwin could return the first
> AF_INET record in this case.
>
> That is, you might very well see:
> * en0, AF_INET, 192.168.0.1
> * en0, AF_INET, 169.254.123.45
> * en0, AF_INET6,
> * lo, AF_INET, 127.0.0.1
On the way home, I realised the current behaviour deviates from Linux also.
Linux getifaddrs():
* eth0 -> AF_INET
* eth0 -> AF_INET6
Cygwin getifaddrs():
* {xxx} -> AF_INET6
* {xxx}:1 -> AF_INET
This is another reason why I think it could be architecturally simpler to just
have multiple records and to drop the interface indices all together of the form
":1".
Thanks,
Jason.
--
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: Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
Corinna Vinschen cygwin.com> writes: > I think there's a potential solution to this problem. It just depends on > how important it is. > snip > So here's the idea. If we remove the braces from the GUID name, we drop > 2 chars, so we have 6 chars left. 6 chars are enough to convert the > IPv4 address into a radix-64 like string, using the l64a function. > > For instance, in my case the aforementioned interface has the IPv4 > address 192.168.129.107. That's 0xc0a8816b as long, which translates > into "f36e.1" as radix-64 value per the l64a function. > > So, for the above interface we get > > 371D57D9-0FF3-402C-AB69-E88FF9D85BC3:f36e.1 > > as the unique alias name for the given IPv4 address. > > Of course, if we do that, then all configured IPv4 address will always > get an alias name like this. Just skipping the alias extension for the > first IPv4 address of an interface would not be an option. Only the > IPv6 addresses would use the interface name without alias. I don't > think that's actually a problem, though, but I'm not sure. > > Any thoughts on this? Is it worth it? No - it's not worth it. One of my use cases is to test a particular interface if it has an IP address or not (due to DHCP, AutoIP, etc.). Then on definition of an address, I can trigger a process. This assumes that the interface names remains constant. So a dynamically changing interface name is something I'd like to NOT see. The solution that I do prefer, is one similar to QNX. QNX behaves differently to Linux, but could be the simplest implementation for Cygwin. If an interface has aliases, it simply has multiple records in getifaddrs(). The ioctl() interface returns the main/preferred address. Cygwin could return the first AF_INET record in this case. That is, you might very well see: * en0, AF_INET, 192.168.0.1 * en0, AF_INET, 169.254.123.45 * en0, AF_INET6, * lo, AF_INET, 127.0.0.1 Having something similar to QNX would mean a much simpler implementation for Cygwin and I need to deal with the case of multiple addresses in my software in any case. The ioctl()s would all work as the native interface name is used (primarily I need SIOCGIFHWADDR, SIOCGIFFRNDLYNAM and others that are not implicitly given by getifaddrs()), which is not the case today, unless all ioctl ()s are also updated. We also remove all uncertainty due to addresses being added and removed. After detecting that an interface has an address, I can check if it is in a particular subnet or not myself, or just assume that if at least one IP is assigned, everything is OK and get a list of all addresses myself. Linux inherently doesn't have this problem, as an alias once defined, behaves as an independent interface. I'd like to hear your thoughts. Jason. -- 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: Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
Jason Curl arcor.de> writes: > Hello, > > I've seen an issue when using getifaddrs() using Cygwin 1.7.x (snapshot > build from 2010-11-24, shortly after the ARP fixes from Corinna). > Operating System is Windows 7 x64_86 Ultimate. > > When I use getifaddrs() I get a list of interface names, some are > appended with ":1". > For extra information - this problem does not appear to be an issue when using Cygwin 1.7.7 (0.230/5/3) under Windows XP SP3. -- 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
Difference in behaviour between getifaddrs() and ioctl(SIOCGIFCONF)
Hello,
I've seen an issue when using getifaddrs() using Cygwin 1.7.x (snapshot
build from 2010-11-24, shortly after the ARP fixes from Corinna).
Operating System is Windows 7 x64_86 Ultimate.
When I use getifaddrs() I get a list of interface names, some are
appended with ":1".
Getting the list with ioctl(SIOCGIFCONF) provides a different list of
names, where interface names only differ sometimes by ":1".
The list from ioctl() is correct, that from getifaddrs() is incorrect,
in that the name cannot be used to resolve the HWADDR, SIOCGIFFRNDLYNAM
with ioctl().
Using getifaddrs():
device: {4ED54D4E-1024-4BDF-A926-67D2895D2DC4};
ioctl(SIOCGIFFRNDLYNAM)=0 Local Area Connection 4
device: {A045DC0F-A979-49B3-954C-D0678365FF26}:1; ioctl(SIOCGIFFRNDLYNAM)=-1
device: {4EB69B61-C791-434A-8FCE-8F4859EA8DFC};
ioctl(SIOCGIFFRNDLYNAM)=0 Local Area Connection 3
device: {85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007};
ioctl(SIOCGIFFRNDLYNAM)=0 Bluetooth Network Connection
device: {56D2E68A-4173-4117-A719-65123B973C65}:1; ioctl(SIOCGIFFRNDLYNAM)=-1
device: {7E5203E8-97DE-4822-9A2E-380BD258D97E}:1; ioctl(SIOCGIFFRNDLYNAM)=-1
device: {8424F604-4FAE-4541-9D8E-7B0A583A0956}:1; ioctl(SIOCGIFFRNDLYNAM)=-1
device: {846EE342-7039-11DE-9D20-806E6F6E6963}:1; ioctl(SIOCGIFFRNDLYNAM)=-1
Using ioctl(SIOCGIFCONF):
device: {4ED54D4E-1024-4BDF-A926-67D2895D2DC4};
ioctl(SIOCGIFFRNDLYNAM)=0 Local Area Connection 4
device: {A045DC0F-A979-49B3-954C-D0678365FF26};
ioctl(SIOCGIFFRNDLYNAM)=0 Bluetooth Network Connection 2
device: {4EB69B61-C791-434A-8FCE-8F4859EA8DFC};
ioctl(SIOCGIFFRNDLYNAM)=0 Local Area Connection 3
device: {85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007};
ioctl(SIOCGIFFRNDLYNAM)=0 Bluetooth Network Connection
device: {56D2E68A-4173-4117-A719-65123B973C65};
ioctl(SIOCGIFFRNDLYNAM)=0 Local Area Connection
device: {7E5203E8-97DE-4822-9A2E-380BD258D97E};
ioctl(SIOCGIFFRNDLYNAM)=0 VMware Network Adapter VMnet1
device: {8424F604-4FAE-4541-9D8E-7B0A583A0956};
ioctl(SIOCGIFFRNDLYNAM)=0 VMware Network Adapter VMnet8
device: {846EE342-7039-11DE-9D20-806E6F6E6963};
ioctl(SIOCGIFFRNDLYNAM)=0 Loopback Pseudo-Interface 1
My control panel shows only interfaces
* Bluetooth Network Connection 2
* Local Area Connection
* VMware Network Adapter VMnet1
* VMware Network Adapter VMnet8
--
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: ioctl() on socket fd's take 3 seconds on 1.7.7
Corinna Vinschen cygwin.com> writes: > > I tried to understand what this flag is for. As far as I can > > understand, windows will always reply to ARP requests. There's a > > registry entry for "gratuitous arp". So doesn't that imply IFF_NOARP > > will be set for all interfaces? > > You mean, it should *not* be set for all interface, don't you? > > PPP and SLIP interfaces usually don't do ARP, so I just set the > flag for them unconditionally. Yes - it should *not* be set for all interfaces, except SLIP, PPP as you've previously mentioned. Jason -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
On 23/11/2010 16:38, Corinna Vinschen wrote: On Nov 23 14:10, Jason Curl wrote: Actually, after reading a bit about this flag, the usage in Cygwin seems to be wrong anyway. I applied a patch so that IFF_NOARP is only set for PPP and SLIP devices, so the call to SendARP is gone. Please test CVS or the next developer snapshot. I tried to understand what this flag is for. As far as I can understand, windows will always reply to ARP requests. There's a registry entry for "gratuitous arp". So doesn't that imply IFF_NOARP will be set for all interfaces? I downloaded the snapshot as of today. The 3 second delays are no longer present (thanks!). Best Regards, Jason. -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
Corinna Vinschen cygwin.com> writes: > > On Nov 22 21:29, Jason Curl wrote: > > The actual delays are caused by SendARP() called from get_xp_ifs(). > > Interestingly enough, it isn't always slow, only sometimes. > > [...] > > First of all, thanks for looking deeper into this. Thanks for taking notice for my initial problem. > This autoconfig address is returned by GetAdapterAddresses so it has > been configured at one point, even if the interface is not visible. > > Ok, so SendARP is kind of a problematic call. As you can see from the > source code, it's only called to set the IFF_NOARP flag. Probably > that's a bit over the top. What about just disabling this code? I'll try this out on my next opportunity. I personally have no need for IFF_NOARP. Jason. -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
René Berber computer.org> writes:
>
> On 11/22/2010 2:29 PM, Jason Curl wrote:
> [snip]
> > And the interface that is failing: D4B7FEA9 = 169.254.183.212 doesn't
> > appear by a call to "ipconfig /all". I'm guessing that Windows is
> [snip]
> > I'm not sure where this IP is currently coming from...
>
> It's Microsoft's default address, used when the network interface is set
> to "Obtain an IP address automatically" and no server responds or
> accepts the request, and the "Alternate Configuration" is set to use
> "Automatic private IP address".
>
> But the real point is: it shouldn't be used in any case other than when
> the interface can't get an address. And that is only during
> configuration...
Your second point is not relevant, it doesn't matter if my interface is fixed,
DHCP or AutoIP, so long as the Windows routing table knows what IP address
belongs with which MAC. Proof is in the logs.
There are two instances of AutoIP. The second instance (VMware Network Adapter
VMnet1) is bound to an interface with 169.254.211.193. The problematic instance
169.254.183.212 isn't listed in "ipconfig".
So the question can be, where does 169.254.183.212 which doesn't appear to be
bound to a particular interface, so that when SendARP() is called, Win7 thinks
it needs to send a query out on the network thus causing a 3 second delay?
I didn't get enough time to get this far last night. It appears to be a problem
with "Tunnel adapter isatap.{A045DC0F-A979-49B3-954C-D0678365FF26}". But I have
a feeling it's probably to do with my Bluetooth Interface (as other tunnel
adapters don't cause problems).
{4ED54D4E-1024-4BDF-A926-67D2895D2DC4} a9fe0202
{A045DC0F-A979-49B3-954C-D0678365FF26} a9feb7d4 <- Culprit
{4EB69B61-C791-434A-8FCE-8F4859EA8DFC} a9fe0202
{85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007}
{56D2E68A-4173-4117-A719-65123B973C65} c0a80119
{7E5203E8-97DE-4822-9A2E-380BD258D97E} a9fed3c1
{8424F604-4FAE-4541-9D8E-7B0A583A0956} c0a8df01
{846EE342-7039-11DE-9D20-806E6F6E6963} 7f01
The output of my "ifconf" replacement shows, where the MAC address of the
culprit is the same as the BT interface:
{4ED54D4E-1024-4BDF-A926-67D2895D2DC4} AF_INET 169.254.2.2
255.255.255.0
169.254.2.255169.254.2.2 80:00:60:0F:E8:00 yes no
{A045DC0F-A979-49B3-954C-D0678365FF26} AF_INET 169.254.183.212
255.255.0.0
169.254.255.255 169.254.183.212 00:60:57:1B:21:99 yes no
{4EB69B61-C791-434A-8FCE-8F4859EA8DFC} AF_INET 169.254.2.2
255.255.255.0
169.254.2.255169.254.2.2 80:00:60:0F:E8:00 yes no
{85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007} AF_INET 0.0.0.0
255.0.0.0
0.255.255.2550.0.0.0 00:60:57:1B:21:99 yes no
{56D2E68A-4173-4117-A719-65123B973C65} AF_INET 192.168.1.25
255.255.255.0
192.168.1.255192.168.1.25 00:24:1D:71:F6:EC yes yes
{7E5203E8-97DE-4822-9A2E-380BD258D97E} AF_INET 169.254.211.193
255.255.0.0
169.254.255.255 169.254.211.193 00:50:56:C0:00:01 yes yes
{8424F604-4FAE-4541-9D8E-7B0A583A0956} AF_INET 192.168.223.1
255.255.255.0
192.168.223.255 192.168.223.100:50:56:C0:00:08 yes yes
{846EE342-7039-11DE-9D20-806E6F6E6963} AF_INET 127.0.0.1
255.0.0.0
127.255.255.255 127.0.0.100:00:00:00:00:00 yes yes
In this case, it appears that this is an example of an interface that is
*not* up.
Thanks & Best Regards,
Jason.
--
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: ioctl() on socket fd's take 3 seconds on 1.7.7
On 22/11/2010 14:17, Corinna Vinschen wrote:
Can you retry with the next developer snapshot? Are the ioctl calls
still slow? If so, I'm wondering if the GetAdaptersAddresses call is
rather slow if a lot of interfaces exist. Every single ioctl in your
application calls GetAdaptersAddresses twice, like this:
bool
get_adapters_addresses (PIP_ADAPTER_ADDRESSES *pa_ret, ULONG family)
{
DWORD ret, size = 0;
PIP_ADAPTER_ADDRESSES pa0 = NULL;
if (!pa_ret)
return ERROR_BUFFER_OVERFLOW
== GetAdaptersAddresses (family, GAA_FLAG_INCLUDE_PREFIX
| GAA_FLAG_INCLUDE_ALL_INTERFACES,
NULL, NULL,&size);
do
{
ret = GetAdaptersAddresses (family, GAA_FLAG_INCLUDE_PREFIX
| GAA_FLAG_INCLUDE_ALL_INTERFACES,
NULL, pa0,&size);
if (ret == ERROR_BUFFER_OVERFLOW
&& !(pa0 = (PIP_ADAPTER_ADDRESSES) realloc (pa0, size)))
break;
}
while (ret == ERROR_BUFFER_OVERFLOW);
if (ret != ERROR_SUCCESS)
{
if (pa0)
free (pa0);
*pa_ret = NULL;
return false;
}
*pa_ret = pa0;
return true;
}
It's not this function. I see it called twice after adding my own
syscall_printf and it's very quick taking about 7ms. The problem is
after the second call to this function from get_xp_ifs()
258 6374960 [main] a 3484 ioctl: fd 3, cmd 80487368
215 6375175 [main] a 3484 get_ifconf: **JC** get_xp_ifs()
1606 6376781 [main] a 3484 get_adapters_addresses: **JC**
get_adapters_addresses enter
310 6377091 [main] a 3484 get_adapters_addresses: **JC** call to
GetAdaptersAddresses
6361 6383452 [main] a 3484 get_adapters_addresses: **JC** call to
GetAdaptersAddresses finished
155 6383607 [main] a 3484 get_adapters_addresses: **JC** call to
GetAdaptersAddresses
6615 6390222 [main] a 3484 get_adapters_addresses: **JC** call to
GetAdaptersAddresses finished
292 6390514 [main] a 3484 get_adapters_addresses: **JC**
get_adapters_addresses leave
3112178 9502692 [main] a 3484 get_ifconf: **JC** 9896336 = get_xp_ifd()
The actual delays are caused by SendARP() called from get_xp_ifs().
Interestingly enough, it isn't always slow, only sometimes.
220 107969 [main] a 2808 ioctl: fd 3, cmd 80087364
256 108225 [main] a 2808 fhandler_socket::ioctl: **JC** get_ifconf()
310 108535 [main] a 2808 get_ifconf: **JC** get_xp_ifs()
322 108857 [main] a 2808 get_xp_ifs: **JC** -> A
363 109220 [main] a 2808 get_adapters_addresses: **JC**
get_adapters_addresses enter
327 109547 [main] a 2808 get_adapters_addresses: **JC** call to
GetAdaptersAddresses
8617 118164 [main] a 2808 get_adapters_addresses: **JC** call to
GetAdaptersAddresses finished
194 118358 [main] a 2808 get_adapters_addresses: **JC** call to
GetAdaptersAddresses
7119 125477 [main] a 2808 get_adapters_addresses: **JC** call to
GetAdaptersAddresses finished
122 125599 [main] a 2808 get_adapters_addresses: **JC**
get_adapters_addresses leave
1062 126661 [main] a 2808 get_xp_ifs: **JC** -> cnt=8
235 126896 [main] a 2808 get_xp_ifs: **JC** -> SendARP (D4B7FEA9, 0,
0x28C6FC, 0x28C704
3111331 3238227 [main] a 2808 get_xp_ifs: **JC** -> 67 = SendARP
(D4B7FEA9, 0, 0x28C6FC, 0x28C704 (=0))
459 3238686 [main] a 2808 get_xp_ifs: **JC** -> SendARP (1901A8C0, 0,
0x28C6FC, 0x28C704
276 3238962 [main] a 2808 get_xp_ifs: **JC** -> 0 = SendARP
(1901A8C0, 0, 0x28C6FC, 0x28C704 (=6))
735 3239697 [main] a 2808 get_xp_ifs: **JC** -> SendARP (C1D3FEA9, 0,
0x28C6FC, 0x28C704
351 3240048 [main] a 2808 get_xp_ifs: **JC** -> 0 = SendARP
(C1D3FEA9, 0, 0x28C6FC, 0x28C704 (=6))
283 3240331 [main] a 2808 get_xp_ifs: **JC** -> SendARP (01DFA8C0, 0,
0x28C6FC, 0x28C704
335 3240666 [main] a 2808 get_xp_ifs: **JC** -> 0 = SendARP
(01DFA8C0, 0, 0x28C6FC, 0x28C704 (=6))
264 3240930 [main] a 2808 get_xp_ifs: **JC** -> SendARP (017F, 0,
0x28C6FC, 0x28C704
344 3241274 [main] a 2808 get_xp_ifs: **JC** -> 0 = SendARP
(017F, 0, 0x28C6FC, 0x28C704 (=0))
311 3241585 [main] a 2808 get_ifconf: **JC** 15466896 = get_xp_ifd()
318 3241903 [main] a 2808 fhandler_socket::ioctl: **JC** 2672756 =
get_ifconf(0x80087364, 1628228800)
291 3242194 [main] a 2808 fhandler_socket::ioctl: 0 = ioctl_socket
(80087364, 28C8D4)
And the interface that is failing: D4B7FEA9 = 169.254.183.212 doesn't
appear by a call to "ipconfig /all". I'm guessing that Windows is
actually making a network request for this non-existent interface.
./Windows/v5.0/Include/WinError.h:#define ERROR_BAD_NET_NAME
67L
ERROR_BAD_NET_NAME
"The network name cannot be found. This error is returned on Windows
Vista and later when an ARP reply to the SendARP request was not
received. This error occurs if the destination IPv4 address could not be
reached."
I'm not sure where this IP is currently coming from...
$ ipconfig /all
Re: ioctl() on socket fd's take 3 seconds on 1.7.7
On 22/11/2010 14:17, Corinna Vinschen wrote: > On Nov 20 18:25, Jason Curl wrote: >> On 15/11/2010 17:22, Corinna Vinschen wrote: >>> On Nov 9 09:20, Jason Curl wrote: >>>>166 65418 [main] ipcheck 5580 ioctl: fd 3, cmd 80087364 >>>> --- Process 5580, exception C005 at 610C8C86 >>> >>> Crash in Cygwin, but the address doesn't help much, unfortunately. >>> >>>> Interestingly enough, the program works. That is, it finds all >>>> interfaces and returns correct values (except interface names are >>>> UUIDs instead of something more friendly like "eth0" that existed in >>>> 1.5.26). >>>> >> I've generated a relatively simple test case that I can compile >> using cygwin1-20101102.dll. > > Thank you. I can't reproduce any slowness, each ioctl takes only a > couple of milliseconds. At least I could reproduce the exception when > stracing the testcase and I've applied a matching patch to Cygwin. > > Can you retry with the next developer snapshot? Are the ioctl calls > still slow? If so, I'm wondering if the GetAdaptersAddresses call is > rather slow if a lot of interfaces exist. Every single ioctl in your > application calls GetAdaptersAddresses twice, like this: > > Can you test how long this call takes in your scenario, and if it > might be the culprit? I've downloaded cygwin1-20101118.dll as I didn't see anything newer and the problem still exists. So I downloaded the source and built my own binary. The problem still exists. I did see a change in behaviour - when using "strace", the 3 second delays are now present (with previous versions of cygwin1.dll, strace implied no delays, running vanilla would show delays). So could have the crash while using strace shortcircuited the 3 second timeout? I've attached the output of 'strace'. What I see is the following: 78 65155 [main] a 6984 ioctl: fd 3, cmd 80087364 3153263 3218418 [main] a 6984 fhandler_socket::ioctl: 0 = ioctl_socket (80087364, 28C8D4) 46 3218464 [main] a 6984 ioctl: returning 0 Regards, Jason. out.txt.bz2 Description: Binary data -- 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: ioctl() on socket fd's take 3 seconds on 1.7.7
On 15/11/2010 17:22, Corinna Vinschen wrote:
On Nov 9 09:20, Jason Curl wrote:
166 65418 [main] ipcheck 5580 ioctl: fd 3, cmd 80087364
--- Process 5580, exception C005 at 610C8C86
Crash in Cygwin, but the address doesn't help much, unfortunately.
Interestingly enough, the program works. That is, it finds all
interfaces and returns correct values (except interface names are
UUIDs instead of something more friendly like "eth0" that existed in
1.5.26).
>>
It will be a little later when I'm able to generate a working test case.
T'would be nice. Please make it short and simple and, if possible, in
plain C.
I've generated a relatively simple test case that I can compile using
cygwin1-20101102.dll.
compile using
$ gcc --version
gcc (GCC) 4.3.4 20090804 (release) 1
$ gcc ifconf.c
$ ./a.exe
The output looks something like:
DEBUG 1290273446.193553 main 50: SIOCGIFCONF start
DEBUG 1290273449.318553 main 52: SIOCGIFCONF end
Interface: {4ED54D4E-1024-4BDF-A926-67D2895D2DC4}
DEBUG 1290273449.320553 main 59: SIOCGIFADDR start
DEBUG 1290273452.442553 main 61: SIOCGIFADDR end
Family: AF_INET
Address: a9fe0202
DEBUG 1290273452.444553 main 72: SIOCGIFNETMASK start
DEBUG 1290273455.567553 main 74: SIOCGIFNETMASK end
Mask: ff00
DEBUG 1290273455.571553 main 77: SIOCGIFBRDADDR start
DEBUG 1290273458.694553 main 79: SIOCGIFBRDADDR end
Broadcast: a9fe02ff
DEBUG 1290273458.695553 main 82: SIOCGIFDSTADDR start
DEBUG 1290273461.817553 main 84: SIOCGIFDSTADDR end
Dest: a9fe0202
Interface: {A045DC0F-A979-49B3-954C-D0678365FF26}
DEBUG 1290273461.819553 main 59: SIOCGIFADDR start
DEBUG 1290273464.943553 main 61: SIOCGIFADDR end
Family: AF_INET
Address: a9feb7d4
DEBUG 1290273464.945553 main 72: SIOCGIFNETMASK start
DEBUG 1290273468.067553 main 74: SIOCGIFNETMASK end
Mask:
DEBUG 1290273468.068553 main 77: SIOCGIFBRDADDR start
DEBUG 1290273471.190553 main 79: SIOCGIFBRDADDR end
Broadcast: a9fe
DEBUG 1290273471.191553 main 82: SIOCGIFDSTADDR start
DEBUG 1290273474.313553 main 84: SIOCGIFDSTADDR end
Dest: a9feb7d4
Interface: {4EB69B61-C791-434A-8FCE-8F4859EA8DFC}
DEBUG 1290273474.315553 main 59: SIOCGIFADDR start
DEBUG 1290273477.437553 main 61: SIOCGIFADDR end
Family: AF_INET
Address: a9fe0202
DEBUG 1290273477.439553 main 72: SIOCGIFNETMASK start
DEBUG 1290273480.561553 main 74: SIOCGIFNETMASK end
Mask: ff00
DEBUG 1290273480.562553 main 77: SIOCGIFBRDADDR start
DEBUG 1290273483.685553 main 79: SIOCGIFBRDADDR end
Broadcast: a9fe02ff
DEBUG 1290273483.686553 main 82: SIOCGIFDSTADDR start
DEBUG 1290273486.808553 main 84: SIOCGIFDSTADDR end
Dest: a9fe0202
Interface: {85C2CEC7-A2B9-47D4-9A50-D63E9F9ED007}
DEBUG 1290273486.810553 main 59: SIOCGIFADDR start
DEBUG 1290273489.931553 main 61: SIOCGIFADDR end
Family: AF_INET
Address:
DEBUG 1290273489.934553 main 72: SIOCGIFNETMASK start
DEBUG 1290273493.03 main 74: SIOCGIFNETMASK end
Mask: ff00
DEBUG 1290273493.056553 main 77: SIOCGIFBRDADDR start
DEBUG 1290273496.178553 main 79: SIOCGIFBRDADDR end
Broadcast: 00ff
DEBUG 1290273496.179553 main 82: SIOCGIFDSTADDR start
DEBUG 1290273499.303553 main 84: SIOCGIFDSTADDR end
Dest:
Interface: {56D2E68A-4173-4117-A719-65123B973C65}
DEBUG 1290273499.305553 main 59: SIOCGIFADDR start
DEBUG 1290273502.427553 main 61: SIOCGIFADDR end
Family: AF_INET
Address: c0a80119
DEBUG 1290273502.429553 main 72: SIOCGIFNETMASK start
DEBUG 1290273505.550553 main 74: SIOCGIFNETMASK end
Mask: ff00
DEBUG 1290273505.551553 main 77: SIOCGIFBRDADDR start
DEBUG 1290273508.674553 main 79: SIOCGIFBRDADDR end
Broadcast: c0a801ff
DEBUG 1290273508.675553 main 82: SIOCGIFDSTADDR start
DEBUG 1290273511.798553 main 84: SIOCGIFDSTADDR end
Dest: c0a80119
Interface: {7E5203E8-97DE-4822-9A2E-380BD258D97E}
DEBUG 1290273511.800553 main 59: SIOCGIFADDR start
DEBUG 1290273514.921553 main 61: SIOCGIFADDR end
Family: AF_INET
Address: a9fed3c1
DEBUG 1290273514.923553 main 72: SIOCGIFNETMASK start
DEBUG 1290273518.045553 main 74: SIOCGIFNETMASK end
Mask:
DEBUG 1290273518.046553 main 77: SIOCGIFBRDADDR start
DEBUG 1290273521.168553 main 79: SIOCGIFBRDADDR end
Broadcast: a9fe
DEBUG 1290273521.170553 main 82: SIOCGIFDSTADDR start
DEBUG 1290273524.292553 main 84: SIOCGIFDSTADDR end
Dest: a9fed3c1
Interface: {8424F604-4FAE-4541-9D8E-7B0A583A0956}
DEBUG 1290273524.294553 main 59: SIOCGIFADDR start
DEBUG 1290273527.416553 main 61: SIOCGIFADDR end
Family: AF_INET
Address: c0a8df01
DEBUG 1290273527.418553 main 72: SIOCGIFNETMASK start
DEBUG 1290273530.540553 main 74: SIOCGIFNETMASK end
Mask: ff00
DEBUG 1290273530.541553 main 77: SIOCGIFBRDADDR start
DEBUG 1290273533.665553 main 79: SIOCGIFBRDADDR end
Broadcast: c0a8dfff
DEBUG 1290273533.666553 main 82: SIOCGIFDSTADDR start
DEBUG 1290273536.788553 main 84: SIOCGIFDSTADDR end
Dest: c0a8df01
Interface: {846EE342-7039-11DE-9D20-806E6F6E6963}
DEBUG 12902735
Re: Stack dumps from sh.exe (from within make)
Jim Reisert AD1C alum.mit.edu> writes: > Here is some of the console output: > > # make wintest > > g++ -g -Wall -c -o writelog.o writelog.c > g++ ctyfiles.o library.o csv.o ct8.o ct9.o mwl.o n3fjp.o na.o > wintest.o wpxloc.o writelog.o -o ctyfiles > pushd .. ; make cty/entities.csv > /cygdrive/e/unified /cygdrive/e/unified/cty > 0 [main] sh 5372 exception::handle: Exception: STATUS_ACCESS_VIOLATION > 645 [main] sh 5372 open_stackdumpfile: Dumping stack trace to > sh.exe.stackdump > 0 [main] sh 2224 child_copy: linked dll data write copy failed, > 0x3BD000..0x3C14A4, done 0, windows pid 2608, Win32 error 487 It looks like the same problem answered by Larry Hall on 7th November (STATUS_ACCESS_VIOLATION). See http://article.gmane.org/gmane.os.cygwin/123315 You might want to try running rebaseall. Regards, Jason. -- 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
ioctl() on socket fd's take 3 seconds on 1.7.7
Hello,
Cygwin 1.7.7 is definitely an improvement over 1.5.x but I see a
regression on 1.7.7 (on Win7 x64) that ioctl() on a socket FD takes 3
seconds.
I'm writing my own ifconfig replacement and I do the following:
#define IFC_BUF 10 * sizeof(struct ifreq)
#define MAX_IFC_BUF 8192
buf = malloc(IFC_BUF);
buflen = IFC_BUF;
s = socket(AF_INET, SOCK_DGRAM, 0);
ifc.ifc_buf = buf;
intf = FALSE;
while (buflen < MAX_IFC_BUF && !intf) {
ifc.ifc_len = buflen;
if (ioctl(s, SIOCGIFCONF, &ifc) >= 0) {
^
The ioctl() takes 3 seconds to execute. I've tested cygwin1.dll 1.7.7-1
and snapshot 20101102.
Not only this ioctl, but also the following ioctl()'s take 3 seconds per
call:
if (ioctl(s, SIOCGIFADDR, intf[h].ifr) < 0) {
if (ioctl(s, SIOCGIFNETMASK, intf[h].ifr) < 0) {
if (ioctl(s, SIOCGIFBRDADDR, intf[h].ifr) < 0) {
if (ioctl(s, SIOCGIFDSTADDR, intf[h].ifr) < 0) {
if (ioctl(s, SIOCGIFHWADDR, intf[h].ifr) < 0) {
if (ioctl(s, SIOCGIFFLAGS, intf[h].ifr) < 0) {
When running 'strace' on my executable, execution is fast (there are no
longer the 3 second timeouts) and the program takes 200ms to complete,
not 1.5 minutes (for 8 nics). However, the following is visible in the
logs (I used cygwin1-20101102.dll for the latest tests). Notice the
exception:
166 32185 [main] ipcheck 5580 cygwin_socket: socket (2, 2 (flags
0x0), 0)
29950 62135 [main] ipcheck 5580 wsock_init: res 0
30 62165 [main] ipcheck 5580 wsock_init: wVersion 514
22 62187 [main] ipcheck 5580 wsock_init: wHighVersion 514
19 62206 [main] ipcheck 5580 wsock_init: szDescription WinSock 2.0
20 62226 [main] ipcheck 5580 wsock_init: szSystemStatus Running
19 62245 [main] ipcheck 5580 wsock_init: iMaxSockets 0
18 62263 [main] ipcheck 5580 wsock_init: iMaxUdpDg 0
21 62284 [main] ipcheck 5580 wsock_init: lpVendorInfo 0
2807 65091 [main] ipcheck 5580 build_fh_pc: fh 0x61242014
74 65165 [main] ipcheck 5580 fhandler_base::set_flags: flags
0x10002, supplied_bin 0x0
23 65188 [main] ipcheck 5580 fhandler_base::set_flags:
O_TEXT/O_BINARY set in flags 0x1
21 65209 [main] ipcheck 5580 fhandler_base::set_flags: filemode
set to binary
19 65228 [main] ipcheck 5580 fdsock: fd 3, name '', soc 0x170
24 65252 [main] ipcheck 5580 cygwin_socket: 3 = socket (2, 2
(flags 0x0), 0)
166 65418 [main] ipcheck 5580 ioctl: fd 3, cmd 80087364
--- Process 5580, exception C005 at 610C8C86
38639 104057 [main] ipcheck 5580 exception::handle: In
cygwin_except_handler exc 0xC005 at 0x610C8C86 sp 0x26C7A0
114 104171 [main] ipcheck 5580 exception::handle: In
cygwin_except_handler sig 11 at 0x610C8C86
31 104202 [main] ipcheck 5580 exception::handle: In
cygwin_except_handler calling 0x0
31 104233 [main] ipcheck 5580 __set_errno: void san::leave():284 val 14
26 104259 [main] ipcheck 5580 fhandler_socket::ioctl: error in
get_ifconf
28 104287 [main] ipcheck 5580 fhandler_socket::ioctl: -1 =
ioctl_socket (80087364, CDAD80)
23 104310 [main] ipcheck 5580 ioctl: returning -1
Interestingly enough, the program works. That is, it finds all
interfaces and returns correct values (except interface names are UUIDs
instead of something more friendly like "eth0" that existed in 1.5.26).
My antivirus has been closed (not simply deactivated) with no change in
behaviour.
It will be a little later when I'm able to generate a working test case.
Thanks & Best Regards,
Jason.
--
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: Bug in fork() while in a thread
Corinna Vinschen cygwin.com> writes: > On Aug 15 14:53, Christopher Faylor wrote: > > On Sun, Aug 15, 2010 at 07:42:01PM +0200, Jason Curl wrote: > > >Is it allowed to issue the fork() system call while not in the main > > >thread? When I read the OpenGroup specifications I don't seem to find > > >anything against allowing this. > > If I'm reading this correctly then "the stack" in this case is the stack > > associated with the main thread. Cygwin only duplicates the stack in > > the executing thread. In your example, env (or presumably env2) from > > the main thread is passed to another thread which then calls fork. In > > that scenario, the forked process is going to see garbage in env since > > the array has never been initialized. > I guess I'm missing something here. Here's an excerpt from the SUSv4 > fork man page: > > The fork() function shall create a new process. The new process (child > process) shall be an exact copy of the calling process (parent process) > except as detailed below: > > [...] > > o A process shall be created with a single thread. If a > multi-threaded process calls fork(), the new process shall contain > a replica of the calling thread and its entire address space, > possibly including the states of mutexes and other resources. > [...] > > Is the stack of another thread, which is not executed in the forked > process anymore, a part of the calling's thread "entire address space"? Open Group Posix.1c-2004 mentions only a "signal stack" doesn't need to be copied for XSI. Linux & FreeBSD 7.0 work OK. QNX641 returns ENOSYS if it even sniffs a thread call. I haven't tested Solaris Sparc. Which standard is Cygwin "closest" to, that I can use as a reference when I trip up on similar problems? I have the hint the SuSv4 implementation of Posix. Thanks for your wonderful support. Jason. -- 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: Bug in fork() while in a thread
On 15/08/2010 20:53, Christopher Faylor wrote: On Sun, Aug 15, 2010 at 07:42:01PM +0200, Jason Curl wrote: In particular, if I create a thread, then issue a fork(), data that exists on the stack is corrupted after the fork() is in the child. Using data on the heap doesn't show any issues (and is currently my workaround, in case this is a bug). If I'm reading this correctly then "the stack" in this case is the stack associated with the main thread. Cygwin only duplicates the stack in the executing thread. In your example, env (or presumably env2) from the main thread is passed to another thread which then calls fork. In that scenario, the forked process is going to see garbage in env since the array has never been initialized. It is theoretically possible to duplicate the stack of the main thread and other threads in the forked process but this isn't something that I, personally, would want to take on. I'm the guy who wrote the code that duplicates the state of the stack when a thread forks. It was done at the request of a customer and it was very tricky to get right. This isn't an experience I'd willingly take on again since it would be a lot of work, would require testing on every Windows OS from NT4 on, and would potentially slow down an already slow down Cygwin's already slow fork() implementation. However, if this is something that you're willing to do, I'll happily review a patch to the cygwin1.dll. You'd need to modify fork related code in dcrt0.cc. Thanks Chris for the detailed reply. I've got a workaround and you've confirmed it is correct with your explanation. I don't get much time, my C++ needs improving, let's see what I can do. cgf -- 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
Bug in fork() while in a thread
Hello,
Is it allowed to issue the fork() system call while not in the main
thread? When I read the OpenGroup specifications I don't seem to find
anything against allowing this.
In particular, if I create a thread, then issue a fork(), data that
exists on the stack is corrupted after the fork() is in the child. Using
data on the heap doesn't show any issues (and is currently my
workaround, in case this is a bug).
I've created a minimal example:
$ gcc -g -O0 forktestcase.c -o forktestcase.exe
$ ./forktest
Pointer BEFORE THE FORK env is 0x28cd00
This is the child
Pointer env is 0x28cd00
env[0] is
env[1] is
Child exited with 0
Further, a stackdump is now present, probably while iterating through
the null terminated array at 0x28cd00 after the fork().
If you have a look at the attached code, I believe the expected output is
$ ./forktest
Pointer BEFORE THE FORK env is 0x28cd00
This is the child
Pointer env is 0x28cd00
Child exited with 0
This bug is not recreatable if we execute fork() in the main thread and
not a separate thread.
Please find attached the test case.
#include
#include
#include
#include
struct mydat {
pthread_t pth;
char**env;
pid_t pid;
int status;
};
extern char **environ;
void *callfunc(void *data)
{
struct mydat *dat = data;
int pid;
int i;
printf("Pointer BEFORE THE FORK env is %p\n", dat->env);
i = 0;
while (dat->env[i]) {
printf(" env[%d] is %s\n", i, dat->env[i]);
i++;
}
pid = fork();
if (pid == 0) {
int i;
printf("This is the child\n");
printf("Pointer env is %p\n", dat->env);
i = 0;
while (dat->env[i]) {
printf(" env[%d] is %s\n", i, dat->env[i]);
i++;
}
exit(0);
} else {
int status;
dat->pid = pid;
waitpid(pid, &status, 0);
dat->status = status;
printf("Child exited with %d\n", WEXITSTATUS(status));
}
}
void newthread(struct mydat *dat)
{
if (pthread_create(&dat->pth, NULL, callfunc, dat)) {
perror("Couldn't create thread\n");
return;
}
pthread_join(dat->pth, NULL);
}
int main(int argc, char **argv)
{
struct mydat *dat;
int value1;
int valueb1, valueb2;
int fd1, fd2;
char *env2[] = { "APPTESTRESULT=42", (char *)0 };
char *env[] = { (char *)0 };
dat = malloc(sizeof(struct mydat));
dat->env = env;
newthread(dat);
free(dat);
}--
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: emacs in its own window
Gus K wrote: cygcheck gave the following: Found: C:\cygwin\bin\emacs.exe C:\cygwin\bin\emacs.exe C:\cygwin\bin\cygncurses7.dll C:\cygwin\bin\cygwin1.dll C:\Windows\system32\ADVAPI32.DLL C:\Windows\system32\ntdll.DLL C:\Windows\system32\KERNEL32.DLL C:\Windows\system32\RPCRT4.DLL This may be a bit old now, but I found my emacs wouldn't start yesterday either. Just running it seemed to do nothing, it dropped me back into the shell without starting anything. an "strace emacs" showed that a library couldn't be loaded, there might be a problem in the dependencies of the setup.ini file that Xaw is not listed as a dependency (cygXaw-7.dll in particular was needed). I have installed the first 4 packages-dlls How do i check about the last 4? -- 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: bash, rxvt and interactive shells not exiting as expected
Dave Korn wrote: On 19 December 2006 23:43, Jason Curl wrote: Now, AFAICT rxvt should be starting bash as a login shell in interactive mode. When I close the window from RXVT, a SIGHUP should be sent to bash, and according to the manpages from bash this should also cause SIGHUPs to all the other processes (e.g. effectively stopping everything from "log.sh"). I've also tried setting "shopt -s huponexit" but this doesn't have the effect I need. Instead, what I see is that after the RXVT shell is closed, there are still at least the first two processes that were started in the background are still running! I had expected them to quit. Any ideas? See this thread: http://www.google.co.uk/search?q=Re%3A+Bash+process+remains+after+I+close+rxvt +in+certain+ways&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&cli ent=firefox-a&rls=org.mozilla:en-GB:official Yep - read through that just now. I'm supposedly running a patched version of rxvt (rxvt-20050409-4) that contains some adjustments for the zombie bash. particularly http://www.cygwin.com/ml/cygwin/2006-12/msg00211.html Dunno if the test version is out yet. Haven't looked. cheers, DaveK -- 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: Bash process remains after I close rxvt in certain ways
Charles Wilson wrote: rxvt-20050409-4 (e.g. the test version now on the mirrors) also has a common behavior across all three cases, but that behavior is different than the behavior described above. The new rxvt exits and sighups the child (which obligingly goes ahead and dies; no zombies) in all three cases. You might also want to have a look at http://www.cygwin.com/ml/cygwin/2006-12/msg00712.html Here I see that all the child processes are not ended, this is with rxvt-20050409-4. Closing the window is performed by clicking the "X" on the top right under Windows XP SP2. Short of modifying any code, is there more information I can provide? It appears to work okay for me -- but I'll wait for comments on the test release before I promote it. -- Chuck -- 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/
bash, rxvt and interactive shells not exiting as expected
Dear Cygwin users, I've come across a behaviour that doesn't appear to match the description in the man pages, at least for bash. I have a shell script that starts some non-interactive tasks in the background. This shell script is then executed on startup when a user double clicks on an icon. For example, the shell script is called "~/bin/log.sh" The command I used to make the desktop shortcut is (all on one line): $ mkshortcut -a '-title Logging -e /bin/bash --login -i -c bin/log.sh' -i /bin/rxvt.exe -n "Logging" -s norm -w "`echo $HOME`" -D /bin/rxvt The script "log.sh" that describes the problem looks like: #!/bin/sh bin/myshell.sh 1 & bin/myshell.sh 2 & bin/myshell.sh 3 The script "myshell.sh" references above looks like: #!/bin/sh touch $1.txt; while [ 1 ]; do echo $1 >> ~/$1.txt sleep 1 done They're not my real scripts, but show the behaviour that I see. Now, AFAICT rxvt should be starting bash as a login shell in interactive mode. When I close the window from RXVT, a SIGHUP should be sent to bash, and according to the manpages from bash this should also cause SIGHUPs to all the other processes (e.g. effectively stopping everything from "log.sh"). I've also tried setting "shopt -s huponexit" but this doesn't have the effect I need. Instead, what I see is that after the RXVT shell is closed, there are still at least the first two processes that were started in the background are still running! I had expected them to quit. Any ideas? I didn't see this problem until I recently upgraded today, I was using a version of Cygwin from about 4 weeks ago previously. Since then I've seen that bash, rxvt and cygwin have all been updated. Thanks, Jason. Cygwin Configuration Diagnostics Current System Time: Wed Dec 20 00:35:58 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Program Files\ActiveState Perl Dev Kit 6.0 Deployment\bin\ c:\Program Files\Tcl\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\cvsnt c:\Program Files\Microsoft SQL Server\90\Tools\binn\ c:\Program Files\Delphi7SE\bin c:\Program Files\Delphi7SE\Projects\BPL c:\Program Files\CVSNT\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1004(jcurl)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1004(jcurl)GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'jcurl' PWD = '/home/jcurl' HOME = '/home/jcurl' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\jcurl' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/X11R6/man' APPDATA = 'C:\Documents and Settings\jcurl\Application Data' HOSTNAME = 'europa' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 7, GenuineIntel' WINDIR = 'C:\WINDOWS' VS80COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\' TEXDOCVIEW_txt = 'cygstart %s' PERL5LIB = 'C:\Program Files\ActiveState Perl Dev Kit 6.0 Deployment\lib\' TEXDOCVIEW_dvi = 'cygstart %s' OLDPWD = '/home/jcurl/bin' USERDOMAIN = 'EUROPA' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' TEMP = '/cygdrive/c/DOCUME~1/jcurl/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' QTJAVA = '"C:\Program Files\Java\j2re1.4.2_06\lib\ext\QTJava.zip"' USERNAME = 'jcurl' TEXDOCVIEW_pdf = 'cygstart %s' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' TEXDOCVIEW_html = 'cygstart %s' USERPROFILE = 'C:\Documents and Settings\jcurl' CLIENTNAME = 'Console' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\EUROPA' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/jcurl/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0207' CLASSPATH = '"C:\Program Files\Java\j2re1.4.2_06\lib\ext\QTJava.zip"' PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig' TEXDOCVIEW_ps = 'cygstart %s' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' DISPLAY = ':0' NUMBER_OF_PROCESSORS = '1' SESSIONNAME = 'Console' COMPUTERNAME = 'EUROPA' _ = '/usr/bin/cygcheck' POSIXLY_CORRECT = '1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (
Re: what's the difference between File Handle and File Descriptor?
news.gosonic.com wrote: Thanks One is high level (streams, file handles) the other is low level (file descriptors). Have a look at the difference between fopen() and open(). -- 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/
Cygwin files and devices philosophy
Hello, I have a general question for the developers of cygwin. When I open the file "\\.\COM37" this is not opened by cygwin as a serial port, but rather as a file. The reasoning (that I'm not disputing) is cygwin should have more of a posix/unix flavour. And so specific functionality to treat this as a COM port was removed. So what "should ideally" happen when I open the file? 1. The file should be opened and no error 2. The file should be rejected by cygwin, as the paths don't look "posix". If we take 1, it makes the rules simpler. Maybe this was provided because we really do want to open this and get a handle. Maybe we want to open a network device instead of a hardware device (which has similar sematics). For point 2, this might be considered valid because the path is not POSIX and may confuse programs where the file to open is part of a command line argument. In my case, I provide an option for a terminal program what device should be used to open the file. I don't want to restrict what devices are or are not allowed, except by using function calls to the Posix API to determine if the required functionality can be met. However, if a user passes '\\.\COM37' it opens, isatty() is successful and my software hangs. Should it be up to my program to filter out nasty devices, or the underlying API? Needless to say, that this file doesn't behave as a tty because the fhandler_disk functions are being used. But other functions that I would expect to fail, don't. I ask, so that I may understand in what direction cygwin developers prefer so I can modify my software in the appropriate way. I'd like it not to have any specific knowledge of cygwin, but it will if need be. Could something of this nature lead to a security vulnerability in cygwin? -- 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: PATH and SystemRoot oddity
Igor Pechtchanski wrote:
First off, you could have actually removed the offending entries from the
PATH using something like
OFFENDING_ENTRY="/cygdrive/c/ClearCase/bin"
PATH="`echo "$PATH" | sed "s#:$OFFENDING_ENTRY##"`"
Alternatively, if you want to translate any Win32 path to a Cygwin
(POSIX) path, use the "cygpath" utility, like this:
PATH=${PATH}:"`cygpath -u "$SYSTEMROOT/system32"`"
Glad it helped. Out of curiousity, which one of the two solutions above
did you mean?
Originally, I was looking for something like 'cygpath' in it, but I was
pleasantly surprised by the other solution:
OFFENDING_ENTRY="/cygdrive/c/ClearCase/bin"
PATH="`echo "$PATH" | sed "s#:$OFFENDING_ENTRY##"`"
I'm now modifying it to remove paths with 'Rational' in it. I'd rather
not modify the original 'profile' if I can help it. Makes it easier to
destroy cygwin and reinstall from scratch.
--
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: PATH and SystemRoot oddity
Igor Pechtchanski wrote:
On Fri, 26 Nov 2004, Jason Curl wrote:
I have a similar question: I had to modify 'profile' to change
$PATH=:$PATH
to
$PATH=
How can I simply add $SYSTEMROOT:$SYSTEMROOT/system32 to this? It
doesn't work as-is because $SYSTEMROOT = C:\Windows (and this is
therefore not interpreted by the path). Rephrasing, what do I use to
translate "C:\WINDOWS" to "/cygdrive/c/windows"?
I had to do this because some nasty things in my path were causing
First off, you could have actually removed the offending entries from the
PATH using something like
OFFENDING_ENTRY="/cygdrive/c/ClearCase/bin"
PATH="`echo "$PATH" | sed "s#:$OFFENDING_ENTRY##"`"
Alternatively, if you want to translate any Win32 path to a Cygwin (POSIX)
path, use the "cygpath" utility, like this:
PATH=${PATH}:"`cygpath -u "$SYSTEMROOT/system32"`"
HTH,
Igor
P.S. FWIW, the question is not that similar, and you should probably have
started a new thread with it.
Sorry - next time it will be a new thread. OTOH, this is exactly the
solution I didn't know how to implement. Spasibo Bolshoi!
--
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: PATH and SystemRoot oddity
Brian Dessent wrote: Luke Kendall wrote: I see that by default PATH includes some entries like %SystemRoot%/System32 I also note that $SystemRoot is undefined, yet $SYSTEMROOT contains the expected C:\WINDOWS value. This of course causes problems. Would a backslash-style path work correctly if it were properly interpolated into the PATH? Is the % notation special magic for Cygwin to handle DOS-isms? The case variance may be of interest, in that case. I think you're falsely attributing your errors to this. The cygwin DLL takes care of all the win32 -> posix translation of the path, and it knows about %SystemRoot%. If this were really the case don't you think tons of things would break? Try "echo $PATH" at your shell prompt and you'll see that the systemroot is correctly substituted. FWIW, I think environment variables are case-insensitive at the win32 API level. They preserve case but are not sensitive to it, just like ntfs. Brian I have a similar question: I had to modify 'profile' to change $PATH=:$PATH to $PATH= How can I simply add $SYSTEMROOT:$SYSTEMROOT/system32 to this? It doesn't work as-is because $SYSTEMROOT = C:\Windows (and this is therefore not interpreted by the path). Rephrasing, what do I use to translate "C:\WINDOWS" to "/cygdrive/c/windows"? I had to do this because some nasty things in my path were causing problems (e.g. ClearQuest/ClearCase) TIA, Jason. -- 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: select() read() and write() on /dev/console
Christopher Faylor cygwin.com> writes: > > On Mon, Nov 22, 2004 at 05:18:46PM +0000, Jason Curl wrote: > >Where is fds[0] defined, so I can see exactly what functions are being > >called by peek_console, etc.? e.g. fh->get_readahead_valid(); > >fh->bg_check(SIGTTIN). > > Also in dtable.cc. Look for the obvious. > > I can't build cygwin from work, and I can't download the sources by CVS (firewall). I downloaded the sources from home, but bringing them to work doesn't compile (the compile at home, but I don't have the test setup at home to do this test). The behaviour seen is - When running strace: - Pressing a key on the console doesn't get caught by select() very often - When it was caught, the very first instance provided that select() said there was data to read from fd 0, but a read returned EAGAIN/EWOULDBLOCK. When not running strace: - The key is caught much more often by select() - There is a high chance when EAGAIN/EWOULDBLOCK is returned by read() Analysis Looking at the strace logs, I see only one instance when select() set the bit for FD 0. In this one instance read() returned EAGAIN/EWOULDBLOCK. 01 128 cygwin_select: 4, 0x22EF48, 0x22EF40, 0x22EF38, 0x22EF50 02 128 dtable::select_read: /dev/console fd 0 03 128 dtable::select_write: /dev/console fd 1 04 128 dtable::select_read: /dev/com2 fd 3 05 128 cygwin_select: to->tv_sec 5, to->tv_usec 0, ms 5000 06 128 cygwin_select: sel.always_ready 1 07 128 select_stuff::cleanup: calling cleanup routines 08 128 peek_serial: fh->overlapped_armed 0 09 128 set_bits: me 0xA050188, testing fd 3 (/dev/com2) 10 128 set_bits: ready 1 11 128 set_bits: me 0xA081C40, testing fd 1 (/dev/console) 12 128 set_bits: ready 1 13 128 set_bits: me 0xA081C10, testing fd 0 (/dev/console) 14 128 set_bits: ready 1 15 128 select_stuff::poll: returning 3 16 128 select_stuff::cleanup: calling cleanup routines 17 128 select_stuff::~select_stuff: deleting select records 18 128 readv: readv (0, 0x22EEB0, 1) nonblocking, sigcatchers 2 19 128 fhandler_base::ready_for_read: read_ready 0, avail 0 20 128 readv: -1 = readv (0, 0x22EEB0, 1), errno 11 select_stuff:poll() calls peek_console in select.cc and this is returning 'true'. This implies that PeekConsoleInput() from Windows indicated there was a keypress and it sets 'read_ready=true'. This is seen from lines 01 to 15 of the log above. However, the interesting part is in the 'readv' stuff of 'syscalls.cc'. Line 18 comes from syscalls.cc, readv(). bg_check() returns bg_ok. fhandler_base::ready_for_read() is called. Why does fhandler_base::ready_for_read() have "read_ready 0", when it should have been set by PeekConsoleInput() by peek_console() called by select.cc? This appears to a failure. But on the other hand, if this function is called again, PeekConsoleInput() should still return that there is a character on the input and set 'read_ready' a second time. This is because I don't think ReadConsoleInput() should have been called as of yet. So I don't know where to go from here. Any ideas for going further in analysing the code? -- 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: select() read() and write() on /dev/console
Christopher Faylor cygwin.com> writes:
> In dtable::select_{read,write,except} .
>
> cgf
Where is fds[0] defined, so I can see exactly what functions are being called by
peek_console, etc.? e.g. fh->get_readahead_valid(); fh->bg_check(SIGTTIN).
Thanks.
--
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: select() read() and write() on /dev/console
Christopher Faylor cygwin.com> writes: > > On Fri, Nov 19, 2004 at 06:46:56PM +0100, Jason Curl wrote: > >My question, how do I go about investigating what the root cause is? Has > >anybody else seen similar issues and been able to work around it? I'm > >stuck and I've never seen the source code to cygwin before. > > If you suspect a problem with the cygwin DLL then you can build a > debugging version of the cygwin DLL and debug it using gdb. > > Most of the console handling is in fhandler_console.cc. The select > handling is in select.cc. Look for the string "console" there. > > Instructions for building the DLL are in the FAQ: > > http://cygwin.com/faq/faq_3.html#SEC101 > > Hello, In the function select.cc (v1.102.2.2): peek_console() there is a reference to the function fh->get_readahead_valid(). I don't see how 'fh' is assigned. What I've figured out so far is select_stuff::test_and_set builds up the linked list 'start.next'. fhandler_console::select_read initialises one of those entries in that linked list. But neither of these functions set s->fh to anything (so it defaults to NULL). Other two entries are writing to the console and reading from the serial port. btw, I don't know why is there in select_stuff::test_and_set the line if (s->window_handle || s->window_handle || s->window_handle) Then I look at fhandler.h and find get_readahead_valid() and from here I don't know what's going on. Could the comment at line 85 of fhandler.cc (inside fhandler_base::get_readahead) have anything to do with the problem I am having? So far I don't think so because the bit is being set by the return value of peek_console. It appears at least looking at the strace logs for the function peek_console() fh->get_readahead_valid() is returning 0. me->read_ready == 0 as expected also. The final result is that peek_console is returning a non-zero value. I'm going to start looking into the 'read' code now and see if I can figure out what the leadup to a value of -1 errno=11 could be. -- 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: select() read() and write() on /dev/console
Christopher Faylor cygwin.com> writes:
>
> On Sun, Nov 21, 2004 at 07:00:42PM +0100, Jason Curl wrote:
> >Christopher Faylor wrote:
> >>On Fri, Nov 19, 2004 at 06:46:56PM +0100, Jason Curl wrote:
> >>
> >>>My question, how do I go about investigating what the root cause is? Has
> >>>anybody else seen similar issues and been able to work around it? I'm
> >>>stuck and I've never seen the source code to cygwin before.
> >>
> >>
> >>If you suspect a problem with the cygwin DLL then you can build a
> >>debugging version of the cygwin DLL and debug it using gdb.
> >>
> >>Most of the console handling is in fhandler_console.cc. The select
> >>handling is in select.cc. Look for the string "console" there.
> >>
> >>Instructions for building the DLL are in the FAQ:
> >>
> >>http://cygwin.com/faq/faq_3.html#SEC101
> >>
> >Hello,
> >
> >Is there a way I can use debug_printf() inside C source (not C++). I've
> >found and .
> >
> >Googling and I don't find information about what I need to include, and
> >probably what I need to link.
> >
> >#define TRACE
> >#include
> >#include
> >
> >int main(void)
> >{
> > debug_printf("TEST\n");
> >}
> >
> >It won't link, not finding _err_handler.
>
> Just use regular printf or fprintf. debug_printf is not intended for
> use outside of the cygwin DLL.
>
>
Hello Chris,
I'll see how I go. Printf's aren't very useful in this case as data is on the
console so rapid it's not easy to see what's going on. The problem occurs only
when there is serial input, console input and console output. Remove the serial
input or the console output and the problem goes away.
I did an 'strace' with everything. There appears some kind of race condition (my
software is not running any threads, it's using select() to completely manage
data). What I find interesting are error codes reported by Windows 995 "The I/O
operation has been aborted because of either a thread exit or an application
request." that occurs in the serial handler.
When I am running strace, the keyboard events are being missed completely (I
modified my code to quit in this case, but it doesn't when I'm running strace).
Also as a variant, I changed the behaviour of the console to have blocking reads
and it blocks without strace, but doesn't block with strace. Admittedly, just
about everything is being logged with strace.
Thanks,
Jason.
--
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: select() read() and write() on /dev/console
Christopher Faylor wrote:
On Fri, Nov 19, 2004 at 06:46:56PM +0100, Jason Curl wrote:
My question, how do I go about investigating what the root cause is? Has
anybody else seen similar issues and been able to work around it? I'm
stuck and I've never seen the source code to cygwin before.
If you suspect a problem with the cygwin DLL then you can build a
debugging version of the cygwin DLL and debug it using gdb.
Most of the console handling is in fhandler_console.cc. The select
handling is in select.cc. Look for the string "console" there.
Instructions for building the DLL are in the FAQ:
http://cygwin.com/faq/faq_3.html#SEC101
Hello,
Is there a way I can use debug_printf() inside C source (not C++). I've
found and .
Googling and I don't find information about what I need to include, and
probably what I need to link.
#define TRACE
#include
#include
int main(void)
{
debug_printf("TEST\n");
}
It won't link, not finding _err_handler.
Thanks in advance.
Jason.
--
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: select() read() and write() on /dev/console
Christopher Faylor wrote: On Fri, Nov 19, 2004 at 06:46:56PM +0100, Jason Curl wrote: My question, how do I go about investigating what the root cause is? Has anybody else seen similar issues and been able to work around it? I'm stuck and I've never seen the source code to cygwin before. If you suspect a problem with the cygwin DLL then you can build a debugging version of the cygwin DLL and debug it using gdb. Most of the console handling is in fhandler_console.cc. The select handling is in select.cc. Look for the string "console" there. Instructions for building the DLL are in the FAQ: http://cygwin.com/faq/faq_3.html#SEC101 Created a test to try and localise the problem a little more. Just using the console on it's own doesn't appear to create the problem (I write to the console, read from the console). The application I've written that shows this problem is involving a serial port (in/out), a disk file for logging (out) and the console (in/out). I'll keep replying to this post as I find out more information. Thanks, Jason. -- 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/
select() read() and write() on /dev/console
Hello, I think I might have found a bug with the latest version of cygwin (downloaded one night ago 18Nov2004). I am writing a small terminal emulation software package to interface with an embedded device to perform logging. I use the console (/dev/stdin, /dev/stdout) and a serial port (/dev/com1). The console is configured to be non-canonical so that I can determine immediately when the user has pressed a key. Signals are also disabled by the console. If it's useful, I can post the code here later. So the problem is: I use select() to determine when I can write to the console, when to read from the console (for keypresses), when to write to the serial port and when to read from the serial port. Select() returns indicated that data is to read on /dev/stdin (which is correct, I indeed did press a key), but the read() function for this fails with -1 and errno=EWOULDBLOCK. If I enable the non-blocking behaviour of the console then the system really does block. The problem only appears to occur when there is a reasonable rate of dataoutput to the console. I'm receiving data at 115kpbs from the serial port and dumping it to the console with a little more information (e.g. a timestamp for every line). I've tested the software on Windows NT4 and Windows XP SP1 and they both exhibit the same behaviour, the faster computer not being so susceptible as the slower (Pentium IV 1.6GHz for the faster). The same code compiles on Linux FC3 and it runs correctly. My question, how do I go about investigating what the root cause is? Has anybody else seen similar issues and been able to work around it? I'm stuck and I've never seen the source code to cygwin before. Thanks, Jason -- 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/
