The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David
I think polyc is little broken. "polyc_CFLAGS" macro do not replaced on "-O3":
git pull && ./configure && make && make compiler && make install
...
grep polyc_CFLAGS ./polyc
CFLAGS="@polyc_CFLAGS@"
2017-02-21 14:48 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
The configure script needs to be regenerated from configure.ac.
James
On 21 Feb 2017, at 14:17, Kostirya <kostirya at gmail.com> wrote:
I think polyc is little broken. "polyc_CFLAGS" macro do not replaced on "-O3":
git pull && ./configure && make && make compiler && make install
...
grep polyc_CFLAGS ./polyc
CFLAGS="@polyc_CFLAGS@"
2017-02-21 14:48 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Thanks. That's now been done. David
On 21/02/2017 14:30, James Clarke wrote:
The configure script needs to be regenerated from configure.ac.
James
On 21 Feb 2017, at 14:17, Kostirya <kostirya at gmail.com> wrote:
I think polyc is little broken. "polyc_CFLAGS" macro do not replaced on "-O3":
git pull && ./configure && make && make compiler && make install
...
grep polyc_CFLAGS ./polyc
CFLAGS="@polyc_CFLAGS@"
2017-02-21 14:48 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I sometimes get Segmentation fault on pure SML code (without FFI). Feels it's after main function finished.
gdb -c a.out.core a.out
GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libc++.so.1...done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000080067e618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 [New Thread 802023800 (LWP 100475/<unknown>)] [New Thread 802023400 (LWP 100474/<unknown>)] [New Thread 801c07400 (LWP 100473/<unknown>)] [New Thread 801c07000 (LWP 100472/<unknown>)] [New Thread 801c06c00 (LWP 100471/<unknown>)] [New Thread 801c06800 (LWP 100470/<unknown>)] [New Thread 801c06400 (LWP 100112/<unknown>)] (gdb) bt #0 0x000000080067e618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #1 0x000000080067de3a in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #2 0x000000080067aea0 in dlopen () from /libexec/ld-elf.so.1 #3 0x00000008008a7a48 in pthread_exit () from /lib/libthr.so.3 #4 0x00000008008a796b in pthread_exit () from /lib/libthr.so.3 #5 0x000000080089c85d in pthread_create () from /lib/libthr.so.3 #6 0x0000000000000000 in ?? () (gdb)
2017-02-21 14:48 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
it's also when i compile sml code:
polyc gc_bench.sml
Segmentation fault (core dumped)
gdb -c poly.core /home/nick/polyml/bin/poly
... (gdb) bt #0 0x0000000800fea618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #1 0x0000000800fe9e3a in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #2 0x0000000800fe6ea0 in dlopen () from /libexec/ld-elf.so.1 #3 0x0000000801213a48 in pthread_exit () from /lib/libthr.so.3 #4 0x000000080121396b in pthread_exit () from /lib/libthr.so.3 #5 0x000000080120885d in pthread_create () from /lib/libthr.so.3 #6 0x0000000000000000 in ?? () (gdb)
2017-02-21 16:57 GMT+02:00 Kostirya <kostirya at gmail.com>:
I sometimes get Segmentation fault on pure SML code (without FFI). Feels it's after main function finished.
gdb -c a.out.core a.out
GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libc++.so.1...done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000080067e618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 [New Thread 802023800 (LWP 100475/<unknown>)] [New Thread 802023400 (LWP 100474/<unknown>)] [New Thread 801c07400 (LWP 100473/<unknown>)] [New Thread 801c07000 (LWP 100472/<unknown>)] [New Thread 801c06c00 (LWP 100471/<unknown>)] [New Thread 801c06800 (LWP 100470/<unknown>)] [New Thread 801c06400 (LWP 100112/<unknown>)] (gdb) bt #0 0x000000080067e618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #1 0x000000080067de3a in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #2 0x000000080067aea0 in dlopen () from /libexec/ld-elf.so.1 #3 0x00000008008a7a48 in pthread_exit () from /lib/libthr.so.3 #4 0x00000008008a796b in pthread_exit () from /lib/libthr.so.3 #5 0x000000080089c85d in pthread_create () from /lib/libthr.so.3 #6 0x0000000000000000 in ?? () (gdb)
2017-02-21 14:48 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
I've not seen anything like that. I did a search to see if anyone else had had a crash in similar circumstances in other programs and interestingly the closest match was also in FreeBSD. It's difficult to know where the problem is.
David
On 21/02/2017 15:32, Kostirya wrote:
it's also when i compile sml code:
polyc gc_bench.sml
Segmentation fault (core dumped)
gdb -c poly.core /home/nick/polyml/bin/poly
... (gdb) bt #0 0x0000000800fea618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #1 0x0000000800fe9e3a in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #2 0x0000000800fe6ea0 in dlopen () from /libexec/ld-elf.so.1 #3 0x0000000801213a48 in pthread_exit () from /lib/libthr.so.3 #4 0x000000080121396b in pthread_exit () from /lib/libthr.so.3 #5 0x000000080120885d in pthread_create () from /lib/libthr.so.3 #6 0x0000000000000000 in ?? () (gdb)
2017-02-21 16:57 GMT+02:00 Kostirya <kostirya at gmail.com>:
I sometimes get Segmentation fault on pure SML code (without FFI). Feels it's after main function finished.
gdb -c a.out.core a.out
GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/lib/libc++.so.1...done. Loaded symbols for /usr/lib/libc++.so.1 Reading symbols from /lib/libcxxrt.so.1...done. Loaded symbols for /lib/libcxxrt.so.1 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000080067e618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 [New Thread 802023800 (LWP 100475/<unknown>)] [New Thread 802023400 (LWP 100474/<unknown>)] [New Thread 801c07400 (LWP 100473/<unknown>)] [New Thread 801c07000 (LWP 100472/<unknown>)] [New Thread 801c06c00 (LWP 100471/<unknown>)] [New Thread 801c06800 (LWP 100470/<unknown>)] [New Thread 801c06400 (LWP 100112/<unknown>)] (gdb) bt #0 0x000000080067e618 in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #1 0x000000080067de3a in _rtld_is_dlopened () from /libexec/ld-elf.so.1 #2 0x000000080067aea0 in dlopen () from /libexec/ld-elf.so.1 #3 0x00000008008a7a48 in pthread_exit () from /lib/libthr.so.3 #4 0x00000008008a796b in pthread_exit () from /lib/libthr.so.3 #5 0x000000080089c85d in pthread_create () from /lib/libthr.so.3 #6 0x0000000000000000 in ?? () (gdb)
2017-02-21 14:48 GMT+02:00 David Matthews <David.Matthews at prolingua.co.uk>:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Hi David, It seems Test166 (the new condition variable one) sometimes deadlocks. I'm able to reliably reproduce with the following:
./configure make -j2 compiler make -j2 compiler while true; do make -j2 check; done
(The -j2's are probably irrelevant, but I'm including them for completeness)
On the 40th iteration of the loop it got stuck for me:
val runTests = fn: string -> bool Test028.ML => Passed Test166.ML =>
Threads:
Thread 9 (Thread 0x7faf066fc700 (LWP 29448)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf066fbe08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730295024) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf066fc700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 8 (Thread 0x7faf06efd700 (LWP 29447)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf06efce08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730294192) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf06efd700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 7 (Thread 0x7faf076fe700 (LWP 29446)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf076fde08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730242944) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf076fe700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 6 (Thread 0x7faf07fff700 (LWP 29445)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7237 in Processes::WaitForSignal(TaskData*, PLock*) () #2 0x000055ff143c4f8f in PolyWaitForSignal () #3 0x000055ff13f1b8ba in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf07ffee08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730232720) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf07fff700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 5 (Thread 0x7faf0ce72700 (LWP 29444)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x000055ff14b34e00 in gHeapSizeParameters () #5 0x00007faf0ce71e08 in ?? () #6 0x00007faf0fb64000 in ?? () #7 0x000055ff143a7988 in MemMgr::GrowOrShrinkStack(TaskData*, unsigned long) () #8 0x000055ff15c76870 in ?? () #9 0x000055ff15c76870 in ?? () #10 0x000055ff15c76660 in ?? () #11 0x000055ff15c76668 in ?? () #12 0x000055ff143c9681 in X86TaskData::EnterPolyCode() () #13 0x000055ff143b8990 in NewThreadFunction(void*) () #14 0x00007faf0f73f424 in start_thread (arg=0x7faf0ce72700) at pthread_create.c:333 #15 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 4 (Thread 0x7faf0d673700 (LWP 29443)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0d673700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 3 (Thread 0x7faf0de74700 (LWP 29442)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0de74700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 2 (Thread 0x7faf0e675700 (LWP 29441)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143c4c91 in SignalDetectionThread(void*) () #5 0x00007faf0f73f424 in start_thread (arg=0x7faf0e675700) at pthread_create.c:333 #6 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 1 (Thread 0x7faf0fb49740 (LWP 29440)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x000055ff143a604e in PCondVar::WaitFor(PLock*, unsigned int) () #2 0x000055ff143b8c9f in Processes::BeginRootThread(PolyObject*) () #3 0x000055ff143aaf13 in polymain () #4 0x00007faf0e6962b1 in __libc_start_main (main=0x55ff13f15dc0 <main>, argc=1, argv=0x7ffe94073258, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe94073248) at ../csu/libc-start.c:291 #5 0x000055ff13f1661a in _start ()
Any ideas? This is on Debian amd64 unstable, but I've seen it on non-x86 architectures too with the latest version. Interestingly I can't seem to reproduce it on macOS.
Regards, James
On 21 Feb 2017, at 12:48, David Matthews <David.Matthews at prolingua.co.uk> wrote:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Hi James, I've tried this with Debian stable 64-bit in a VirtualBox and haven't had any problems. Of course that's a different set-up but I would have expected to see something if there was a problem. It makes it rather difficult to track this down.
David
On 23/02/2017 20:44, James Clarke wrote:
Hi David, It seems Test166 (the new condition variable one) sometimes deadlocks. I'm able to reliably reproduce with the following:
./configure make -j2 compiler make -j2 compiler while true; do make -j2 check; done
(The -j2's are probably irrelevant, but I'm including them for completeness)
On the 40th iteration of the loop it got stuck for me:
val runTests = fn: string -> bool Test028.ML => Passed Test166.ML =>
Threads:
Thread 9 (Thread 0x7faf066fc700 (LWP 29448)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf066fbe08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730295024) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf066fc700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 8 (Thread 0x7faf06efd700 (LWP 29447)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf06efce08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730294192) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf06efd700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 7 (Thread 0x7faf076fe700 (LWP 29446)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf076fde08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730242944) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf076fe700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 6 (Thread 0x7faf07fff700 (LWP 29445)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7237 in Processes::WaitForSignal(TaskData*, PLock*) () #2 0x000055ff143c4f8f in PolyWaitForSignal () #3 0x000055ff13f1b8ba in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf07ffee08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730232720) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf07fff700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 5 (Thread 0x7faf0ce72700 (LWP 29444)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x000055ff14b34e00 in gHeapSizeParameters () #5 0x00007faf0ce71e08 in ?? () #6 0x00007faf0fb64000 in ?? () #7 0x000055ff143a7988 in MemMgr::GrowOrShrinkStack(TaskData*, unsigned long) () #8 0x000055ff15c76870 in ?? () #9 0x000055ff15c76870 in ?? () #10 0x000055ff15c76660 in ?? () #11 0x000055ff15c76668 in ?? () #12 0x000055ff143c9681 in X86TaskData::EnterPolyCode() () #13 0x000055ff143b8990 in NewThreadFunction(void*) () #14 0x00007faf0f73f424 in start_thread (arg=0x7faf0ce72700) at pthread_create.c:333 #15 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 4 (Thread 0x7faf0d673700 (LWP 29443)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0d673700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 3 (Thread 0x7faf0de74700 (LWP 29442)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0de74700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 2 (Thread 0x7faf0e675700 (LWP 29441)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143c4c91 in SignalDetectionThread(void*) () #5 0x00007faf0f73f424 in start_thread (arg=0x7faf0e675700) at pthread_create.c:333 #6 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 1 (Thread 0x7faf0fb49740 (LWP 29440)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x000055ff143a604e in PCondVar::WaitFor(PLock*, unsigned int) () #2 0x000055ff143b8c9f in Processes::BeginRootThread(PolyObject*) () #3 0x000055ff143aaf13 in polymain () #4 0x00007faf0e6962b1 in __libc_start_main (main=0x55ff13f15dc0 <main>, argc=1, argv=0x7ffe94073258, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe94073248) at ../csu/libc-start.c:291 #5 0x000055ff13f1661a in _start ()
Any ideas? This is on Debian amd64 unstable, but I've seen it on non-x86 architectures too with the latest version. Interestingly I can't seem to reproduce it on macOS.
Regards, James
On 21 Feb 2017, at 12:48, David Matthews <David.Matthews at prolingua.co.uk> wrote:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
This is on Debian unstable (the soon-to-be-released Stretch should be close enough), but also amd64 in VirtualBox. Perhaps there have been some glibc changes? I couldn't reproduce it under my macOS host, which would be consistent with that.
James
On 1 Mar 2017, at 15:48, David Matthews <David.Matthews at prolingua.co.uk> wrote:
Hi James, I've tried this with Debian stable 64-bit in a VirtualBox and haven't had any problems. Of course that's a different set-up but I would have expected to see something if there was a problem. It makes it rather difficult to track this down.
David
On 23/02/2017 20:44, James Clarke wrote:
Hi David, It seems Test166 (the new condition variable one) sometimes deadlocks. I'm able to reliably reproduce with the following:
./configure make -j2 compiler make -j2 compiler while true; do make -j2 check; done
(The -j2's are probably irrelevant, but I'm including them for completeness)
On the 40th iteration of the loop it got stuck for me:
val runTests = fn: string -> bool Test028.ML => Passed Test166.ML =>
Threads:
Thread 9 (Thread 0x7faf066fc700 (LWP 29448)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf066fbe08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730295024) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf066fc700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 8 (Thread 0x7faf06efd700 (LWP 29447)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf06efce08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730294192) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf06efd700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 7 (Thread 0x7faf076fe700 (LWP 29446)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf076fde08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730242944) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf076fe700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 6 (Thread 0x7faf07fff700 (LWP 29445)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7237 in Processes::WaitForSignal(TaskData*, PLock*) () #2 0x000055ff143c4f8f in PolyWaitForSignal () #3 0x000055ff13f1b8ba in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf07ffee08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730232720) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf07fff700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 5 (Thread 0x7faf0ce72700 (LWP 29444)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x000055ff14b34e00 in gHeapSizeParameters () #5 0x00007faf0ce71e08 in ?? () #6 0x00007faf0fb64000 in ?? () #7 0x000055ff143a7988 in MemMgr::GrowOrShrinkStack(TaskData*, unsigned long) () #8 0x000055ff15c76870 in ?? () #9 0x000055ff15c76870 in ?? () #10 0x000055ff15c76660 in ?? () #11 0x000055ff15c76668 in ?? () #12 0x000055ff143c9681 in X86TaskData::EnterPolyCode() () #13 0x000055ff143b8990 in NewThreadFunction(void*) () #14 0x00007faf0f73f424 in start_thread (arg=0x7faf0ce72700) at pthread_create.c:333 #15 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 4 (Thread 0x7faf0d673700 (LWP 29443)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0d673700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 3 (Thread 0x7faf0de74700 (LWP 29442)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0de74700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 2 (Thread 0x7faf0e675700 (LWP 29441)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143c4c91 in SignalDetectionThread(void*) () #5 0x00007faf0f73f424 in start_thread (arg=0x7faf0e675700) at pthread_create.c:333 #6 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 1 (Thread 0x7faf0fb49740 (LWP 29440)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x000055ff143a604e in PCondVar::WaitFor(PLock*, unsigned int) () #2 0x000055ff143b8c9f in Processes::BeginRootThread(PolyObject*) () #3 0x000055ff143aaf13 in polymain () #4 0x00007faf0e6962b1 in __libc_start_main (main=0x55ff13f15dc0 <main>, argc=1, argv=0x7ffe94073258, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe94073248) at ../csu/libc-start.c:291 #5 0x000055ff13f1661a in _start ()
Any ideas? This is on Debian amd64 unstable, but I've seen it on non-x86 architectures too with the latest version. Interestingly I can't seem to reproduce it on macOS.
Regards, James
On 21 Feb 2017, at 12:48, David Matthews <David.Matthews at prolingua.co.uk> wrote:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Hi David, I can reproduce this (or at least a very similar issue) seemingly every time on 32-bit PowerPC. All three of my uploads to Debian failed to build on it (across different machines) and I can reproduce it on another box. It happens with both jessie and unstable; below is the state of all the threads when I built it on unstable with two calls to "make compiler" followed by a "make check" (though ./poly --script Tests/Succeed/Test166.ML also hangs, so the test harness and running other tests first is irrelevant). Do you have access to a PowerPC machine you can put Debian on? If not I can probably arrange getting you remote access to one.
Regards, James
(gdb) thread apply all bt
Thread 16 (Thread 0xee2ff450 (LWP 1795)): #0 0x1fdefb98 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1ff45718 in pthread_cond_wait () from /lib/powerpc-linux-gnu/libc.so.6 #2 0x20024eb4 in PCondVar::Wait (this=this at entry=0xf2a172b8, pLock=pLock at entry=0x200911ec <processesModule+20>) at locking.cpp:169 #3 0x20036880 in Processes::WaitInfinite (this=this at entry=0x200911d8 <processesModule>, taskData=taskData at entry=0xf2a17280, hMutex=0xf2a6a4c0) at processes.cpp:576 #4 0x2003694c in PolyThreadCondVarWait (threadId=<optimized out>, arg=...) at processes.cpp:509 #5 0x2004ca2c in IntTaskData::SwitchToPoly (this=this at entry=0xf2a17280) at interpret.cpp:855 #6 0x2004f374 in IntTaskData::EnterPolyCode (this=0xf2a17280) at interpret.cpp:1936 #7 0x20037074 in NewThreadFunction (parameter=0xf2a17280) at processes.cpp:1361 #8 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #9 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 15 (Thread 0xeeaff450 (LWP 1794)): #0 0x1fdefb98 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1ff45718 in pthread_cond_wait () from /lib/powerpc-linux-gnu/libc.so.6 #2 0x20024eb4 in PCondVar::Wait (this=this at entry=0xf2a17088, pLock=pLock at entry=0x200911ec <processesModule+20>) at locking.cpp:169 #3 0x20036880 in Processes::WaitInfinite (this=this at entry=0x200911d8 <processesModule>, taskData=taskData at entry=0xf2a17050, hMutex=0xf2a69510) at processes.cpp:576 #4 0x2003694c in PolyThreadCondVarWait (threadId=<optimized out>, arg=...) at processes.cpp:509 #5 0x2004ca2c in IntTaskData::SwitchToPoly (this=this at entry=0xf2a17050) at interpret.cpp:855 #6 0x2004f374 in IntTaskData::EnterPolyCode (this=0xf2a17050) at interpret.cpp:1936 #7 0x20037074 in NewThreadFunction (parameter=0xf2a17050) at processes.cpp:1361 #8 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #9 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 14 (Thread 0xef2ff450 (LWP 1793)): #0 0x1fdefb98 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1ff45718 in pthread_cond_wait () from /lib/powerpc-linux-gnu/libc.so.6 #2 0x20024eb4 in PCondVar::Wait (this=this at entry=0xf2a16f48, pLock=pLock at entry=0x200911ec <processesModule+20>) at locking.cpp:169 #3 0x20036880 in Processes::WaitInfinite (this=this at entry=0x200911d8 <processesModule>, taskData=taskData at entry=0xf2a16f10, hMutex=0xf2a68560) at processes.cpp:576 #4 0x2003694c in PolyThreadCondVarWait (threadId=<optimized out>, arg=...) at processes.cpp:509 #5 0x2004ca2c in IntTaskData::SwitchToPoly (this=this at entry=0xf2a16f10) at interpret.cpp:855 #6 0x2004f374 in IntTaskData::EnterPolyCode (this=0xf2a16f10) at interpret.cpp:1936 #7 0x20037074 in NewThreadFunction (parameter=0xf2a16f10) at processes.cpp:1361 #8 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #9 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 13 (Thread 0xf1fff450 (LWP 1792)): #0 0x1fdefb98 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1ff45718 in pthread_cond_wait () from /lib/powerpc-linux-gnu/libc.so.6 #2 0x20024eb4 in PCondVar::Wait (this=this at entry=0xf2a19078, pLock=pLock at entry=0x200911ec <processesModule+20>) at locking.cpp:169 #3 0x20036540 in Processes::MutexBlock (this=this at entry=0x200911d8 <processesModule>, taskData=taskData at entry=0xf2a19040, hMutex=0xf2a190e0) at processes.cpp:465 #4 0x2003661c in PolyThreadMutexBlock (threadId=<optimized out>, arg=...) at processes.cpp:395 #5 0x2004ca2c in IntTaskData::SwitchToPoly (this=this at entry=0xf2a19040) at interpret.cpp:855 #6 0x2004f374 in IntTaskData::EnterPolyCode (this=0xf2a19040) at interpret.cpp:1936 #7 0x20037074 in NewThreadFunction (parameter=0xf2a19040) at processes.cpp:1361 #8 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #9 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 12 (Thread 0xf29ff450 (LWP 1757)): #0 0x1fdefb98 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1ff45718 in pthread_cond_wait () from /lib/powerpc-linux-gnu/libc.so.6 #2 0x20024eb4 in PCondVar::Wait (this=this at entry=0xf2a044c8, pLock=pLock at entry=0x200911ec <processesModule+20>) at locking.cpp:169 #3 0x20037cb4 in Processes::WaitForSignal (this=0x200911d8 <processesModule>, taskData=0xf2a04490, sigLock=0x20092210 <sigLock>) at processes.cpp:2110 #4 0x20048aac in waitForSignal (taskData=0xf2a04490) at sighandler.cpp:275 #5 PolyWaitForSignal (threadId=<optimized out>) at sighandler.cpp:344 #6 0x2004c9cc in IntTaskData::SwitchToPoly (this=this at entry=0xf2a04490) at interpret.cpp:843 #7 0x2004f3f0 in IntTaskData::EnterPolyCode (this=0xf2a04490) at interpret.cpp:1936 #8 0x20037074 in NewThreadFunction (parameter=0xf2a04490) at processes.cpp:1361 #9 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #10 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 11 (Thread 0xf33cf450 (LWP 1756)): #0 0x1fdefb98 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1ff45718 in pthread_cond_wait () from /lib/powerpc-linux-gnu/libc.so.6 #2 0x20024eb4 in PCondVar::Wait (this=this at entry=0x20adc4a8, pLock=pLock at entry=0x200911ec <processesModule+20>) at locking.cpp:169 #3 0x20036880 in Processes::WaitInfinite (this=this at entry=0x200911d8 <processesModule>, taskData=taskData at entry=0x20adc470, hMutex=0x20adc51c) at processes.cpp:576 #4 0x2003694c in PolyThreadCondVarWait (threadId=<optimized out>, arg=...) at processes.cpp:509 #5 0x2004ca2c in IntTaskData::SwitchToPoly (this=this at entry=0x20adc470) at interpret.cpp:855 #6 0x2004f374 in IntTaskData::EnterPolyCode (this=0x20adc470) at interpret.cpp:1936 #7 0x20037074 in NewThreadFunction (parameter=0x20adc470) at processes.cpp:1361 #8 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #9 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 10 (Thread 0xf3bdf450 (LWP 1755)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 9 (Thread 0xf43df450 (LWP 1754)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 8 (Thread 0xf4bdf450 (LWP 1753)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 7 (Thread 0xf53df450 (LWP 1752)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 6 (Thread 0xf5bdf450 (LWP 1751)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 5 (Thread 0xf63df450 (LWP 1750)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 4 (Thread 0xf6bdf450 (LWP 1749)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 3 (Thread 0xf73df450 (LWP 1748)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=this at entry=0x20090688 <gTaskFarm>) at locking.cpp:308 #3 0x20021df0 in GCTaskFarm::ThreadFunction (this=0x20090688 <gTaskFarm>) at gctaskfarm.cpp:218 #4 0x20021f24 in GCTaskFarm::WorkerThreadFunction (parameter=<optimized out>) at gctaskfarm.cpp:241 #5 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #6 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 2 (Thread 0xf7cdf450 (LWP 1747)): #0 0x1fdf365c in do_futex_wait.constprop () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1fdf3808 in __new_sem_wait_slow.constprop.1 () from /lib/powerpc-linux-gnu/libpthread.so.0 #2 0x20025288 in PSemaphore::Wait (this=0x20092238 SigHandler::Init()::waitSemaphore) at locking.cpp:308 #3 0x200482c0 in SignalDetectionThread () at sighandler.cpp:524 #4 0x1fde7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0 #5 0x1ff339ac in clone () from /lib/powerpc-linux-gnu/libc.so.6
Thread 1 (Thread 0xf7d25290 (LWP 1733)): #0 0x1fdf0138 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/powerpc-linux-gnu/libpthread.so.0 #1 0x1ff45788 in pthread_cond_timedwait () from /lib/powerpc-linux-gnu/libc.so.6 #2 0x20024fc4 in PCondVar::WaitFor (this=this at entry=0x20091218 <processesModule+64>, pLock=pLock at entry=0x200911ec <processesModule+20>, milliseconds=milliseconds at entry=400) at locking.cpp:227 #3 0x200373f4 in Processes::BeginRootThread (this=0x200911d8 <processesModule>, rootFunction=<optimized out>) at processes.cpp:1573 #4 0x2002a3c0 in polymain (argc=1, argv=0xff8e1d44, exports=0x2085a290 <poly_exports>) at mpoly.cpp:399 #5 0x20486ea8 in main (argc=<optimized out>, argv=<optimized out>) at polystub.c:42
On 1 Mar 2017, at 15:57, James Clarke <jrtc27 at jrtc27.com> wrote:
This is on Debian unstable (the soon-to-be-released Stretch should be close enough), but also amd64 in VirtualBox. Perhaps there have been some glibc changes? I couldn't reproduce it under my macOS host, which would be consistent with that.
James
On 1 Mar 2017, at 15:48, David Matthews <David.Matthews at prolingua.co.uk> wrote:
Hi James, I've tried this with Debian stable 64-bit in a VirtualBox and haven't had any problems. Of course that's a different set-up but I would have expected to see something if there was a problem. It makes it rather difficult to track this down.
David
On 23/02/2017 20:44, James Clarke wrote:
Hi David, It seems Test166 (the new condition variable one) sometimes deadlocks. I'm able to reliably reproduce with the following:
./configure make -j2 compiler make -j2 compiler while true; do make -j2 check; done
(The -j2's are probably irrelevant, but I'm including them for completeness)
On the 40th iteration of the loop it got stuck for me:
val runTests = fn: string -> bool Test028.ML => Passed Test166.ML =>
Threads:
Thread 9 (Thread 0x7faf066fc700 (LWP 29448)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf066fbe08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730295024) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf066fc700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 8 (Thread 0x7faf06efd700 (LWP 29447)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf06efce08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730294192) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf06efd700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 7 (Thread 0x7faf076fe700 (LWP 29446)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf076fde08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730242944) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf076fe700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 6 (Thread 0x7faf07fff700 (LWP 29445)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7237 in Processes::WaitForSignal(TaskData*, PLock*) () #2 0x000055ff143c4f8f in PolyWaitForSignal () #3 0x000055ff13f1b8ba in area1 () #4 0x00007faf0ce71c00 in ?? () #5 0x00007faf07ffee08 in ?? () #6 0x00007faf0fb79040 in ?? () from /lib64/ld-linux-x86-64.so.2 #7 0x00007faf0e6f0e48 in __GI___libc_malloc (bytes=140389730232720) at malloc.c:2925 #8 0x000055ff143c5477 in initThreadSignals(TaskData*) () #9 0x000055ff143b8990 in NewThreadFunction(void*) () #10 0x00007faf0f73f424 in start_thread (arg=0x7faf07fff700) at pthread_create.c:333 #11 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 5 (Thread 0x7faf0ce72700 (LWP 29444)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x000055ff143b7e30 in Processes::WaitInfinite(TaskData*, SaveVecEntry*) () #2 0x000055ff143b7f4f in PolyThreadCondVarWait () #3 0x000055ff1426496d in area1 () #4 0x000055ff14b34e00 in gHeapSizeParameters () #5 0x00007faf0ce71e08 in ?? () #6 0x00007faf0fb64000 in ?? () #7 0x000055ff143a7988 in MemMgr::GrowOrShrinkStack(TaskData*, unsigned long) () #8 0x000055ff15c76870 in ?? () #9 0x000055ff15c76870 in ?? () #10 0x000055ff15c76660 in ?? () #11 0x000055ff15c76668 in ?? () #12 0x000055ff143c9681 in X86TaskData::EnterPolyCode() () #13 0x000055ff143b8990 in NewThreadFunction(void*) () #14 0x00007faf0f73f424 in start_thread (arg=0x7faf0ce72700) at pthread_create.c:333 #15 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 4 (Thread 0x7faf0d673700 (LWP 29443)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0d673700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 3 (Thread 0x7faf0de74700 (LWP 29442)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b34b40 <gTaskFarm>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b34b40 <gTaskFarm>, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143a313d in GCTaskFarm::ThreadFunction() () #5 0x000055ff143a3229 in GCTaskFarm::WorkerThreadFunction(void*) () #6 0x00007faf0f73f424 in start_thread (arg=0x7faf0de74700) at pthread_create.c:333 #7 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 2 (Thread 0x7faf0e675700 (LWP 29441)): #0 0x00007faf0f747536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 do_futex_wait (sem=sem at entry=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:111 #2 0x00007faf0f7475e4 in __new_sem_wait_slow (sem=0x55ff14b35fc0 SigHandler::Init()::waitSemaphore, abstime=0x0) at sem_waitcommon.c:181 #3 0x000055ff143a61a3 in PSemaphore::Wait() () #4 0x000055ff143c4c91 in SignalDetectionThread(void*) () #5 0x00007faf0f73f424 in start_thread (arg=0x7faf0e675700) at pthread_create.c:333 #6 0x00007faf0e75e9bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
Thread 1 (Thread 0x7faf0fb49740 (LWP 29440)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x000055ff143a604e in PCondVar::WaitFor(PLock*, unsigned int) () #2 0x000055ff143b8c9f in Processes::BeginRootThread(PolyObject*) () #3 0x000055ff143aaf13 in polymain () #4 0x00007faf0e6962b1 in __libc_start_main (main=0x55ff13f15dc0 <main>, argc=1, argv=0x7ffe94073258, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe94073248) at ../csu/libc-start.c:291 #5 0x000055ff13f1661a in _start ()
Any ideas? This is on Debian amd64 unstable, but I've seen it on non-x86 architectures too with the latest version. Interestingly I can't seem to reproduce it on macOS.
Regards, James
On 21 Feb 2017, at 12:48, David Matthews <David.Matthews at prolingua.co.uk> wrote:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
David _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
Hi James, I have access to a few machines but I don't think there's a PowerPC among them. I don't know if it's possible to install qemu in Windows and then run a PowerPC virtual machine in that. I currently use VirtualBox to run various flavours of Linux and FreeBSD but of course that only works for X86. If you can get me access to a real machine that would certainly help.
I've already prepared a release of 5.7 and I'm inclined to go ahead with that anyway. There will almost certainly be other bug fixes to include so it's likely that 5.7.1 won't be that far ahead.
Regards, David
On 21/03/2017 13:08, James Clarke wrote:
Hi David, I can reproduce this (or at least a very similar issue) seemingly every time on 32-bit PowerPC. All three of my uploads to Debian failed to build on it (across different machines) and I can reproduce it on another box. It happens with both jessie and unstable; below is the state of all the threads when I built it on unstable with two calls to "make compiler" followed by a "make check" (though ./poly --script Tests/Succeed/Test166.ML also hangs, so the test harness and running other tests first is irrelevant). Do you have access to a PowerPC machine you can put Debian on? If not I can probably arrange getting you remote access to one.
Regards, James
Hi David, Qemu in Windows should be doable, but it will be painfully slow.
I have spun up a PowerPC VM for you; please mail me your SSH key(s) and desired username, and I will give you the login details.
Issues I'm seeing:
1. libffi/src/powerpc/ffi_powerpc.h is missing (should have been added as part of f1f5ede), but the Debian package is building with --with-system-libffi, so you'll need to use that
2. Running "./configure --build=powerpc-linux-gnu --with-system-libffi && make compiler && make compiler && ./poly --script Tests/Succeed/Test166.ML" hangs on the test (You need to manually give --build since config.guess sees the 64-bit kernel and assumes it's building for 64-bit PowerPC)
3. Some 64-bit big endian builds have been segfaulting on the first "make compiler":
Making VALUEOPSSIG /bin/bash: line 1: 15571 Segmentation fault ./poly --error-exit < mlsource/BuildExport.sml
I'm setting up a ppc64 chroot now to see if that can reproduced on this particular machine.
Regards, James
On 21 Mar 2017, at 13:54, David Matthews <David.Matthews at prolingua.co.uk> wrote:
Hi James, I have access to a few machines but I don't think there's a PowerPC among them. I don't know if it's possible to install qemu in Windows and then run a PowerPC virtual machine in that. I currently use VirtualBox to run various flavours of Linux and FreeBSD but of course that only works for X86. If you can get me access to a real machine that would certainly help.
I've already prepared a release of 5.7 and I'm inclined to go ahead with that anyway. There will almost certainly be other bug fixes to include so it's likely that 5.7.1 won't be that far ahead.
Regards, David
On 21/03/2017 13:08, James Clarke wrote:
Hi David, I can reproduce this (or at least a very similar issue) seemingly every time on 32-bit PowerPC. All three of my uploads to Debian failed to build on it (across different machines) and I can reproduce it on another box. It happens with both jessie and unstable; below is the state of all the threads when I built it on unstable with two calls to "make compiler" followed by a "make check" (though ./poly --script Tests/Succeed/Test166.ML also hangs, so the test harness and running other tests first is irrelevant). Do you have access to a PowerPC machine you can put Debian on? If not I can probably arrange getting you remote access to one.
Regards, James
On 21/02/17 13:48, David Matthews wrote:
The latest version, provisionally called 5.6.1, has had very little change for several months. I'm not aware of any show-stoppers so I think it would be a good time to make a release. Because there have been some major changes I was planning to call it 5.7. This is the last chance to do any last tests before the release.
We have strange memory management problems with Isabelle.
I've been using repository versions of Poly/ML privately during the past few months, without seeing such problems. Only the official switch in http://isabelle.in.tum.de/repos/isabelle/rev/42b92fa72a51 exposed that, ranging from main HOL not building on an underpowered macOS machine to some big AFP entry not building on an overpowered Linux box.
For the moment, I have switched the Isabelle setup back to stable Poly/ML 5.6 (see http://isabelle.in.tum.de/repos/isabelle/rev/18f3d341f8c0).
I will come back on that when I've investigated the situation further.
Makarius
On 24/02/17 13:26, Makarius wrote:
We have strange memory management problems with Isabelle.
I've been using repository versions of Poly/ML privately during the past few months, without seeing such problems. Only the official switch in http://isabelle.in.tum.de/repos/isabelle/rev/42b92fa72a51 exposed that, ranging from main HOL not building on an underpowered macOS machine to some big AFP entry not building on an overpowered Linux box.
For the moment, I have switched the Isabelle setup back to stable Poly/ML 5.6 (see http://isabelle.in.tum.de/repos/isabelle/rev/18f3d341f8c0).
I will come back on that when I've investigated the situation further.
I've now spent some time with it. Here are some preliminary observations for Isabelle/002b4c8c366e and AFP/d0bd0f0fe3b2 and Poly/ML 5.6 vs. Poly/ML pre-5.7 (6307085deb18):
(1) Poly/ML pre-5.7 requires a bit more heap space (tested for HOL, HOL-Library, HOL-Analysis), especially when running in parallel. This might explain the failure building main HOL on the small macOS machine: it probably runs into a situation where heap compaction no longer works and the ML process interrupts all threads.
To address that, I have fine-tuned the defaults for parallel proofs, leading up to Isabelle/05f1b5342298, with some hope that it might improve the situation in general: less waste of CPU and memory on small machines.
(2) The big problem is AFP/Iptables_Semantics_Examples. Here is the timing with Poly/ML 5.6 on lxbroy10, an old AMD machine that is relatively slow:
Finished Iptables_Semantics_Examples (4:35:13 elapsed time, 23:35:08 cpu time, factor 5.14)
With Poly/ML 5.7 it quickly runs into memory problems. See the included PNG images for comparison.
That session is definitely quite ambitious, not to say insane. It contains lots of invocations of the "eval" proof method, which means dynamic compilation of ML from HOL specifications, and throwing away the result.
My current guess is that it is a problem of compiled ML code that is no longer garbage-collected.
Is there a way to measure the size of this persistent ML code?
Is there a way to invoke the Poly/ML compiler in interpreted mode via some flag?
See also http://isabelle.in.tum.de/repos/isabelle/file/1803a9787eca/src/Pure/ML/ml_co... where Poly/ML is invoked in Isabelle/ML.
Makarius
On 27/02/17 23:55, Makarius wrote:
On 24/02/17 13:26, Makarius wrote:
We have strange memory management problems with Isabelle.
(1) Poly/ML pre-5.7 requires a bit more heap space (tested for HOL, HOL-Library, HOL-Analysis), especially when running in parallel. This might explain the failure building main HOL on the small macOS machine: it probably runs into a situation where heap compaction no longer works and the ML process interrupts all threads.
Here are some more measurements for the plain HOL build problem on my new MacMini. Current Isabelle/36c650d1a90d it usually works, even on that small macOS 10.12 Sierra machine, but it requires much more memory than usual.
The included a.png vs. b.png illustrate that, but they have been produced on a different machine (macbroy2), which runs Mac OS X 10.9 Mavericks.
Here are the Isabelle settings to reproduce that:
##enable this for "b.png" #init_component "$HOME/.isabelle/contrib/polyml-5.7-20170217"
ML_OPTIONS="-H 500 --gcthreads=2" ISABELLE_BUILD_OPTIONS="threads=2"
The session is then built as follows:
$ isabelle build HOL
The low number of threads is important. With 4 it generally works better.
I've done the same test on a virtual Ubuntu 16.04 with 2 cores + 8 GB, and there is no big difference in heap usage.
I am unsure if this is really a matter of Poly/ML 5.6 vs. 5.7: on Mac OS X, we have seen many heap irregularities in the past few years, i.e. situations where heap compaction does not work anymore and the process is interrupted.
Makarius
On 27/02/2017 22:55, Makarius wrote:
On 24/02/17 13:26, Makarius wrote:
We have strange memory management problems with Isabelle.
(1) Poly/ML pre-5.7 requires a bit more heap space (tested for HOL, HOL-Library, HOL-Analysis), especially when running in parallel. This might explain the failure building main HOL on the small macOS machine: it probably runs into a situation where heap compaction no longer works and the ML process interrupts all threads.
To address that, I have fine-tuned the defaults for parallel proofs, leading up to Isabelle/05f1b5342298, with some hope that it might improve the situation in general: less waste of CPU and memory on small machines.
(2) The big problem is AFP/Iptables_Semantics_Examples. Here is the timing with Poly/ML 5.6 on lxbroy10, an old AMD machine that is relatively slow:
Finished Iptables_Semantics_Examples (4:35:13 elapsed time, 23:35:08 cpu time, factor 5.14)
With Poly/ML 5.7 it quickly runs into memory problems. See the included PNG images for comparison.
That session is definitely quite ambitious, not to say insane. It contains lots of invocations of the "eval" proof method, which means dynamic compilation of ML from HOL specifications, and throwing away the result.
My current guess is that it is a problem of compiled ML code that is no longer garbage-collected.
Is there a way to measure the size of this persistent ML code?
Is there a way to invoke the Poly/ML compiler in interpreted mode via some flag?
The current version does garbage collect code; it's just that it only happens at a major GC. Previously when code was part of the general heap a short-lived code cell would be garbage-collected by a minor GC. It could be that this is problem or it could be that there is a bug which is resulting in code not being properly collected.
It isn't possible to use the current byte-code interpreter with the machine-code version. The idea I had for interpretation was to interpret at the level of the code-tree, essentially one step on from the parse-tree. Each instruction of top-level code without a loop is executed only once and so it's a complete waste of resources to optimise it and generate machine code, but that's what happens at the moment. It should be fairly easy to add an interpretation step since something like that already happens for expressions involving constants.
I'm inclined to release the current version of git master as 5.7 and then look into this and other issues.
David
On 01/03/17 13:55, David Matthews wrote:
On 24/02/17 13:26, Makarius wrote: My current guess is that it is a problem of compiled ML code that is no longer garbage-collected.
The current version does garbage collect code; it's just that it only happens at a major GC. Previously when code was part of the general heap a short-lived code cell would be garbage-collected by a minor GC. It could be that this is problem or it could be that there is a bug which is resulting in code not being properly collected.
I'm inclined to release the current version of git master as 5.7 and then look into this and other issues.
OK, it merely means that we need to skip this version for official Isabelle use. I will continue testing Poly/ML repository versions privately.
Makarius
On 01/03/2017 13:31, Makarius wrote:
On 01/03/17 13:55, David Matthews wrote:
On 24/02/17 13:26, Makarius wrote: My current guess is that it is a problem of compiled ML code that is no longer garbage-collected.
The current version does garbage collect code; it's just that it only happens at a major GC. Previously when code was part of the general heap a short-lived code cell would be garbage-collected by a minor GC. It could be that this is problem or it could be that there is a bug which is resulting in code not being properly collected.
I'm inclined to release the current version of git master as 5.7 and then look into this and other issues.
OK, it merely means that we need to skip this version for official Isabelle use. I will continue testing Poly/ML repository versions privately.
That's understandable. Adding support for interpretation is going to be a bit of work and until it's done and tested there's no way of being sure it will solve this problem. I'd prefer not to delay the release.
David
On 02/03/17 14:22, David Matthews wrote:
Adding support for interpretation is going to be a bit of work and until it's done and tested there's no way of being sure it will solve this problem. I'd prefer not to delay the release.
Interpretation will not really solve the "by eval" problem: code generation produces huge ML modules and expects that they run efficiently. I've proposed that merely as a measure of last resort.
Since you say that code GC should basically work (again), this is what really counts.
Makarius
David,
I?ve just pulled the latest source. I am experimenting with how to build ProofPower if the installed Poly/ML has fixed magnitude integers. I get a bus error when I do:
PolyML.loadModule "modules/IntAsIntInf/IntAsIntInf?;
(By the way, why is the configure option called ?enable-intinf-as-int but it?s the other way round in the module name?)
Regards,
Rob.
On 04/03/2017 16:42, Rob Arthan wrote:
I?ve just pulled the latest source. I am experimenting with how to build ProofPower if the installed Poly/ML has fixed magnitude integers. I get a bus error when I do:
PolyML.loadModule "modules/IntAsIntInf/IntAsIntInf?;
I've just tried this. I was getting an infinite loop rather than a bus error and only on 64-bits. I've pushed a fix for that. Has it sorted out the bus error?
(By the way, why is the configure option called ?enable-intinf-as-int but it?s the other way round in the module name?)
That is inconsistent. I'm not sure which is better.
Regards, David
David,
On 5 Mar 2017, at 19:23, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 04/03/2017 16:42, Rob Arthan wrote:
I?ve just pulled the latest source. I am experimenting with how to build ProofPower if the installed Poly/ML has fixed magnitude integers. I get a bus error when I do:
PolyML.loadModule "modules/IntAsIntInf/IntAsIntInf?;
I've just tried this. I was getting an infinite loop rather than a bus error and only on 64-bits. I've pushed a fix for that. Has it sorted out the bus error?
I should have said that I was doing my experiments on Mac OS (Sierra 10.12.3). I?ve just tried it on a Ubuntu 16.04 VirtualBox VM and there I see the same behaviour as you: infinite loop before your fix and OK after. On Mac OS I am still getting the bus error:
rda]- ./poly Poly/ML 5.6.1 Testing (Git version v5.6-835-geec20d3)
PolyML.loadModule "modules/IntAsIntInf/IntAsIntInf" ;
Bus error: 10
I should say that this is not a stopper for me as I am currently planning to accommodate the choice that was made when Poly/ML was built rather than try to override it with the module.
(By the way, why is the configure option called ?enable-intinf-as-int but it?s the other way round in the module name?)
That is inconsistent. I'm not sure which is better.
Nor me! If you want to make it consistent, I suggest you change whichever is least work.
Regards,
Rob.
Rob, I've committed a fix for this and it now seems to work on Mac OS X. It turned out the problem was that the code of the module was being loaded into the normal heap which no longer has execute permission rather than the code area. It looks as though Linux, unlike Mac OS X and Windows, ignores the lack of execute permission.
The module name has also changed to IntInfAsInt.
Regards, David
On 05/03/2017 20:46, Rob Arthan wrote:
David,
On 5 Mar 2017, at 19:23, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 04/03/2017 16:42, Rob Arthan wrote:
I?ve just pulled the latest source. I am experimenting with how to build ProofPower if the installed Poly/ML has fixed magnitude integers. I get a bus error when I do:
PolyML.loadModule "modules/IntAsIntInf/IntAsIntInf?;
I've just tried this. I was getting an infinite loop rather than a bus error and only on 64-bits. I've pushed a fix for that. Has it sorted out the bus error?
I should have said that I was doing my experiments on Mac OS (Sierra 10.12.3). I?ve just tried it on a Ubuntu 16.04 VirtualBox VM and there I see the same behaviour as you: infinite loop before your fix and OK after. On Mac OS I am still getting the bus error:
rda]- ./poly Poly/ML 5.6.1 Testing (Git version v5.6-835-geec20d3)
PolyML.loadModule "modules/IntAsIntInf/IntAsIntInf" ;
Bus error: 10
I should say that this is not a stopper for me as I am currently planning to accommodate the choice that was made when Poly/ML was built rather than try to override it with the module.
(By the way, why is the configure option called ?enable-intinf-as-int but it?s the other way round in the module name?)
That is inconsistent. I'm not sure which is better.
Nor me! If you want to make it consistent, I suggest you change whichever is least work.
Regards,
Rob.
-
David.Matthews＠prolingua.co.uk -
jrtc27＠jrtc27.com -
kostirya＠gmail.com -
makarius＠sketis.net -
rda＠lemma-one.com