Re: rcs configure hang

[Florian Weimer]

* Kelly Wang:

> Hi Florian,
>
> Thanks for checking. Here is my system info:
> % uname -a
> Linux sjc-ads-7913 4.18.0-147.3.1.el8_1.x86_64 #1 SMP Wed Nov 27 01:11:44 UTC 
> 2019 x86_64 unknown unknown GNU/Linux
> % rpm -q kernel
> kernel-4.18.0-80.el8.x86_64
> kernel-4.18.0-147.3.1.el8_1.x86_64
>
> This is virtualization system.

What's the hypervisor?

(It may also be worthwhile to try with a more recent .el8 kernel.)

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Thien,

Thanks for follow up. Here is my reply on 11/10/2020.

Thanks for checking. Here is my system info:
% uname -a
Linux sjc-ads-7913 4.18.0-147.3.1.el8_1.x86_64 #1 SMP Wed Nov 27 01:11:44 UTC 
2019 x86_64 unknown unknown GNU/Linux
% rpm -q kernel
kernel-4.18.0-80.el8.x86_64
kernel-4.18.0-147.3.1.el8_1.x86_64

This is virtualization system.

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 1/10/21, 2:07 PM, "Thien-Thi Nguyen"  wrote:


() Florian Weimer 
() Mon, 09 Nov 2020 10:14:00 +0100

   Would you be able to share details of the file system used
   (XFS or something else?) and the kernel version (uname -a,
   rpm -q kernel)?

   Do you use virtualization or containers?

   I would like to see if I can reproduce it internally.

Ping.  (Any news?)

-- 
Thien-Thi Nguyen ---
 (defun responsep (query)   ; (2021) Software Libero
   (pcase (context query)   ;   = Dissenso Etico
 (`(technical ,ml) (correctp ml))
 ...))  748E A0E8 1CB8 A748 9BFA
--- 6CE4 6703 2224 4C80 7502

Re: rcs configure hang

[Thien-Thi Nguyen]

() Florian Weimer 
() Mon, 09 Nov 2020 10:14:00 +0100

   Would you be able to share details of the file system used
   (XFS or something else?) and the kernel version (uname -a,
   rpm -q kernel)?

   Do you use virtualization or containers?

   I would like to see if I can reproduce it internally.

Ping.  (Any news?)

-- 
Thien-Thi Nguyen ---
 (defun responsep (query)   ; (2021) Software Libero
   (pcase (context query)   ;   = Dissenso Etico
 (`(technical ,ml) (correctp ml))
 ...))  748E A0E8 1CB8 A748 9BFA
--- 6CE4 6703 2224 4C80 7502



signature.asc
Description: PGP signature

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Florian,

Thanks for checking. Here is my system info:
% uname -a
Linux sjc-ads-7913 4.18.0-147.3.1.el8_1.x86_64 #1 SMP Wed Nov 27 01:11:44 UTC 
2019 x86_64 unknown unknown GNU/Linux
% rpm -q kernel
kernel-4.18.0-80.el8.x86_64
kernel-4.18.0-147.3.1.el8_1.x86_64

This is virtualization system.

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 11/9/20, 1:14 AM, "Florian Weimer"  wrote:

* Kelly Wang:

> You are right, after remove confdir3, rerun strace hang.
> Checked tr output, it stopped at bunch of mkdir and chdir and no further 
steps after that.
> mkdir("confdir3", 0700) = 0
> chdir("confdir3")   = 0

Would you be able to share details of the file system used (XFS or
something else?) and the kernel version (uname -a, rpm -q kernel)?

Do you use virtualization or containers?

I would like to see if I can reproduce it internally.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Paul,

With ./configure gl_cv_func_getcwd_path_max=no, the step passed without hanging.
I was able to get rcs configure, make and installed. 
Just need to verify if 5.10.0 fix ci/co problem among our team.

I don't think we have conversation for GNU tar before and the rhel8 server that 
I am building rcs base on is a new system.
Thanks so much for all your help!

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 11/6/20, 9:41 AM, "Paul Eggert"  wrote:

On 11/6/20 8:20 AM, Kelly Wang (kellythw) wrote:
> Is server issue? should I change to other rhel8 server and try the same?

It does sound like some sort of server or filesystem problem, yes. The 
mkdir 
syscall does not finish and refuses to be interrupted. I don't see any way 
to 
modify Gnulib to work around the problem automatically. However, you should 
be 
able to sidestep the problem with something either like this:

./configure gl_cv_func_getcwd_path_max=no

or like this:

./configure gl_cv_func_getcwd_path_max=yes

It's not clear to me which of these workarounds would be better for your 
system.


Didn't we have this same conversation a year ago, with GNU tar, which uses 
the 
same Gnulib module? Are you building now on the same system you used a year 
ago?

https://lists.gnu.org/r/bug-tar/2019-10/msg1.html
https://lists.gnu.org/r/bug-tar/2019-10/msg2.html
https://lists.gnu.org/r/bug-tar/2019-10/msg3.html


Reviewing that earlier conversation prompts me to ask: are you building on 
a 
Samba filesystem? There seems to be a problem in this area that is 
reportedly 
fixed by upgrading to a newer version of Samba, or by fiddling with Samba 
settings (not clear). See:

https://www.cs.rug.nl/~jurjen/ApprenticesNotes/tstcg_tar.html

which is part of:


https://www.cs.rug.nl/~jurjen/ApprenticesNotes/testing_samba_to_compilation_grade.html

Re: rcs configure hang

[Paul Eggert]

On 11/6/20 8:20 AM, Kelly Wang (kellythw) wrote:

Is server issue? should I change to other rhel8 server and try the same?


It does sound like some sort of server or filesystem problem, yes. The mkdir 
syscall does not finish and refuses to be interrupted. I don't see any way to 
modify Gnulib to work around the problem automatically. However, you should be 
able to sidestep the problem with something either like this:


./configure gl_cv_func_getcwd_path_max=no

or like this:

./configure gl_cv_func_getcwd_path_max=yes

It's not clear to me which of these workarounds would be better for your system.


Didn't we have this same conversation a year ago, with GNU tar, which uses the 
same Gnulib module? Are you building now on the same system you used a year ago?


https://lists.gnu.org/r/bug-tar/2019-10/msg1.html
https://lists.gnu.org/r/bug-tar/2019-10/msg2.html
https://lists.gnu.org/r/bug-tar/2019-10/msg3.html


Reviewing that earlier conversation prompts me to ask: are you building on a 
Samba filesystem? There seems to be a problem in this area that is reportedly 
fixed by upgrading to a newer version of Samba, or by fiddling with Samba 
settings (not clear). See:


https://www.cs.rug.nl/~jurjen/ApprenticesNotes/tstcg_tar.html

which is part of:

https://www.cs.rug.nl/~jurjen/ApprenticesNotes/testing_samba_to_compilation_grade.html

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Paul,

With kill -14 91418, I don't see any output add to tr.
% ps -elf | grep strace
0 S kellythw480  1  0  80   0 - 58957 -  Nov05 ?00:00:00 
strace -o tr ./a.out
0 S kellythw   3760  1  0  80   0 - 58957 -  Nov05 ?00:00:00 
strace -o tr ./a.out
0 S kellythw  15709  1  0  80   0 - 58957 -  Nov05 ?00:00:00 
strace -o tr ./a.out
0 S kellythw  93336  91418  0  80   0 - 58957 -  08:14 pts/900:00:00 
strace -o tr ./a.out

% tail tr
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700

Is server issue? should I change to other rhel8 server and try the same?

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 11/5/20, 2:52 PM, "Paul Eggert"  wrote:

On 11/5/20 2:28 PM, Kelly Wang (kellythw) wrote:
> When strace hang, I do 'ps -elf | grep strace' from other terminal and do 
kill -9 
> kill -s INT $(ps -o pid= -C a.out) looks like not working from my server.

Assuming you're using the Linux kernel signal numbers, you should be able 
to get 
a process ID (say, 4729) and use this:

kill -2 4729

instead of the fancier 'kill' command I suggested. Also, try this in 
another 
session:

kill -14 4729

which sends the ALRM signal instead of the INT signal. Either way, see what 
'tr' 
says.

Re: rcs configure hang

[Paul Eggert]

On 11/5/20 2:28 PM, Kelly Wang (kellythw) wrote:

When strace hang, I do 'ps -elf | grep strace' from other terminal and do kill -9 

kill -s INT $(ps -o pid= -C a.out) looks like not working from my server.


Assuming you're using the Linux kernel signal numbers, you should be able to get 
a process ID (say, 4729) and use this:


kill -2 4729

instead of the fancier 'kill' command I suggested. Also, try this in another 
session:


kill -14 4729

which sends the ALRM signal instead of the INT signal. Either way, see what 'tr' 
says.

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Paul,

When strace hang, I do 'ps -elf | grep strace' from other terminal and do kill 
-9 
kill -s INT $(ps -o pid= -C a.out) looks like not working from my server.

% kill -s INT $(ps -o pid= -C a.out)
Illegal variable name.

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 11/5/20, 1:36 PM, "Paul Eggert"  wrote:

On 11/5/20 1:18 PM, Kelly Wang (kellythw) wrote:
> With the conftest.c you provided, strace still hang.
> Check for how many calls for chdir("confdir3"), it only has 110 times, 
then hang after mkdir("confdir3", 0700 ...
> Is there any directory limitation that can make on a server?

Wow, that's a more-serious kernel (or filesystem) bug than I thought: the 
mkdir 
system call is hanging and does not appear to be interruptible via SIGALRM.

When the program hangs, how do you terminate it? Do you use Control-C from 
a 
terminal? If so, what happens if you instead use 'kill'? Something like 
this:

rm -fr conftest3
gcc conftest.c
strace -o tr ./a.out &
sleep 1
kill -s INT $(ps -o pid= -C a.out)

That last line should send the SIGINT signal to the a.out command; does 
this 
cause a.out to exit? (You can look at 'tr' to see.) If it exits, perhaps we 
can 
modify conftest3 to do the same thing to itself when it is running on a 
buggy 
kernel.

Also, what happens if you do the same recipe as above, but use 'ALRM' 
rather 
than 'INT'? Again, look at the end of 'tr'.

Re: rcs configure hang

[Paul Eggert]

On 11/5/20 1:18 PM, Kelly Wang (kellythw) wrote:

With the conftest.c you provided, strace still hang.
Check for how many calls for chdir("confdir3"), it only has 110 times, then hang after 
mkdir("confdir3", 0700 ...
Is there any directory limitation that can make on a server?


Wow, that's a more-serious kernel (or filesystem) bug than I thought: the mkdir 
system call is hanging and does not appear to be interruptible via SIGALRM.


When the program hangs, how do you terminate it? Do you use Control-C from a 
terminal? If so, what happens if you instead use 'kill'? Something like this:


rm -fr conftest3
gcc conftest.c
strace -o tr ./a.out &
sleep 1
kill -s INT $(ps -o pid= -C a.out)

That last line should send the SIGINT signal to the a.out command; does this 
cause a.out to exit? (You can look at 'tr' to see.) If it exits, perhaps we can 
modify conftest3 to do the same thing to itself when it is running on a buggy 
kernel.


Also, what happens if you do the same recipe as above, but use 'ALRM' rather 
than 'INT'? Again, look at the end of 'tr'.

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Paul,

With the conftest.c you provided, strace still hang.
Check for how many calls for chdir("confdir3"), it only has 110 times, then 
hang after mkdir("confdir3", 0700 ...
Is there any directory limitation that can make on a server?
  
sjc-ads-7913:/ws/kellythw-sjc/rcs_try/getcwd-test% tail tr
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0
mkdir("confdir3", 0700

% grep 'chdir("confdir3")' tr | wc -l
110

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 11/5/20, 9:57 AM, "Paul Eggert"  wrote:

On 10/27/20 8:36 AM, Kelly Wang (kellythw) wrote:
> You are right, after remove confdir3, rerun strace hang.
> Checked tr output, it stopped at bunch of mkdir and chdir and no further 
steps after that.
> mkdir("confdir3", 0700) = 0
> chdir("confdir3")   = 0

How many chdir("confdir3") calls were there, exactly? On my platform there 
were 
1367.

My guess is that the getcwd system call hung on your platform, which 
suggests a 
kernel or filesystem bug somewhere.

What happens if you run the attached conftest.c instead? It's the same as 
before, except with an 'alarm (10)' call. As before, run it like this in 
your 
development directory:

rm -fr conftest3
gcc conftest.c
strace -o tr ./a.out

and see how 'tr' ends if it hangs (which I hope it doesn't).

Re: rcs configure hang

[Paul Eggert]

On 10/27/20 8:36 AM, Kelly Wang (kellythw) wrote:

You are right, after remove confdir3, rerun strace hang.
Checked tr output, it stopped at bunch of mkdir and chdir and no further steps 
after that.
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0


How many chdir("confdir3") calls were there, exactly? On my platform there were 
1367.


My guess is that the getcwd system call hung on your platform, which suggests a 
kernel or filesystem bug somewhere.


What happens if you run the attached conftest.c instead? It's the same as 
before, except with an 'alarm (10)' call. As before, run it like this in your 
development directory:


rm -fr conftest3
gcc conftest.c
strace -o tr ./a.out

and see how 'tr' ends if it hangs (which I hope it doesn't).
/* confdefs.h */
#define PACKAGE_NAME "dummy"
#define PACKAGE_TARNAME "dummy"
#define PACKAGE_VERSION "0"
#define PACKAGE_STRING "dummy 0"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define PACKAGE "dummy"
#define VERSION "0"
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define __EXTENSIONS__ 1
#define _ALL_SOURCE 1
#define _DARWIN_C_SOURCE 1
#define _GNU_SOURCE 1
#define _NETBSD_SOURCE 1
#define _OPENBSD_SOURCE 1
#define _POSIX_PTHREAD_SEMANTICS 1
#define __STDC_WANT_IEC_60559_ATTRIBS_EXT__ 1
#define __STDC_WANT_IEC_60559_BFP_EXT__ 1
#define __STDC_WANT_IEC_60559_DFP_EXT__ 1
#define __STDC_WANT_IEC_60559_FUNCS_EXT__ 1
#define __STDC_WANT_IEC_60559_TYPES_EXT__ 1
#define __STDC_WANT_LIB_EXT2__ 1
#define __STDC_WANT_MATH_SPEC_FUNCS__ 1
#define _TANDEM_SOURCE 1
#define _HPUX_ALT_XOPEN_SOCKET_API 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_ARPA_INET_H 1
#define HAVE_FEATURES_H 1
#define HAVE_UNISTD_H 1
#define HAVE_SYS_PARAM_H 1
#define HAVE_DIRENT_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_NETDB_H 1
#define HAVE_NETINET_IN_H 1
#define HAVE_LIMITS_H 1
#define HAVE_WCHAR_H 1
#define HAVE_STDINT_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_THREADS_H 1
#define HAVE_SYS_MMAN_H 1
#define HAVE_SYS_SELECT_H 1
#define HAVE_PTHREAD_H 1
#define HAVE_SYS_CDEFS_H 1
#define HAVE_SYS_IOCTL_H 1
#define HAVE_SYS_UIO_H 1
#define restrict __restrict
#define HAVE_SHUTDOWN 1
#define HAVE_STRUCT_SOCKADDR_STORAGE 1
#define HAVE_SA_FAMILY_T 1
#define HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY 1
#define HAVE_ALLOCA_H 1
#define HAVE_ALLOCA 1
#define HAVE_FCHDIR 1
#define HAVE_FCNTL 1
#define HAVE_SYMLINK 1
#define HAVE_FDOPENDIR 1
#define HAVE_MEMPCPY 1
#define HAVE_FSTATAT 1
#define HAVE_FTRUNCATE 1
#define HAVE_GETDTABLESIZE 1
#define HAVE_GETTIMEOFDAY 1
#define HAVE_ISBLANK 1
#define HAVE_LSTAT 1
#define HAVE_MPROTECT 1
#define HAVE_OPENAT 1
#define HAVE_STRERROR_R 1
#define HAVE___XPG_STRERROR_R 1
#define HAVE_PIPE 1
#define HAVE_SIGACTION 1
#define HAVE_SIGALTSTACK 1
#define HAVE_SIGINTERRUPT 1
#define HAVE_SLEEP 1
#define HAVE_CATGETS 1
#define HAVE_SNPRINTF 1
#define HAVE_USLEEP 1
#define HAVE_ENVIRON_DECL 1
#define HAVE_DECL_STRERROR_R 1
#define HAVE_STRERROR_R 1
#define STRERROR_R_CHAR_P 1
#define HAVE_DECL_FCHDIR 1
#define HAVE_WORKING_O_NOATIME 1
#define HAVE_WORKING_O_NOFOLLOW 1
#define LSTAT_FOLLOWS_SLASHED_SYMLINK 1
#define HAVE_DECL_GETCWD 1
#define HAVE_DECL_GETDTABLESIZE 1
#define HAVE_IPV4 1
#define HAVE_IPV6 1
#define HAVE_WINT_T 1
#define HAVE_LONG_LONG_INT 1
#define HAVE_UNSIGNED_LONG_LONG_INT 1
#define HAVE_WEAK_SYMBOLS 1
#define HAVE_PTHREAD_API 1
#define USE_POSIX_THREADS 1
#define USE_POSIX_THREADS_WEAK 1
#define MALLOC_0_IS_NONNULL 1
#define HAVE_MAP_ANONYMOUS 1
#define HAVE_DECL_MEMRCHR 1
#define HAVE_DECL_ALARM 1
#define PROMOTED_MODE_T mode_t
#define HAVE_DECL_STRERROR_R 1
#define HAVE_SIGSET_T 1
#define HAVE__BOOL 1
#define HAVE_WCHAR_T 1
#define HAVE_DECL_STRDUP 1
#define _USE_STD_STAT 1
#define HAVE_DECL_UNSETENV 1
#define GNULIB_TEST_ACCEPT 1
#define HAVE_ALLOCA 1
#define GNULIB_TEST_BIND 1
#define GNULIB_TEST_CHDIR 1
#define GNULIB_TEST_CLOEXEC 1
#define GNULIB_TEST_CLOSE 1
#define HAVE_CLOSEDIR 1
#define GNULIB_TEST_CLOSEDIR 1
#define GNULIB_TEST_CONNECT 1
#define D_INO_IN_DIRENT 1
#define HAVE_DIRFD 1
#define HAVE_DECL_DIRFD 1
#define GNULIB_TEST_DIRFD 1
#define GNULIB_TEST_DUP 1
#define GNULIB_TEST_DUP2 1
#define GNULIB_TEST_ENVIRON 1
#define GNULIB_TEST_FCHDIR 1
#define GNULIB_TEST_FCNTL 1
#define GNULIB_FD_SAFER_FLAG 1
#define GNULIB_TEST_FDOPEN 1
#define HAVE_DECL_FDOPENDIR 1
#define GNULIB_TEST_FDOPENDIR 1
#define GNULIB_FDOPENDIR 1
#define GNULIB_TEST_FSTAT 1
#define GNULIB_TEST_FSTATAT 1
#define GNULIB_TEST_FTRUNCATE 1
/* end confdefs.h.  */

#include 
#include 
#if HAVE_UNISTD_H
# include 
#else
# include 
#endif
#include 
#include 
#include 
#include 
#include 


/* Arrange to define PATH_MAX, like "pathmax.h" does. */
#if HAVE_UNISTD_H
# include 
#endif
#include 
#if defined 

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Paul or gnulib guru,

Can you share any thought for the configure hanging problem while configure rcs?

+ ./configure

checking whether fcntl handles F_DUPFD correctly... yes
checking whether fcntl understands F_DUPFD_CLOEXEC... needs runtime check
checking whether conversion from 'int' to 'long double' works... yes
checking whether getcwd handles long file names properly...

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 10/27/20, 8:36 AM, "Kelly Wang (kellythw)"  wrote:

Hi Paul,

You are right, after remove confdir3, rerun strace hang.
Checked tr output, it stopped at bunch of mkdir and chdir and no further 
steps after that.
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0

Thanks,
Kelly

If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools


On 10/26/20, 3:56 PM, "Paul Eggert"  wrote:

On 10/26/20 9:13 AM, Kelly Wang (kellythw) wrote:

> [Kelly] strace step is not hang and I have tr generated.

Looking at the tr file, it appears that there was already a directory 
confdir3 
when you ran the strace step, and this directory messed up the test. 
Please 
remove that directory (or rename it) and then re-run the "strace -o tr 
./a.out". 
As before, the strace should also hang so you may need to type 
control-C to exit 
it after a while. Look at the resulting 'tr' file and compare it to the 
compressed file tr.gz I sent you earlier.

> [Kelly] The difference of tr output start at:
> 
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", 
O_RDONLY|O_CLOEXEC) = 3  ==> output from yours
> 
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3  ==> my 
output

That difference is unimportant. I'm concerned more about what happens 
after the 
long string of mkdir/chdir calls, which should occur once you get 
confdir3 out 
of the way.

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Paul,

You are right, after remove confdir3, rerun strace hang.
Checked tr output, it stopped at bunch of mkdir and chdir and no further steps 
after that.
mkdir("confdir3", 0700) = 0
chdir("confdir3")   = 0

Thanks,
Kelly
 
If you need support for DevX Tools:   http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
 

On 10/26/20, 3:56 PM, "Paul Eggert"  wrote:

On 10/26/20 9:13 AM, Kelly Wang (kellythw) wrote:

> [Kelly] strace step is not hang and I have tr generated.

Looking at the tr file, it appears that there was already a directory 
confdir3 
when you ran the strace step, and this directory messed up the test. Please 
remove that directory (or rename it) and then re-run the "strace -o tr 
./a.out". 
As before, the strace should also hang so you may need to type control-C to 
exit 
it after a while. Look at the resulting 'tr' file and compare it to the 
compressed file tr.gz I sent you earlier.

> [Kelly] The difference of tr output start at:
> 
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 
3  ==> output from yours
> 
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3  ==> my 
output

That difference is unimportant. I'm concerned more about what happens after 
the 
long string of mkdir/chdir calls, which should occur once you get confdir3 
out 
of the way.



tr
Description: tr

Re: rcs configure hang

[Paul Eggert]

On 10/26/20 9:13 AM, Kelly Wang (kellythw) wrote:


[Kelly] strace step is not hang and I have tr generated.


Looking at the tr file, it appears that there was already a directory confdir3 
when you ran the strace step, and this directory messed up the test. Please 
remove that directory (or rename it) and then re-run the "strace -o tr ./a.out". 
As before, the strace should also hang so you may need to type control-C to exit 
it after a while. Look at the resulting 'tr' file and compare it to the 
compressed file tr.gz I sent you earlier.



[Kelly] The difference of tr output start at:

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3  
==> output from yours

openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3  ==> my output


That difference is unimportant. I'm concerned more about what happens after the 
long string of mkdir/chdir calls, which should occur once you get confdir3 out 
of the way.

Re: rcs configure hang

[Kelly Wang (kellythw)]

Hi Paul,



Sorry for late reply and thank you so much for checking into the problem.

Comments added below.



Thanks,

Kelly

If you need support for DevX Tools:   http://devxsupport.cisco.com/

Specifically, for NXOS, see -

https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools



On 10/22/20, 3:04 PM, "Paul Eggert"  wrote:



On 10/21/20 7:36 AM, Thien-Thi Nguyen wrote:

> "Kelly Wang (kellythw)"  


> I download rcs 5.10.0, untarred and try to run ./configure.

> However it is hang in 'checking whether getcwd handles long

> file names properly...' for more than 30+ min and still hang.



> This is from ‘gl_FUNC_GETCWD_PATH_MAX’ in m4/getcwd-path-max.m4.

> IIUC, the test tries to create a filename up to, and then a bit

> longer than, PATH_MAX in length.  It does this in a ‘while (1)’

> loop, relying on ‘break’ to exit the loop.  Perhaps this is a C

> compiler problem?



I'd guess that it's due to thrashing, e.g., there's a huge PATH_MAX or 
something

like that. At any rate, it's surely a Gnulib problem rather than an RCS 
problem

so I'll cc. this to bug-gnulib.



Kelly, I created the attached tarball getcwd-test.tar.gz by running

'./gnulib-tool --create-testdir --dir getcwd-test getcwd' in the Gnulib 
source

directory. Please try:



tar xf getcwd-test.tar.gz

cd getcwd-test

./configure

[Kelly] yes, it hanged in the similar way as rcs.



make check



in the same filesystem where you tried and failed to build RCS. If it hangs 
in a

similar way while running 'configure', it's a Gnulib problem. If it succeeds

then something odd is going on and it may be either a Gnulib or RCS problem.



Assuming it hangs, leave it hanging but look at the working directory. You

should see a file conftest.c that looks like the attached separate file. 
Let us

know of any differences between your conftest.c and the attached one. Also, 
try

the following commands:



gcc conftest.c

strace -o tr ./a.out



The strace should also hang so you may need to type control-C to exit it 
after a

while. Look at the resulting 'tr' file and compare it to the attached 
compressed

file tr.gz. Where does yours start acting differently? That will help us 
figure

out the bug.



[Kelly] strace step is not hang and I have tr generated.

[Kelly] The difference of tr output start at:

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3  
==> output from yours

openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3  ==> my output

I attached a.out and tz, so is that mean the lib file that my machine used has 
problem?






a.out
Description: a.out


tr
Description: tr