Hide Forgot
Created attachment 503696 [details] vnc configuration of a large number of services Description of problem: xinetd does not start and aborts when a large number of services are configured. Version-Release number of selected component (if applicable): xinetd-2.3.14-36.fc16 How reproducible: Always Steps to Reproduce: 1. Copy over attached file to /etc/xinetd.d 2. Start xinetd 3. Actual results: Abort: *** glibc detected *** xinetd: free(): invalid pointer: 0x00007fd7542f60b0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x3a9d875676)[0x7fd751ed2676] xinetd(+0x9217)[0x7fd752f02217] xinetd(+0xbb26)[0x7fd752f04b26] xinetd(main+0x18)[0x7fd752f07508] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7fd751e7bc5d] xinetd(+0x57c9)[0x7fd752efe7c9] ======= Memory map: ======== 7fd7515d9000-7fd7515ef000 r-xp 00000000 fd:00 524335 /lib64/libgcc_s-4.4.4-20100726.so.1 7fd7515ef000-7fd7517ee000 ---p 00016000 fd:00 524335 /lib64/libgcc_s-4.4.4-20100726.so.1 7fd7517ee000-7fd7517ef000 rw-p 00015000 fd:00 524335 /lib64/libgcc_s-4.4.4-20100726.so.1 7fd7517ef000-7fd7517fb000 r-xp 00000000 fd:00 541775 /lib64/libnss_files-2.12.so 7fd7517fb000-7fd7519fa000 ---p 0000c000 fd:00 541775 /lib64/libnss_files-2.12.so 7fd7519fa000-7fd7519fb000 r--p 0000b000 fd:00 541775 /lib64/libnss_files-2.12.so 7fd7519fb000-7fd7519fc000 rw-p 0000c000 fd:00 541775 /lib64/libnss_files-2.12.so 7fd7519fc000-7fd751a54000 r-xp 00000000 fd:00 524314 /lib64/libfreebl3.so 7fd751a54000-7fd751c53000 ---p 00058000 fd:00 524314 /lib64/libfreebl3.so 7fd751c53000-7fd751c55000 rw-p 00057000 fd:00 524314 /lib64/libfreebl3.so 7fd751c55000-7fd751c59000 rw-p 00000000 00:00 0 7fd751c59000-7fd751c5b000 r-xp 00000000 fd:00 524308 /lib64/libdl-2.12.so 7fd751c5b000-7fd751e5b000 ---p 00002000 fd:00 524308 /lib64/libdl-2.12.so 7fd751e5b000-7fd751e5c000 r--p 00002000 fd:00 524308 /lib64/libdl-2.12.so 7fd751e5c000-7fd751e5d000 rw-p 00003000 fd:00 524308 /lib64/libdl-2.12.so 7fd751e5d000-7fd751fd2000 r-xp 00000000 fd:00 524304 /lib64/libc-2.12.so 7fd751fd2000-7fd7521d2000 ---p 00175000 fd:00 524304 /lib64/libc-2.12.so 7fd7521d2000-7fd7521d6000 r--p 00175000 fd:00 524304 /lib64/libc-2.12.so 7fd7521d6000-7fd7521d7000 rw-p 00179000 fd:00 524304 /lib64/libc-2.12.so 7fd7521d7000-7fd7521dc000 rw-p 00000000 00:00 0 7fd7521dc000-7fd7521e3000 r-xp 00000000 fd:00 524316 /lib64/libcrypt-2.12.so 7fd7521e3000-7fd7523e3000 ---p 00007000 fd:00 524316 /lib64/libcrypt-2.12.so 7fd7523e3000-7fd7523e4000 r--p 00007000 fd:00 524316 /lib64/libcrypt-2.12.so 7fd7523e4000-7fd7523e5000 rw-p 00008000 fd:00 524316 /lib64/libcrypt-2.12.so 7fd7523e5000-7fd752413000 rw-p 00000000 00:00 0 7fd752413000-7fd752496000 r-xp 00000000 fd:00 524336 /lib64/libm-2.12.so 7fd752496000-7fd752695000 ---p 00083000 fd:00 524336 /lib64/libm-2.12.so 7fd752695000-7fd752696000 r--p 00082000 fd:00 524336 /lib64/libm-2.12.so 7fd752696000-7fd752697000 rw-p 00083000 fd:00 524336 /lib64/libm-2.12.so 7fd752697000-7fd7526ad000 r-xp 00000000 fd:00 529829 /lib64/libnsl-2.12.so 7fd7526ad000-7fd7528ac000 ---p 00016000 fd:00 529829 /lib64/libnsl-2.12.so 7fd7528ac000-7fd7528ad000 r--p 00015000 fd:00 529829 /lib64/libnsl-2.12.so 7fd7528ad000-7fd7528ae000 rw-p 00016000 fd:00 529829 /lib64/libnsl-2.12.so 7fd7528ae000-7fd7528b0000 rw-p 00000000 00:00 0 7fd7528b0000-7fd7528b8000 r-xp 00000000 fd:00 524708 /lib64/libwrap.so.0.7.6 7fd7528b8000-7fd752ab8000 ---p 00008000 fd:00 524708 /lib64/libwrap.so.0.7.6 7fd752ab8000-7fd752ab9000 rw-p 00008000 fd:00 524708 /lib64/libwrap.so.0.7.6 7fd752ab9000-7fd752aba000 rw-p 00000000 00:00 0 7fd752aba000-7fd752ad7000 r-xp 00000000 fd:00 524318 /lib64/libselinux.so.1Aborted (core dumped) Expected results: Don't crash Additional info: Attached patch fixes the problem. Looks like xinetd was trying to write to a freed pointer, i.e. realloc'ed into another memory location. --- Additional comment from spoyarek on 2011-06-08 09:42:57 EDT --- Created attachment 503698 [details] write into the realloc'ed location, not the old one
Fixed in rawhide http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/721044.html
This actually still causes memory corruption. The problem lies in the realloc itself. When assigning a file descriptor to a service, a pointer to the global array of fds is used. Reallocing that array moves it to another memory location, thus invalidating the original pointers that all services have been using. I'm quite surprised it doesn't segfault right away. I managed to fix this in Fedora rawhide http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/721693.html.