Extremely slow compilation of C++ because of cc1plus does bad systemcalls
When compiling a very small and simple C++ program (which took 6 seconds), i profiled the execution. cc1plus was speding a lot of time trying to create .exe-files AND .lnk-files. This was the command-line: g++ -c -O0 -DGTEST_DONT_DEFINE_FAIL -std=gnu++14 -Iw64 -Icommon/freertos/include -Iw64/config/ -Icommon -Icommon/dali -Icommon/debug -Icommon/config -isystem ../Tools/googletest/include -isystem ../Tools/googlemock/include -DUNITTEST -g -Wall -Werror -pthread unittest/block_hvac_unittest.cc -o obj_unit_linux/unittest/block_hvac_unittest.o I used procmon to capture all system-calls done. This is a part of what happened: (search for .exe AND .lnk) Why does the preprocessor try to create these files (my command is just trying to compile (no linking)) ? 08:25:49.3879979 cc1plus.exe 7256 QueryAllInformationFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward BUFFER OVERFLOW CreationTime: 03/11/2017 13:52:16, LastAccessTime: 03/11/2017 13:52:16, LastWriteTime: 03/11/2017 13:52:16, ChangeTime: 03/11/2017 13:52:16, FileAttributes: DCNCI, AllocationSize: 4,096, EndOfFile: 4,096, NumberOfLinks: 1, DeletePending: False, Directory: True, IndexNumber: 0xe00065c3f, EaSize: 0, Access: Read EA, Read Attributes, Read Control, Position: 0, Mode: , AlignmentRequirement: Word 08:25:49.3880077 cc1plus.exe 7256 CloseFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward SUCCESS 08:25:49.3880800 cc1plus.exe 7256 CreateFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward\clwbintrin.h NAME NOT FOUND Desired Access: Read EA, Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a 08:25:49.3881391 cc1plus.exe 7256 CreateFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward\clwbintrin.h.exe NAME NOT FOUND Desired Access: Read EA, Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a 08:25:49.3882166 cc1plus.exe 7256 CreateFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward\clwbintrin.h.lnk NAME NOT FOUND Desired Access: Read EA, Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a 08:25:49.3882946 cc1plus.exe 7256 CreateFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward\clwbintrin.h.exe.lnk NAME NOT FOUND Desired Access: Read EA, Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a 08:25:49.3883608 cc1plus.exe 7256 CreateFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward SUCCESS Desired Access: Read EA, Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 08:25:49.3883767 cc1plus.exe 7256 QueryInformationVolume C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward SUCCESS VolumeCreationTime: 20/11/2015 20:57:08, VolumeSerialNumber: 8CA4-C6C6, SupportsObjects: True, VolumeLabel: OS 08:25:49.3883849 cc1plus.exe 7256 QueryAllInformationFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward BUFFER OVERFLOW CreationTime: 03/11/2017 13:52:16, LastAccessTime: 03/11/2017 13:52:16, LastWriteTime: 03/11/2017 13:52:16, ChangeTime: 03/11/2017 13:52:16, FileAttributes: DCNCI, AllocationSize: 4,096, EndOfFile: 4,096, NumberOfLinks: 1, DeletePending: False, Directory: True, IndexNumber: 0xe00065c3f, EaSize: 0, Access: Read EA, Read Attributes, Read Control, Position: 0, Mode: , AlignmentRequirement: Word 08:25:49.3883957 cc1plus.exe 7256 CloseFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward SUCCESS 08:25:49.3884696 cc1plus.exe 7256 CreateFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\c++\backward\clwbintrin.h NAME NOT FOUND Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a 08:25:49.3885450 cc1plus.exe 7256 CreateFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\clwbintrin.h SUCCESS Desired Access: Read EA, Read Attributes, Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened 08:25:49.3885619 cc1plus.exe 7256 QueryInformationVolume C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\clwbintrin.h SUCCESS VolumeCreationTime: 20/11/2015 20:57:08, VolumeSerialNumber: 8CA4-C6C6, SupportsObjects: True, VolumeLabel: OS 08:25:49.3885701 cc1plus.exe 7256 QueryAllInformationFile C:\cygwin64\lib\gcc\x86_64-w64-mingw32\6.4.0\include\clwbintrin.h BUFFER OVERFLOW CreationTime: 03/11/2017 13:52:14, LastAccessTime: 03/11/2017 13:52:14, LastWriteTime: 19/10/2017 03:25:55, Cha
LLVM/Clang 5.0.1 clang-format returning an error
Hi there, Just updated to LLVM/Clang 5.0.1 and clang-format is giving me the following error: Simple error report and hopefully easy to reproduce... $ clang-format --version : CommandLine Error: Option 'disable-symbolication' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options $ uname -a CYGWIN_NT-10.0 4SMMSF2 2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64 Cygwin Alan -- 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
Hi Cygwin
sup Cygwin https://goo.gl/FYxYpG Mike -- 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: setup takes a long time
Fergus Daly writes: > As an incidental query: > I deduce from the look of the snip above that you update Cygwin from > within Cygwin? You can update one Cygwin installation from another (distinct) Cygwin installation. You shouldn't do that from within the same Cygwin installation unless you really know what you're doing. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: setup takes a long time
Fergus Daly writes: > The setup program does seem to take a long time, even when it just > means "update" and even when there's nothing to update. Here's what > happens in unattended mode: […] Looks completely normal. Some of the scripts do need to look at quite a few files before deciding if there's real work to do, so a slow disk (spinning rust or network) can introduce noticeable delays. On an SSD it should be done in well under a minute. If not, you might need to check the settings on your antivirus solution to be less aggressive with read-ahead for things in the Cygwin directory. > I can kind of see the point of autorebase and update-info-dir, but why > revisit texlive every time, and why all the zp stuff, every time? Because that's the way to make it work reliably even around corner cases and nobody has come up with something better yet. Now, if you look at /var/log/setup.log.full you might see something interesting that might need fixing. TeXLive in particular might have picked up some settings that trigger re-generation of many or even all formats each time you run the script (you can run it by hand and see what it does). Unless you are familiar with how the TeXLive configuration manager works, your best bet is a complete re-installation of all packages associated with TeXLive and then it should work as intended again (i.e. do nothing unless something has changed). > Why does setup explore McShield and McAfee? Some time in the past it would otherwise fail to successfully install Cygwin on systems that had this crapware installed. It might be possible to just remove that from setup now, I would personally be in favor of it. > Incidentally note the switch -m. Without it, checking sha1sum's I > guess provides some kind of protection, but it's incredibly > time-consuming and seems quite unnecessarily to cover much more than > the files downloaded, even the entire resource? That check is there for an entirely different reason that will hopefully no longer be supported in the not-too-distant future. When that happens it can go away. > In the presumably very rare event of a broken download, could the > update not more simply just abort? No, it really was there originally to pick up files that you want to install, but have no entry in setup.ini for. If you never create your own packages or move files by hand in your mirror directory, you should _always_ use the -m switch. A broken download will be identified by a wrong SHA512 checksum (or a missing file, as it were). 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: setup takes a long time
On 2018-01-31 08:34, Buchbinder, Barry (NIH/NIAID) [E] wrote: > Jon Turney sent the following at Wednesday, January 31, 2018 9:02 AM >> On 31/01/2018 06:18, Fergus Daly wrote: [...] >>> >>> The setup program does seem to take a long time, even when it just >>> means "update" and even when there's nothing to update. Here's what >>> happens in unattended mode: >> >> These tasks are supposed to identify when they have no work to do, and >> do nothing quickly. It seems that is not always the case. > > Recently brought up: > https://cygwin.com/ml/cygwin/2018-01/msg00274.html > > It seems that this behavior is by design. > https://cygwin.com/ml/cygwin/2018-01/msg00275.html > > FWIW, I still wouldn't mind having a command line option that skips > rebase and postinstall scripts when nothing has been updated. Main reason for running setup when nothing has been updated is to (re)run rebase and other scripts that may not have completed successfully the first time for some reason. An option to skip might be nice for scheduled unattended updates, like hitting Cancel at the end; as would an option to have setup find and stop cygrunsrv server processes before starting updates, then restart cygrunsrv server processes before exiting. They do accept patches to setup ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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: setup takes a long time
Jon Turney sent the following at Wednesday, January 31, 2018 9:02 AM >On 31/01/2018 06:18, Fergus Daly wrote: [...] >> >> The setup program does seem to take a long time, even when it just >> means "update" and even when there's nothing to update. Here's what >> happens in unattended mode: > > These tasks are supposed to identify when they have no work to do, and > do nothing quickly. It seems that is not always the case. Recently brought up: https://cygwin.com/ml/cygwin/2018-01/msg00274.html It seems that this behavior is by design. https://cygwin.com/ml/cygwin/2018-01/msg00275.html FWIW, I still wouldn't mind having a command line option that skips rebase and postinstall scripts when nothing has been updated. Thanks, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: setup takes a long time
>> $ ./setup-2.884.x86_64.exe --local-install >> '\\necker\download\cygwin-packages' --no-admin --upgrade-also --quiet-mode >> --mirror-mode --no-shortcuts | ts -i Thank you, using ts is really illuminating. As an incidental query: I deduce from the look of the snip above that you update Cygwin from within Cygwin? I have always done so from within a DOS Command Prompt window, believing your way to be fatally flawed. Is your way (much more convenient) ALWAYS OK? What if cygwin1.dll is itself being updated? Fergus PS Or maybe you are using Windows PowerShell or similar. -- 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: environ: fix link error on 64-bit Cygwin
On Jan 31 07:52, Eric Blake wrote: > Forwarding from the gnulib list; is this something we should fix in > cygwin proper? Why does anybody remove the -Wl,--disable-auto-import flag? What for? The idea was to never use this flag on Cygwin and to get rid of the dllimport/dllexport nonsense... > On 01/31/2018 04:42 AM, Bruno Haible wrote: > > On 64-bit Cygwin, a libunistring build fails like this: > > [...] > > libtool: link: x86_64-pc-cygwin-gcc -g -O2 -Wl,--disable-auto-import -o > > .libs/test-environ.exe test-environ.o -L/usr/local/cygwin64/lib libtests.a > > ../lib/.libs/libunistring.dll.a -liconv libtests.a -L/usr/local/cygwin64/lib > > test-environ.o:test-environ.c:(.rdata$.refptr.environ[.refptr.environ]+0x0): > > undefined reference to `environ' > > collect2: error: ld returned 1 exit status > > > > This fixes it. > > [...] > > +_GL_EXTERN_C __declspec(dllimport) char **environ; But, other than that, an equivalent newlib patch would be ok. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: setup takes a long time
On 31/01/2018 06:18, Fergus Daly wrote: The setup program does seem to take a long time, even when it just means "update" and even when there's nothing to update. Here's what happens in unattended mode: [...] Try this with 'ts' from moreutils, e.g: $ ./setup-2.884.x86_64.exe --local-install '\\necker\download\cygwin-packages' --no-admin --upgrade-also --quiet-mode --mirror-mode --no-shortcuts | ts -i 00:00:00 Starting cygwin install, version 2.884 00:00:00 User has NO backup/restore rights 00:00:00 Current Directory: \\necker\download\cygwin-packages 00:00:00 Could not open Service control manager 00:00:00 root: C:\cygwin64 user 00:00:00 Selected local directory: \\necker\download\cygwin-packages 00:00:13 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash" 00:01:40 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_texlive_prep.dash" 00:00:00 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash" 00:00:03 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_adwaita-icon-theme.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_desktop-file-utils.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_fontconfig_cache_1.sh" 00:00:14 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_glib2.0.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_gnome-themes-standard.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_gnome-themes.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_hicolor-icon-theme.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_man-db.sh" 00:00:02 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_mate-icon-theme.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_mate-themes.sh" 00:00:00 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/zp_shared-mime-info.sh" 00:00:00 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/zp_texlive_finish.dash" 00:00:02 Ending cygwin install I can kind of see the point of autorebase and update-info-dir, but why revisit texlive every time, and why all the zp stuff, every time? Why These tasks are supposed to identify when they have no work to do, and do nothing quickly. It seems that is not always the case. does setup explore McShield and McAfee? Incidentally note the switch -m. Without it, checking sha1sum's I guess provides some kind of protection, but it's incredibly time-consuming and seems quite unnecessarily to cover much more than the files downloaded, even the entire resource? In the presumably very rare event of a broken download, could the update not more simply just abort? --local-install could indeed use some improvement. Note that the scan is also used to filter the list of packages, so (without --mirror-mode) we don't offer for installation packages we don't have the archive for... -- 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: environ: fix link error on 64-bit Cygwin
Forwarding from the gnulib list; is this something we should fix in
cygwin proper?
On 01/31/2018 04:42 AM, Bruno Haible wrote:
> On 64-bit Cygwin, a libunistring build fails like this:
>
> $ /bin/sh ../libtool --tag=CC --preserve-dup-deps --mode=link
> x86_64-pc-cygwin-gcc -g -O2 -L/usr/local/cygwin64/lib
> -Wl,--disable-auto-import -o test-environ.exe test-environ.o libtests.a
> ../lib/libunistring.la libtests.a
> libtool: link: x86_64-pc-cygwin-gcc -g -O2 -Wl,--disable-auto-import -o
> .libs/test-environ.exe test-environ.o -L/usr/local/cygwin64/lib libtests.a
> ../lib/.libs/libunistring.dll.a -liconv libtests.a -L/usr/local/cygwin64/lib
> test-environ.o:test-environ.c:(.rdata$.refptr.environ[.refptr.environ]+0x0):
> undefined reference to `environ'
> collect2: error: ld returned 1 exit status
>
> This fixes it.
>
>
> 2018-01-31 Bruno Haible
>
> environ: Fix link error on 64-bit Cygwin.
> * lib/unistd.in.h (environ): On Cygwin, redeclare with the
> __declspec(dllimport) attribute.
> * doc/posix-functions/environ.texi: Mention the Cygwin problem.
>
> diff --git a/doc/posix-functions/environ.texi
> b/doc/posix-functions/environ.texi
> index 34ac25a..a6c0095 100644
> --- a/doc/posix-functions/environ.texi
> +++ b/doc/posix-functions/environ.texi
> @@ -24,6 +24,9 @@ shared libraries on Mac OS X 10.5. Here is a workaround:
> Instead, one can use
> #define environ (*_NSGetEnviron())
> @end smallexample
> This works at all versions of Mac OS X.
> +@item
> +On Cygwin in 64-bit mode, references to this variable cause a link error when
> +the option @code{-Wl,--disable-auto-import} is in use.
> @end itemize
>
> Portability problems not fixed by Gnulib:
> diff --git a/lib/unistd.in.h b/lib/unistd.in.h
> index 6802e3b..4ef0ffa 100644
> --- a/lib/unistd.in.h
> +++ b/lib/unistd.in.h
> @@ -400,6 +400,13 @@ _GL_WARN_ON_USE (dup3, "dup3 is unportable - "
>
>
> #if @GNULIB_ENVIRON@
> +# if defined __CYGWIN__
> +/* The 'environ' variable is defined in a DLL. Therefore its declaration
> needs
> + the '__declspec(dllimport)' attribute, but the system's lacks
> it.
> + This leads to a link error on 64-bit Cygwin when the option
> + -Wl,--disable-auto-import is in use. */
> +_GL_EXTERN_C __declspec(dllimport) char **environ;
> +# endif
> # if !@HAVE_DECL_ENVIRON@
> /* Set of environment variables and values. An array of strings of the form
> "VARIABLE=VALUE", terminated with a NULL. */
>
>
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: RPC clnt_create() adress already in use
Corinna Vinschen wrote:
On Jan 31 00:15, Mark Geisert wrote:
PAULUS, Raimund, TI-ABN wrote:
Hi Mark,
in my email (https://sourceware.org/ml/cygwin/2017-12/msg00194.html) i
described 2 approaches. I prefer nr 1.
Here the part of the source in bindresvport.c:
[...]
[...]
I'm a bit puzzled here in terms of using your own bindresvport. Cygwin
implements bindresvport{_sa} for quite some time, 2006 or earlier.
Yeesh; I did not know that. Thanks for pointing that out. So that means there's
another possible way to try solving the OP's issue: by using Cygwin's
bindresvport* in place of the one supplied with libtirpc.
If we see the OP's issue with Cygwin's bindresvport*, I think it makes more
sense to patch libtirpc than to change Cygwin's bindresvport*. The crux of OP's
issue is that libtirpc's code expects to see EADDRINUSE errors from bind()
whereas on Cygwin they aren't often seen until you connect().
I'll look into using Cygwin's bindresvport() in the next day or two.
Thanks all,
..mark
--
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: RPC clnt_create() adress already in use
On Jan 31 00:15, Mark Geisert wrote:
> PAULUS, Raimund, TI-ABN wrote:
> > Hi Mark,
> >
> > in my email (https://sourceware.org/ml/cygwin/2017-12/msg00194.html) i
> > described 2 approaches. I prefer nr 1.
> > Here the part of the source in bindresvport.c:
> > [...]
> > This causes bind() to search an unused port. I use libtirpc with this fix
> > since several weeks and it works for me. I don't know an other way (fixing
> > Cygwin) to success.
> > The RPC-client on my pc is started every few minutes and has to connect to
> > the RPC-server. Without the fix libtirpc is not usable and I have to use
> > Cygwin 1.5.18 with the old librpc.
> [...]
>
> Hi Raimund,
> Thanks for attaching the complete source for your modified bindresvport.c.
> I had been treating your setting of port to 0 as a workaround rather than as
> a solution. My misunderstanding.
>
> We can't solve the issue that way because when bind() is called with a
> zeroed port number, it picks a random port number that's often outside the
> range of ports bindresvport() is supposed to return (i.e., a port between
> STARTPORT and ENDPORT).
>
> I thought of something similar to your idea but obeying the bindresvport()
> semantics. I add a static short value named 'usecount' to the function's
> local variables. Mid-function, I have this code to choose a port number:
> if (port == 0) {
> port = ((getpid() + usecount++) % NPORTS) + STARTPORT;
> }
>
> Can you try this with your testcase(s) and make sure it works for you?
I'm a bit puzzled here in terms of using your own bindresvport. Cygwin
implements bindresvport{_sa} for quite some time, 2006 or earlier.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: RPC clnt_create() adress already in use
PAULUS, Raimund, TI-ABN wrote:
Hi Mark,
in my email (https://sourceware.org/ml/cygwin/2017-12/msg00194.html) i
described 2 approaches. I prefer nr 1.
Here the part of the source in bindresvport.c:
--
if (port == 0) {
port = (getpid() % NPORTS) + STARTPORT;
}
res = -1;
errno = EADDRINUSE;
/* fix for bind() */
port = 0;
again:
for (i = 0; i < nports; ++i) {
*portp = htons(port++);
if (port > endport)
port = startport;
res = bind(sd, sa, salen);
if (res >= 0 || errno != EADDRINUSE)
break;
}
if (i == nports && startport != LOWPORT) {
startport = LOWPORT;
endport = STARTPORT - 1;
nports = STARTPORT - LOWPORT;
port = LOWPORT + port % (STARTPORT - LOWPORT);
goto again;
}
mutex_unlock(&port_lock);
return (res);
}
---
This causes bind() to search an unused port. I use libtirpc with this fix since
several weeks and it works for me. I don't know an other way (fixing Cygwin) to
success.
The RPC-client on my pc is started every few minutes and has to connect to the
RPC-server. Without the fix libtirpc is not usable and I have to use Cygwin
1.5.18 with the old librpc.
[...]
Hi Raimund,
Thanks for attaching the complete source for your modified bindresvport.c. I
had been treating your setting of port to 0 as a workaround rather than as a
solution. My misunderstanding.
We can't solve the issue that way because when bind() is called with a zeroed
port number, it picks a random port number that's often outside the range of
ports bindresvport() is supposed to return (i.e., a port between STARTPORT and
ENDPORT).
I thought of something similar to your idea but obeying the bindresvport()
semantics. I add a static short value named 'usecount' to the function's local
variables. Mid-function, I have this code to choose a port number:
if (port == 0) {
port = ((getpid() + usecount++) % NPORTS) + STARTPORT;
}
Can you try this with your testcase(s) and make sure it works for you?
..mark
--
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
