* Re: rcs configure hang
[not found] ` <873627odbp.fsf@gnuvola.org>
@ 2020-10-22 22:02 ` Paul Eggert
2020-10-26 16:13 ` Kelly Wang (kellythw)
0 siblings, 1 reply; 18+ messages in thread
From: Paul Eggert @ 2020-10-22 22:02 UTC (permalink / raw)
To: Thien-Thi Nguyen, Kelly Wang (kellythw)
Cc: Gnulib bugs, Srini Garlapalli (sgarlapa), bug-rcs@gnu.org
[-- Attachment #1.1.1: Type: text/plain, Size: 1918 bytes --]
On 10/21/20 7:36 AM, Thien-Thi Nguyen wrote:
> "Kelly Wang (kellythw)" <kellythw@cisco.com> <https://lists.gnu.org/r/bug-rcs/2020-10/msg00018.html>
> 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
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.
[-- Attachment #1.1.2: getcwd-test.tar.gz --]
[-- Type: application/gzip, Size: 873284 bytes --]
[-- Attachment #1.1.3: conftest.c --]
[-- Type: text/x-csrc, Size: 10889 bytes --]
/* 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 <errno.h>
#include <stdlib.h>
#if HAVE_UNISTD_H
# include <unistd.h>
#else
# include <direct.h>
#endif
#include <string.h>
#include <limits.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
/* Arrange to define PATH_MAX, like "pathmax.h" does. */
#if HAVE_UNISTD_H
# include <unistd.h>
#endif
#include <limits.h>
#if defined HAVE_SYS_PARAM_H && !defined PATH_MAX && !defined MAXPATHLEN
# include <sys/param.h>
#endif
#if !defined PATH_MAX && defined MAXPATHLEN
# define PATH_MAX MAXPATHLEN
#endif
#ifdef __hpux
# undef PATH_MAX
# define PATH_MAX 1024
#endif
#if defined _WIN32 && ! defined __CYGWIN__
# undef PATH_MAX
# define PATH_MAX 260
#endif
#ifndef AT_FDCWD
# define AT_FDCWD 0
#endif
#ifdef ENAMETOOLONG
# define is_ENAMETOOLONG(x) ((x) == ENAMETOOLONG)
#else
# define is_ENAMETOOLONG(x) 0
#endif
/* Use the getcwd function, not any macro. */
#undef getcwd
#if defined _WIN32 && !defined __CYGWIN__
#define access _access
#define chdir _chdir
#define chmod _chmod
#define close _close
#define creat _creat
#define dup _dup
#define dup2 _dup2
#define ecvt _ecvt
#define execl _execl
#define execle _execle
#define execlp _execlp
#define execv _execv
#define execve _execve
#define execvp _execvp
#define execvpe _execvpe
#define fcloseall _fcloseall
#define fcvt _fcvt
#define fdopen _fdopen
#define fileno _fileno
#define gcvt _gcvt
#define getcwd _getcwd
#define getpid _getpid
#define getw _getw
#define isatty _isatty
#define j0 _j0
#define j1 _j1
#define jn _jn
#define lfind _lfind
#define lsearch _lsearch
#define lseek _lseek
#define memccpy _memccpy
#define mkdir _mkdir
#define mktemp _mktemp
#define open _open
#define putenv _putenv
#define putw _putw
#define read _read
#define rmdir _rmdir
#define strdup _strdup
#define swab _swab
#define tempnam _tempnam
#define tzset _tzset
#define umask _umask
#define unlink _unlink
#define utime _utime
#define wcsdup _wcsdup
#define write _write
#define y0 _y0
#define y1 _y1
#define yn _yn
#endif
#ifndef S_IRWXU
# define S_IRWXU 0700
#endif
/* The length of this name must be 8. */
#define DIR_NAME "confdir3"
#define DIR_NAME_LEN 8
#define DIR_NAME_SIZE (DIR_NAME_LEN + 1)
/* The length of "../". */
#define DOTDOTSLASH_LEN 3
/* Leftover bytes in the buffer, to work around library or OS bugs. */
#define BUF_SLOP 20
int
main ()
{
#ifndef PATH_MAX
/* The Hurd doesn't define this, so getcwd can't exhibit the bug --
at least not on a local file system. And if we were to start worrying
about remote file systems, we'd have to enable the wrapper function
all of the time, just to be safe. That's not worth the cost. */
exit (0);
#elif ((INT_MAX / (DIR_NAME_SIZE / DOTDOTSLASH_LEN + 1) - DIR_NAME_SIZE - BUF_SLOP) <= PATH_MAX)
/* FIXME: Assuming there's a system for which this is true,
this should be done in a compile test. */
exit (0);
#else
char buf[PATH_MAX * (DIR_NAME_SIZE / DOTDOTSLASH_LEN + 1)
+ DIR_NAME_SIZE + BUF_SLOP];
char *cwd = getcwd (buf, PATH_MAX);
size_t initial_cwd_len;
size_t cwd_len;
int fail = 0;
size_t n_chdirs = 0;
if (cwd == NULL)
exit (10);
cwd_len = initial_cwd_len = strlen (cwd);
while (1)
{
size_t dotdot_max = PATH_MAX * (DIR_NAME_SIZE / DOTDOTSLASH_LEN);
char *c = NULL;
cwd_len += DIR_NAME_SIZE;
/* If mkdir or chdir fails, it could be that this system cannot create
any file with an absolute name longer than PATH_MAX, such as cygwin.
If so, leave fail as 0, because the current working directory can't
be too long for getcwd if it can't even be created. On Linux with
the 9p file system, mkdir fails with error EINVAL when cwd_len gets
too long; ignore this failure because the getcwd() system call
produces good results whereas the gnulib substitute calls getdents64
which fails with error EPROTO.
For other errors, be pessimistic and consider that as a failure,
too. */
if (mkdir (DIR_NAME, S_IRWXU) < 0 || chdir (DIR_NAME) < 0)
{
if (! (errno == ERANGE || is_ENAMETOOLONG (errno)))
#ifdef __linux__
if (! (errno == EINVAL))
#endif
fail = 20;
break;
}
if (PATH_MAX <= cwd_len && cwd_len < PATH_MAX + DIR_NAME_SIZE)
{
struct stat sb;
c = getcwd (buf, PATH_MAX);
if (!c && errno == ENOENT)
{
fail = 11;
break;
}
if (c)
{
fail = 31;
break;
}
if (! (errno == ERANGE || is_ENAMETOOLONG (errno)))
{
fail = 21;
break;
}
/* Our replacement needs to be able to stat() long ../../paths,
so generate a path larger than PATH_MAX to check,
avoiding the replacement if we can't stat(). */
c = getcwd (buf, cwd_len + 1);
if (c && !AT_FDCWD && stat (c, &sb) != 0 && is_ENAMETOOLONG (errno))
{
fail = 32;
break;
}
}
if (dotdot_max <= cwd_len - initial_cwd_len)
{
if (dotdot_max + DIR_NAME_SIZE < cwd_len - initial_cwd_len)
break;
c = getcwd (buf, cwd_len + 1);
if (!c)
{
if (! (errno == ERANGE || errno == ENOENT
|| is_ENAMETOOLONG (errno)))
{
fail = 22;
break;
}
if (AT_FDCWD || errno == ERANGE || errno == ENOENT)
{
fail = 12;
break;
}
}
}
if (c && strlen (c) != cwd_len)
{
fail = 23;
break;
}
++n_chdirs;
}
/* Leaving behind such a deep directory is not polite.
So clean up here, right away, even though the driving
shell script would also clean up. */
{
size_t i;
/* Try rmdir first, in case the chdir failed. */
rmdir (DIR_NAME);
for (i = 0; i <= n_chdirs; i++)
{
if (chdir ("..") < 0)
break;
if (rmdir (DIR_NAME) != 0)
break;
}
}
exit (fail);
#endif
}
[-- Attachment #1.1.4: tr.gz --]
[-- Type: application/gzip, Size: 8861 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-10-22 22:02 ` rcs configure hang Paul Eggert
@ 2020-10-26 16:13 ` Kelly Wang (kellythw)
2020-10-26 22:55 ` Paul Eggert
0 siblings, 1 reply; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-10-26 16:13 UTC (permalink / raw)
To: Paul Eggert, Thien-Thi Nguyen
Cc: Srini Garlapalli (sgarlapa), bug-rcs@gnu.org, Gnulib bugs,
Kelly Wang (kellythw), Yi Yan (yyan)
[-- Attachment #1.1: Type: text/plain, Size: 2958 bytes --]
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" <eggert@cs.ucla.edu> wrote:
On 10/21/20 7:36 AM, Thien-Thi Nguyen wrote:
> "Kelly Wang (kellythw)" <kellythw@cisco.com> <https://lists.gnu.org/r/bug-rcs/2020-10/msg00018.html>
> 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?
[-- Attachment #1.2: Type: text/html, Size: 8350 bytes --]
[-- Attachment #2: a.out --]
[-- Type: application/octet-stream, Size: 16936 bytes --]
[-- Attachment #3: tr --]
[-- Type: application/octet-stream, Size: 1835 bytes --]
execve("./a.out", ["./a.out"], 0x7ffddfab4000 /* 46 vars */) = 0
brk(NULL) = 0x18b0000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffdbac098c0) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=211534, ...}) = 0
mmap(NULL, 211534, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f73b6e6a000
close(3) = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2009\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=5993088, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f73b6e68000
mmap(NULL, 3942432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f73b68b3000
mprotect(0x7f73b6a6c000, 2097152, PROT_NONE) = 0
mmap(0x7f73b6c6c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b9000) = 0x7f73b6c6c000
mmap(0x7f73b6c72000, 14368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f73b6c72000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7f73b6e69500) = 0
mprotect(0x7f73b6c6c000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ) = 0
mprotect(0x7f73b6e9e000, 4096, PROT_READ) = 0
munmap(0x7f73b6e6a000, 211534) = 0
getcwd("/ws/kellythw-sjc/rcs_try/getcwd-test", 4096) = 37
mkdir("confdir3", 0700) = -1 EEXIST (File exists)
rmdir("confdir3") = -1 ENOTEMPTY (Directory not empty)
chdir("..") = 0
rmdir("confdir3") = -1 ENOENT (No such file or directory)
exit_group(20) = ?
+++ exited with 20 +++
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-10-26 16:13 ` Kelly Wang (kellythw)
@ 2020-10-26 22:55 ` Paul Eggert
2020-10-27 15:36 ` Kelly Wang (kellythw)
0 siblings, 1 reply; 18+ messages in thread
From: Paul Eggert @ 2020-10-26 22:55 UTC (permalink / raw)
To: Kelly Wang (kellythw), Thien-Thi Nguyen
Cc: Gnulib bugs, Srini Garlapalli (sgarlapa), bug-rcs@gnu.org,
Yi Yan (yyan)
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-10-26 22:55 ` Paul Eggert
@ 2020-10-27 15:36 ` Kelly Wang (kellythw)
2020-11-05 16:11 ` Kelly Wang (kellythw)
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-10-27 15:36 UTC (permalink / raw)
To: Paul Eggert, Thien-Thi Nguyen
Cc: Srini Garlapalli (sgarlapa), bug-rcs@gnu.org, Gnulib bugs,
Yi Yan (yyan), Kelly Wang (kellythw)
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
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" <eggert@cs.ucla.edu> 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.
[-- Attachment #2: tr --]
[-- Type: application/octet-stream, Size: 11203 bytes --]
execve("./a.out", ["./a.out"], 0x7ffc9b846850 /* 44 vars */) = 0
brk(NULL) = 0x207d000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffc4ee19630) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=211534, ...}) = 0
mmap(NULL, 211534, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f005ae67000
close(3) = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2009\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=5993088, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f005ae65000
mmap(NULL, 3942432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f005a8b0000
mprotect(0x7f005aa69000, 2097152, PROT_NONE) = 0
mmap(0x7f005ac69000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b9000) = 0x7f005ac69000
mmap(0x7f005ac6f000, 14368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f005ac6f000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7f005ae66500) = 0
mprotect(0x7f005ac69000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ) = 0
mprotect(0x7f005ae9b000, 4096, PROT_READ) = 0
munmap(0x7f005ae67000, 211534) = 0
getcwd("/ws/kellythw-sjc/rcs_try/getcwd-test", 4096) = 37
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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 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) = 0
chdir("confdir3") = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3") = 0
mkdir("confdir3", 0700
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-10-27 15:36 ` Kelly Wang (kellythw)
@ 2020-11-05 16:11 ` Kelly Wang (kellythw)
2020-11-05 17:57 ` Paul Eggert
2020-11-09 9:14 ` Florian Weimer
2 siblings, 0 replies; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-11-05 16:11 UTC (permalink / raw)
To: Paul Eggert, Thien-Thi Nguyen
Cc: Srini Garlapalli (sgarlapa), bug-rcs@gnu.org, Gnulib bugs,
Yi Yan (yyan), Kelly Wang (kellythw)
Hi Paul or gnulib guru,
Can you share any thought for the configure hanging problem while configure rcs?
+ ./configure
<snip>
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)" <kellythw@cisco.com> 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" <eggert@cs.ucla.edu> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-10-27 15:36 ` Kelly Wang (kellythw)
2020-11-05 16:11 ` Kelly Wang (kellythw)
@ 2020-11-05 17:57 ` Paul Eggert
2020-11-05 21:18 ` Kelly Wang (kellythw)
2020-11-09 9:14 ` Florian Weimer
2 siblings, 1 reply; 18+ messages in thread
From: Paul Eggert @ 2020-11-05 17:57 UTC (permalink / raw)
To: Kelly Wang (kellythw), Thien-Thi Nguyen
Cc: Gnulib bugs, Srini Garlapalli (sgarlapa), bug-rcs@gnu.org,
Yi Yan (yyan)
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
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).
[-- Attachment #2: conftest.c --]
[-- Type: text/x-csrc, Size: 10502 bytes --]
/* 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 <errno.h>
#include <stdlib.h>
#if HAVE_UNISTD_H
# include <unistd.h>
#else
# include <direct.h>
#endif
#include <string.h>
#include <limits.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
/* Arrange to define PATH_MAX, like "pathmax.h" does. */
#if HAVE_UNISTD_H
# include <unistd.h>
#endif
#include <limits.h>
#if defined HAVE_SYS_PARAM_H && !defined PATH_MAX && !defined MAXPATHLEN
# include <sys/param.h>
#endif
#if !defined PATH_MAX && defined MAXPATHLEN
# define PATH_MAX MAXPATHLEN
#endif
#ifdef __hpux
# undef PATH_MAX
# define PATH_MAX 1024
#endif
#if defined _WIN32 && ! defined __CYGWIN__
# undef PATH_MAX
# define PATH_MAX 260
#endif
#ifndef AT_FDCWD
# define AT_FDCWD 0
#endif
#ifdef ENAMETOOLONG
# define is_ENAMETOOLONG(x) ((x) == ENAMETOOLONG)
#else
# define is_ENAMETOOLONG(x) 0
#endif
/* Use the getcwd function, not any macro. */
#undef getcwd
#if defined _WIN32 && !defined __CYGWIN__
#define access _access
#define chdir _chdir
#define chmod _chmod
#define close _close
#define creat _creat
#define dup _dup
#define dup2 _dup2
#define ecvt _ecvt
#define execl _execl
#define execle _execle
#define execlp _execlp
#define execv _execv
#define execve _execve
#define execvp _execvp
#define execvpe _execvpe
#define fcloseall _fcloseall
#define fcvt _fcvt
#define fdopen _fdopen
#define fileno _fileno
#define gcvt _gcvt
#define getcwd _getcwd
#define getpid _getpid
#define getw _getw
#define isatty _isatty
#define j0 _j0
#define j1 _j1
#define jn _jn
#define lfind _lfind
#define lsearch _lsearch
#define lseek _lseek
#define memccpy _memccpy
#define mkdir _mkdir
#define mktemp _mktemp
#define open _open
#define putenv _putenv
#define putw _putw
#define read _read
#define rmdir _rmdir
#define strdup _strdup
#define swab _swab
#define tempnam _tempnam
#define tzset _tzset
#define umask _umask
#define unlink _unlink
#define utime _utime
#define wcsdup _wcsdup
#define write _write
#define y0 _y0
#define y1 _y1
#define yn _yn
#endif
#ifndef S_IRWXU
# define S_IRWXU 0700
#endif
/* The length of this name must be 8. */
#define DIR_NAME "confdir3"
#define DIR_NAME_LEN 8
#define DIR_NAME_SIZE (DIR_NAME_LEN + 1)
/* The length of "../". */
#define DOTDOTSLASH_LEN 3
/* Leftover bytes in the buffer, to work around library or OS bugs. */
#define BUF_SLOP 20
int
main ()
{
alarm (10);
#ifndef PATH_MAX
/* The Hurd doesn't define this, so getcwd can't exhibit the bug --
at least not on a local file system. And if we were to start worrying
about remote file systems, we'd have to enable the wrapper function
all of the time, just to be safe. That's not worth the cost. */
exit (0);
#elif ((INT_MAX / (DIR_NAME_SIZE / DOTDOTSLASH_LEN + 1) - DIR_NAME_SIZE - BUF_SLOP) <= PATH_MAX)
/* FIXME: Assuming there's a system for which this is true,
this should be done in a compile test. */
exit (0);
#else
char buf[PATH_MAX * (DIR_NAME_SIZE / DOTDOTSLASH_LEN + 1)
+ DIR_NAME_SIZE + BUF_SLOP];
char *cwd = getcwd (buf, PATH_MAX);
size_t initial_cwd_len;
size_t cwd_len;
int fail = 0;
size_t n_chdirs = 0;
if (cwd == NULL)
exit (10);
cwd_len = initial_cwd_len = strlen (cwd);
while (1)
{
size_t dotdot_max = PATH_MAX * (DIR_NAME_SIZE / DOTDOTSLASH_LEN);
char *c = NULL;
cwd_len += DIR_NAME_SIZE;
/* If mkdir or chdir fails, it could be that this system cannot create
any file with an absolute name longer than PATH_MAX, such as cygwin.
If so, leave fail as 0, because the current working directory can't
be too long for getcwd if it can't even be created. On Linux with
the 9p file system, mkdir fails with error EINVAL when cwd_len gets
too long; ignore this failure because the getcwd() system call
produces good results whereas the gnulib substitute calls getdents64
which fails with error EPROTO.
For other errors, be pessimistic and consider that as a failure,
too. */
if (mkdir (DIR_NAME, S_IRWXU) < 0 || chdir (DIR_NAME) < 0)
{
if (! (errno == ERANGE || is_ENAMETOOLONG (errno)))
#ifdef __linux__
if (! (errno == EINVAL))
#endif
fail = 20;
break;
}
if (PATH_MAX <= cwd_len && cwd_len < PATH_MAX + DIR_NAME_SIZE)
{
struct stat sb;
c = getcwd (buf, PATH_MAX);
if (!c && errno == ENOENT)
{
fail = 11;
break;
}
if (c)
{
fail = 31;
break;
}
if (! (errno == ERANGE || is_ENAMETOOLONG (errno)))
{
fail = 21;
break;
}
/* Our replacement needs to be able to stat() long ../../paths,
so generate a path larger than PATH_MAX to check,
avoiding the replacement if we can't stat(). */
c = getcwd (buf, cwd_len + 1);
if (c && !AT_FDCWD && stat (c, &sb) != 0 && is_ENAMETOOLONG (errno))
{
fail = 32;
break;
}
}
if (dotdot_max <= cwd_len - initial_cwd_len)
{
if (dotdot_max + DIR_NAME_SIZE < cwd_len - initial_cwd_len)
break;
c = getcwd (buf, cwd_len + 1);
if (!c)
{
if (! (errno == ERANGE || errno == ENOENT
|| is_ENAMETOOLONG (errno)))
{
fail = 22;
break;
}
if (AT_FDCWD || errno == ERANGE || errno == ENOENT)
{
fail = 12;
break;
}
}
}
if (c && strlen (c) != cwd_len)
{
fail = 23;
break;
}
++n_chdirs;
}
/* Leaving behind such a deep directory is not polite.
So clean up here, right away, even though the driving
shell script would also clean up. */
{
size_t i;
/* Try rmdir first, in case the chdir failed. */
rmdir (DIR_NAME);
for (i = 0; i <= n_chdirs; i++)
{
if (chdir ("..") < 0)
break;
if (rmdir (DIR_NAME) != 0)
break;
}
}
exit (fail);
#endif
}
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-05 17:57 ` Paul Eggert
@ 2020-11-05 21:18 ` Kelly Wang (kellythw)
2020-11-05 21:36 ` Paul Eggert
0 siblings, 1 reply; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-11-05 21:18 UTC (permalink / raw)
To: Paul Eggert, Thien-Thi Nguyen
Cc: Srini Garlapalli (sgarlapa), bug-rcs@gnu.org, Gnulib bugs,
Yi Yan (yyan)
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" <eggert@cs.ucla.edu> 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).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-05 21:18 ` Kelly Wang (kellythw)
@ 2020-11-05 21:36 ` Paul Eggert
2020-11-05 22:28 ` Kelly Wang (kellythw)
0 siblings, 1 reply; 18+ messages in thread
From: Paul Eggert @ 2020-11-05 21:36 UTC (permalink / raw)
To: Kelly Wang (kellythw)
Cc: Yi Yan (yyan), Gnulib bugs, Thien-Thi Nguyen, bug-rcs@gnu.org,
Srini Garlapalli (sgarlapa)
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'.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-05 21:36 ` Paul Eggert
@ 2020-11-05 22:28 ` Kelly Wang (kellythw)
2020-11-05 22:52 ` Paul Eggert
0 siblings, 1 reply; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-11-05 22:28 UTC (permalink / raw)
To: Paul Eggert
Cc: Thien-Thi Nguyen, Srini Garlapalli (sgarlapa), bug-rcs@gnu.org,
Gnulib bugs, Yi Yan (yyan), Kelly Wang (kellythw)
Hi Paul,
When strace hang, I do 'ps -elf | grep strace' from other terminal and do kill -9 <process id from ps -elf>
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" <eggert@cs.ucla.edu> 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'.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-05 22:28 ` Kelly Wang (kellythw)
@ 2020-11-05 22:52 ` Paul Eggert
2020-11-06 16:20 ` Kelly Wang (kellythw)
0 siblings, 1 reply; 18+ messages in thread
From: Paul Eggert @ 2020-11-05 22:52 UTC (permalink / raw)
To: Kelly Wang (kellythw)
Cc: Yi Yan (yyan), Gnulib bugs, Thien-Thi Nguyen, bug-rcs@gnu.org,
Srini Garlapalli (sgarlapa)
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 <process id from ps -elf>
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-05 22:52 ` Paul Eggert
@ 2020-11-06 16:20 ` Kelly Wang (kellythw)
2020-11-06 17:40 ` Paul Eggert
0 siblings, 1 reply; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-11-06 16:20 UTC (permalink / raw)
To: Paul Eggert
Cc: Thien-Thi Nguyen, Srini Garlapalli (sgarlapa), bug-rcs@gnu.org,
Gnulib bugs, Yi Yan (yyan), Kelly Wang (kellythw)
Hi Paul,
With kill -14 91418, I don't see any output add to tr.
% ps -elf | grep strace
0 S kellythw 480 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/9 00: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" <eggert@cs.ucla.edu> 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 <process id from ps -elf>
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-06 16:20 ` Kelly Wang (kellythw)
@ 2020-11-06 17:40 ` Paul Eggert
2020-11-06 22:15 ` Kelly Wang (kellythw)
0 siblings, 1 reply; 18+ messages in thread
From: Paul Eggert @ 2020-11-06 17:40 UTC (permalink / raw)
To: Kelly Wang (kellythw)
Cc: Yi Yan (yyan), Gnulib bugs, Thien-Thi Nguyen, bug-rcs@gnu.org,
Srini Garlapalli (sgarlapa)
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/msg00001.html
https://lists.gnu.org/r/bug-tar/2019-10/msg00002.html
https://lists.gnu.org/r/bug-tar/2019-10/msg00003.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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-06 17:40 ` Paul Eggert
@ 2020-11-06 22:15 ` Kelly Wang (kellythw)
0 siblings, 0 replies; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-11-06 22:15 UTC (permalink / raw)
To: Paul Eggert
Cc: Thien-Thi Nguyen, Srini Garlapalli (sgarlapa), bug-rcs@gnu.org,
Gnulib bugs, Yi Yan (yyan), 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" <eggert@cs.ucla.edu> 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/msg00001.html
https://lists.gnu.org/r/bug-tar/2019-10/msg00002.html
https://lists.gnu.org/r/bug-tar/2019-10/msg00003.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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-10-27 15:36 ` Kelly Wang (kellythw)
2020-11-05 16:11 ` Kelly Wang (kellythw)
2020-11-05 17:57 ` Paul Eggert
@ 2020-11-09 9:14 ` Florian Weimer
2020-11-10 17:37 ` Kelly Wang (kellythw)
2021-01-10 22:04 ` Thien-Thi Nguyen
2 siblings, 2 replies; 18+ messages in thread
From: Florian Weimer @ 2020-11-09 9:14 UTC (permalink / raw)
To: Kelly Wang (kellythw)
Cc: Paul Eggert, Gnulib bugs, Thien-Thi Nguyen, Yi Yan (yyan),
Srini Garlapalli (sgarlapa), bug-rcs@gnu.org
* 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-09 9:14 ` Florian Weimer
@ 2020-11-10 17:37 ` Kelly Wang (kellythw)
2021-01-11 16:19 ` Florian Weimer
2021-01-10 22:04 ` Thien-Thi Nguyen
1 sibling, 1 reply; 18+ messages in thread
From: Kelly Wang (kellythw) @ 2020-11-10 17:37 UTC (permalink / raw)
To: Florian Weimer
Cc: Paul Eggert, Thien-Thi Nguyen, Srini Garlapalli (sgarlapa),
bug-rcs@gnu.org, Gnulib bugs, Yi Yan (yyan),
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" <fweimer@redhat.com> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-09 9:14 ` Florian Weimer
2020-11-10 17:37 ` Kelly Wang (kellythw)
@ 2021-01-10 22:04 ` Thien-Thi Nguyen
2021-01-11 16:06 ` Kelly Wang (kellythw) via Gnulib discussion list
1 sibling, 1 reply; 18+ messages in thread
From: Thien-Thi Nguyen @ 2021-01-10 22:04 UTC (permalink / raw)
To: Florian Weimer
Cc: Paul Eggert, Gnulib bugs, Yi Yan (yyan), Kelly Wang (kellythw),
Srini Garlapalli (sgarlapa), bug-rcs@gnu.org
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
() Florian Weimer <fweimer@redhat.com>
() 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 219 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2021-01-10 22:04 ` Thien-Thi Nguyen
@ 2021-01-11 16:06 ` Kelly Wang (kellythw) via Gnulib discussion list
0 siblings, 0 replies; 18+ messages in thread
From: Kelly Wang (kellythw) via Gnulib discussion list @ 2021-01-11 16:06 UTC (permalink / raw)
To: Thien-Thi Nguyen, Florian Weimer
Cc: Paul Eggert, Gnulib bugs, Yi Yan (yyan), Kelly Wang (kellythw),
Srini Garlapalli (sgarlapa), bug-rcs@gnu.org
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" <ttn@gnuvola.org> wrote:
() Florian Weimer <fweimer@redhat.com>
() 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: rcs configure hang
2020-11-10 17:37 ` Kelly Wang (kellythw)
@ 2021-01-11 16:19 ` Florian Weimer
0 siblings, 0 replies; 18+ messages in thread
From: Florian Weimer @ 2021-01-11 16:19 UTC (permalink / raw)
To: Kelly Wang (kellythw)
Cc: Paul Eggert, Gnulib bugs, Thien-Thi Nguyen, Yi Yan (yyan),
Srini Garlapalli (sgarlapa), bug-rcs@gnu.org
* 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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-01-11 16:20 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <2B072F48-AF8B-47E0-AC5D-C9AB5E0DC4AD@cisco.com>
[not found] ` <873627odbp.fsf@gnuvola.org>
2020-10-22 22:02 ` rcs configure hang Paul Eggert
2020-10-26 16:13 ` Kelly Wang (kellythw)
2020-10-26 22:55 ` Paul Eggert
2020-10-27 15:36 ` Kelly Wang (kellythw)
2020-11-05 16:11 ` Kelly Wang (kellythw)
2020-11-05 17:57 ` Paul Eggert
2020-11-05 21:18 ` Kelly Wang (kellythw)
2020-11-05 21:36 ` Paul Eggert
2020-11-05 22:28 ` Kelly Wang (kellythw)
2020-11-05 22:52 ` Paul Eggert
2020-11-06 16:20 ` Kelly Wang (kellythw)
2020-11-06 17:40 ` Paul Eggert
2020-11-06 22:15 ` Kelly Wang (kellythw)
2020-11-09 9:14 ` Florian Weimer
2020-11-10 17:37 ` Kelly Wang (kellythw)
2021-01-11 16:19 ` Florian Weimer
2021-01-10 22:04 ` Thien-Thi Nguyen
2021-01-11 16:06 ` Kelly Wang (kellythw) via Gnulib discussion list
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).