Summary: | dev-libs/glib-2.58.3: protocol test hangs forever | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rolf Eike Beer <eike> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | TESTFAILURE |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Rolf Eike Beer
2019-02-09 12:05:32 UTC
Created attachment 564324 [details]
build.log
It happened again, so I attached strace to both processes. Both seem to wait for input from the other one. I guess it sometimes happens and sometimes doesn't? I hit an infite wait case on arm64 too, but it was some other test case, not protocol test. Would -j1 workaround "fix" it for now? "-j 1" does not help. But this time with debug info, although that looks like it sits in some kind of event loops: (gdb) bt #0 0xf7863d78 in poll () from /lib/libc.so.6 #1 0xf799d08c in g_main_context_iterate.isra () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #2 0xf799d664 in g_main_loop_run () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #3 0x700015ec in test_error () at /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3/glib/tests/protocol.c:297 #4 0xf79cc210 in g_test_run_suite_internal () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #5 0xf79cc098 in g_test_run_suite_internal () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #6 0xf79cc098 in g_test_run_suite_internal () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #7 0xf79cc098 in g_test_run_suite_internal () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #8 0xf79cc554 in g_test_run_suite () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #9 0xf79cc594 in g_test_run () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #10 0x70000f60 in main (argc=<optimized out>, argv=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3/glib/tests/protocol.c:370 (gdb) thread 2 [Switching to thread 2 (Thread 0xf764fb70 (LWP 13517))] #0 0xf7863d78 in poll () from /lib/libc.so.6 (gdb) bt #0 0xf7863d78 in poll () from /lib/libc.so.6 #1 0xf799d08c in g_main_context_iterate.isra () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #2 0xf799d230 in g_main_context_iteration () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #3 0xf799d2e0 in glib_worker_main () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #4 0xf79cd8b8 in g_thread_proxy () from /var/tmp/portage/dev-libs/glib-2.58.3/work/glib-2.58.3-.sparc32/glib/.libs/libglib-2.0.so.0 #5 0xf791ecec in start_thread () from /lib/libpthread.so.0 #6 0xf7871970 in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) How does this fare with glib-2.60.6? It times out, after both default 2 minute and increated 10 minute timeout. So it's probably as broken as before, but the test driver now catches it so it will not block further builds. Seems to work with 2.62.6. |