RTC failure on FD_ZERO in any program compiled with -debug -check-uninit on openSUSE 11.2 or Ubuntu 9.10

[vkrevs]

Hi. I was wondering if someone could help me with the following issue.

I've just installed Intel C++ compiler 11.1/059 on openSUSE 11.1 for x86_64. It appears that any program contaning the FD_ZERO macro with abort with an RTC failure if compiled in -debug -check-uninit mode. For example, put the following into a file called /tmp/foo.cpp:

#include
#include
#include
int main (int argc, char ** argv)
{
fd_set readfds;
FD_ZERO (&readfds);
return EXIT_SUCCESS;
}

Then compile it:
. /opt/intel/Compiler/11.1/059/bin/iccvars.sh intel64
icpc -debug -check-uninit -c -o foo.o foo.cpp
icpc -o foo foo.o.

Then run it and observe the crash:
$ /tmp/foo

Run-Time Check Failure: The variable '__d1' is being used without being initialized

Aborted


The '__d1' variable is used in the GLIBC's definition of the FD_ZERO macro in /usr/include/bits/select.h:
....
# if __WORDSIZE == 64
# define __FD_ZERO_STOS "stosq"
# define __FD_SET_BTS "btsq"
# define __FD_CLR_BTR "btrq"
# define __FD_ISSET_BT "btq"
# else
...
# endif

# define __FD_ZERO(fdsp) \
do {<><------><------><------><------><------><------><------><------> \
int __d0, __d1;<---><------><------><------><------><------><------> \
__asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS<-><------><------> \
<------><------><------> : "=c" (__d0), "=D" (__d1)<--><------><------> \
<------><------><------> : "a" (0), "0" (sizeof (fd_set)<-----><------> \
<------><------><------><------><------> / sizeof (__fd_mask)),<------> \
<------><------><------> "1" (&__FDS_BITS (fdsp)[0])><------><------> \
<------><------><------> : "memory");<><------><------><------><------> \
} while (0)


Any suggestions?

$ rpm -q gcc glibc
gcc-4.4-4.2.x86_64
glibc-2.10.1-10.4.x86_64

[TimP]

Why not initialize it yourself, at least while using -check? Try several values to assure yourself the operation of your application doesn't depend on initial values.

[vkrevs]

Quoting - tim18

Why not initialize it yourself, at least while using -check? Try several values to assure yourself the operation of your application doesn't depend on initial values.

Hmm, I thought I was making sure my cross-platform application does not depend on initial values by using FD_ZERO in this particular case. Isn't the whole point of FD_ZERO macro is to provide a standard way to initialize an fd_set?

[vkrevs]

Same issue on Ubuntu 9.10 for x86_64. Seems like a generic problem that will occur on any system with a modern glibc (>= 2.10.x).

[Om_S_Intel]

I can reproduce this in FC11 as well.

The compiler behaviour is correct. If you do not use -check-uninit compiler option then the compiler does not check for the uninitialized variables and the compiled binary runs.

[vkrevs]

Quoting - Om Sachan (Intel)

I can reproduce this in FC11 as well.

The compiler behaviour is correct. If you do not use -check-uninit compiler option then the compiler does not check for the uninitialized variables and the compiled binary runs.

Are you saying that there is a bug in FD_ZERO's implementation in glibc 2.10.x, that is FD_ZERO's implementation in glibc 2.10.x relies on unintialized data? Valgrind does not report it ... Just out of curiosity, do you intend to work with glibc maintainers to resolve this issue?