Recipe tries to link against local libraries when activating "postgresql" (Error: "unsafe for cross-compilation") #14
Comments
philb
pushed a commit
that referenced
this issue
Jul 8, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Jul 15, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Jul 15, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Jul 16, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Jul 27, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Jul 29, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Jul 30, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 3, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 17, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 18, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 18, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 20, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 24, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 24, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 27, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Aug 31, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this issue
Sep 14, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
We don't use github.com for tracking issues. If the issue is still valid, then send a patch to openembedded-devel@lists.openembedded.org |
halstead
pushed a commit
that referenced
this issue
Jul 12, 2017
Unicode::LineBreak - UAX #14 Unicode Line Breaking Algorithm. It's being strongly recommended by po4a. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
halstead
pushed a commit
that referenced
this issue
Jul 14, 2017
Unicode::LineBreak - UAX #14 Unicode Line Breaking Algorithm. It's being strongly recommended by po4a. Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Jul 23, 2021
Add docs/ to sdist Addresses part of openembedded#14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Jul 23, 2021
Add docs/ to sdist Addresses part of openembedded#14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Jul 25, 2021
Add docs/ to sdist Addresses part of openembedded#14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Jul 25, 2021
Add docs/ to sdist Addresses part of openembedded#14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Jul 26, 2021
Add docs/ to sdist Addresses part of openembedded#14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Jul 26, 2021
Add docs/ to sdist Addresses part of openembedded#14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Jul 27, 2021
Add docs/ to sdist Addresses part of openembedded#14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
halstead
pushed a commit
that referenced
this issue
Jul 27, 2021
Add docs/ to sdist Addresses part of #14 Signed-off-by: Zang Ruochen <zangrc.fnst@fujitsu.com> Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this issue
Mar 6, 2023
Changes in 2.1.2:
* Fix unprivileged ICMP tracerouting with Linux kernel >= 6.1
(Eric Dumazet, SF bug openembedded#14)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
halstead
pushed a commit
that referenced
this issue
Nov 29, 2023
This upgrade incorporates the CVE-2023-46316 fix and other bug fixes. Changelog: ---------- - Interpret ipv4-mapped ipv6 addresses (::ffff:A.B.C.D) as true ipv4. - Return back more robast poll(2) loop handling. - Fix unprivileged ICMP tracerouting with Linux kernel >= 6.1 (Eric Dumazet, SF bug #14) - Fix command line parsing in wrappers. References: https://security-tracker.debian.org/tracker/CVE-2023-46316 https://sourceforge.net/projects/traceroute/files/traceroute/traceroute-2.1.3/ Signed-off-by: Narpat Mali <narpat.mali@windriver.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/meta-openembedded
that referenced
this issue
Dec 4, 2023
Source: meta-openembedded MR: 129773 Type: Integration Disposition: Merged from meta-openembedded ChangeID: a7e6f56 Description: This upgrade incorporates the CVE-2023-46316 fix and other bug fixes. Changelog: ---------- - Interpret ipv4-mapped ipv6 addresses (::ffff:A.B.C.D) as true ipv4. - Return back more robast poll(2) loop handling. - Fix unprivileged ICMP tracerouting with Linux kernel >= 6.1 (Eric Dumazet, SF bug openembedded#14) - Fix command line parsing in wrappers. References: https://security-tracker.debian.org/tracker/CVE-2023-46316 https://sourceforge.net/projects/traceroute/files/traceroute/traceroute-2.1.3/ Signed-off-by: Narpat Mali <narpat.mali@windriver.com> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
halstead
pushed a commit
that referenced
this issue
Dec 17, 2023
This upgrade incorporates the CVE-2023-46316 fix and other bug fixes. Changelog: ---------- - Interpret ipv4-mapped ipv6 addresses (::ffff:A.B.C.D) as true ipv4. - Return back more robast poll(2) loop handling. - Fix unprivileged ICMP tracerouting with Linux kernel >= 6.1 (Eric Dumazet, SF bug #14) - Fix command line parsing in wrappers. References: https://security-tracker.debian.org/tracker/CVE-2023-46316 https://sourceforge.net/projects/traceroute/files/traceroute/traceroute-2.1.3/ Signed-off-by: Vijay Anusuri <vanusuri@mvista.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/meta-openembedded
that referenced
this issue
Dec 18, 2023
Source: meta-openembedded MR: 128824, 129557 Type: Security Fix Disposition: Merged from meta-openembedded ChangeID: 57e58dc Description: This upgrade incorporates the CVE-2023-46316 fix and other bug fixes. Changelog: ---------- - Interpret ipv4-mapped ipv6 addresses (::ffff:A.B.C.D) as true ipv4. - Return back more robast poll(2) loop handling. - Fix unprivileged ICMP tracerouting with Linux kernel >= 6.1 (Eric Dumazet, SF bug openembedded#14) - Fix command line parsing in wrappers. References: https://security-tracker.debian.org/tracker/CVE-2023-46316 https://sourceforge.net/projects/traceroute/files/traceroute/traceroute-2.1.3/ Signed-off-by: Vijay Anusuri <vanusuri@mvista.com> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When activating support for postgresql:
PACKAGECONFIG_pn-php = "mysql sqlite3 pgsql"The recipe fails:
The reason is that the recipe tries to link against local libraries. "config.log" shows among others the following output:
I posted this already in the official yocto mailing list: https://www.mail-archive.com/yocto@yoctoproject.org/msg24335.html
Operating system is Ubuntu 32 bit as well as Ubuntu 64 bit.
I am willed to fix this but I need some support.
The text was updated successfully, but these errors were encountered: