This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: select() hangs sometimes, for TCP connections


I run the process blocking in select() with strace.
It now runs correctly, but the TCL scenario blocks
elsewhere on a "eval exec bash ...".
gdb seems to show a freeze in a call to a
ReadFile() function -> again something with file
descriptors.

So, I put this command in a strace as well.
Guess what, it runs correctly, but...

It fails later on TCL "file delete" with
"permission denied", after around 60 iterations.
I mean the file was deleted so much times without
problem. It even failed during off work hours, so
there is no activity on the PC.
Permissions are not touched.

Here is the last lines (successful) of strace:

12:59:10 [main] pgtclsh 542 normalize_posix_path: src
/home/pgreplicator/data/rbase/euronet.lock
12:59:10 [main] pgtclsh 542 normalize_posix_path:
/home/pgreplicator/data/rbase/euronet.lock =
normalize_posix_path
(/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: conv_to_win32_path
(/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542 set_flags: flags: text
(0x2000000)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: src_path
/home/pgreplicator/data/rbase/euronet.lock, dst
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
flags 0x2000008, rc 0
12:59:10 [main] pgtclsh 542 symlink_info::check: not a
symlink
12:59:10 [main] pgtclsh 542 symlink_info::check: 0 =
symlink.check
(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
0x2148A0) (0x2000008)
12:59:10 [main] pgtclsh 542 path_conv::check:
root_dir(D:\),
this->path(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock),
set_has_acls(8)
12:59:10 [main] pgtclsh 542 normalize_posix_path: src
D:/cygwin/home/pgreplicator/data/rbase/euronet.lock
12:59:10 [main] pgtclsh 542 normalize_win32_path:
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock =
normalize_win32_path
(D:/cygwin/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: conv_to_win32_path
(D:/cygwin/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542 normalize_win32_path:
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock =
normalize_win32_path
(D:/cygwin/home/pgreplicator/data/rbase/euronet.lock)
12:59:10 [main] pgtclsh 542
mount_info::conv_to_win32_path: src_path
D:/cygwin/home/pgreplicator/data/rbase/euronet.lock,
dst
D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
flags 0x0, rc 0
12:59:10 [main] pgtclsh 542 symlink_info::check: not a
symlink
12:59:10 [main] pgtclsh 542 symlink_info::check: 0 =
symlink.check
(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock,
0x214770) (0x0)
12:59:10 [main] pgtclsh 542 path_conv::check:
root_dir(D:\),
this->path(D:\cygwin\home\pgreplicator\data\rbase\euronet.lock),
set_has_acls(8)

These calls are caused by the TCL command
"file delete"
So tcl84.dll calls cygwin1.dll for some part of the
work (may be Tcl_FSConvertToPathType()).
But as I don't see any trace of unlink (syscalls.cc),
May be TCL calls directly win32 for the final
deletion function.

Anyone to confirm or reject this analysis ?

$ cygcheck /usr/bin/tcl84.dll
D:/cygwin/bin/tcl84.dll
  C:\WINNT\System32\ADVAPI32.DLL
    C:\WINNT\System32\ntdll.dll
    C:\WINNT\System32\KERNEL32.dll
    C:\WINNT\System32\USER32.dll
      C:\WINNT\System32\GDI32.dll
    C:\WINNT\System32\RPCRT4.dll
  D:/cygwin/bin\cygwin1.dll

Is there a potential conflict if TCL calls
cygwin1.dll functions *and* something like
DeleteFileA() or DeleteFileW() of the OS ?

--- Patrick Samson wrote:
> Problem: sometimes select() doesn't return.
> 
> Context: I run a DB replication scenario,
> with cron, everything 5 mn. There is no change in
> the
> DB, so the scenario is always the same. Most of the
> time, it works. But eventually, after some time (may
> be some minutes or hours), a process A keeps waiting
> forever in select() for a response on a TCP socket.
> With gdb I can see that the other end B returned in
> its
> ReadCommand() function, meaning it has send its
> response and waits for a new command, so this side
> should be OK.
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]