[jira] [Commented] (PROTON-2271) Valgrind failure in c_threaderciser test
[
https://issues.apache.org/jira/browse/PROTON-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182171#comment-17182171
]
Jiri Daněk commented on PROTON-2271:
Another failure from PROTON-2270
{noformat}
==109052== 92,085 (1,408 direct, 90,677 indirect) bytes in 1 blocks are
definitely lost in loss record 139 of 139
==109052==at 0x483EB95: calloc (vg_replace_malloc.c:760)
==109052==by 0x4854CCD: pn_listener (epoll.c:1617)
==109052==by 0x10A748: listener_ctx_new (threaderciser.c:265)
==109052==by 0x10A748: lpool_listen (threaderciser.c:283)
==109052==by 0x10B4F9: main (threaderciser.c:566)
{noformat}
> Valgrind failure in c_threaderciser test
>
>
> Key: PROTON-2271
> URL: https://issues.apache.org/jira/browse/PROTON-2271
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.31.0
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Priority: Major
>
> From PROTON-2270 research
> {code:java}
> 7: Test timeout computed to be: 6000
> 7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
> connect, close-connect, wake, timeout, cancel-timeout]
> 7: ==7576== 2,320 (1,408 direct, 912 indirect) bytes in 1 blocks are
> definitely lost in loss record 148 of 156
> 7: ==7576==at 0x483BB1A: calloc (vg_replace_malloc.c:760)
> 7: ==7576==by 0x4854315: pn_listener (epoll.c:1617)
> 7: ==7576==by 0x402C9C: listener_ctx_new (threaderciser.c:264)
> 7: ==7576==by 0x402C9C: lpool_listen.part.0 (threaderciser.c:282)
> 7: ==7576==by 0x40338B: lpool_listen (threaderciser.c:379)
> 7: ==7576==by 0x40338B: global_do_stuff (threaderciser.c:379)
> 7: ==7576==by 0x40360F: handle (threaderciser.c:414)
> 7: ==7576==by 0x40360F: proactor_thread (threaderciser.c:476)
> 7: ==7576==by 0x48D34E1: start_thread (pthread_create.c:479)
> 7: ==7576==by 0x49ED6C2: clone (clone.S:95)
> 7: ==7576==
> 7: ==7576== 95,957 (1,128 direct, 94,829 indirect) bytes in 1 blocks are
> definitely lost in loss record 156 of 156
> 7: ==7576==at 0x483980B: malloc (vg_replace_malloc.c:307)
> 7: ==7576==by 0x402C94: listener_ctx_new (threaderciser.c:263)
> 7: ==7576==by 0x402C94: lpool_listen.part.0 (threaderciser.c:282)
> 7: ==7576==by 0x40338B: lpool_listen (threaderciser.c:379)
> 7: ==7576==by 0x40338B: global_do_stuff (threaderciser.c:379)
> 7: ==7576==by 0x40368F: user_thread (threaderciser.c:397)
> 7: ==7576==by 0x48D34E1: start_thread (pthread_create.c:479)
> 7: ==7576==by 0x49ED6C2: clone (clone.S:95)
> 7: ==7576==
> 1/1 Test #7: c-threaderciser ..***Failed5.75 sec
> 0% tests passed, 1 tests failed out of 1
> Total Test time (real) = 5.76 sec
> The following tests FAILED:
> 7 - c-threaderciser (Failed)
> Errors while running CTest{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182165#comment-17182165
]
Jiri Daněk edited comment on PROTON-2270 at 8/21/20, 10:10 PM:
---
Still, I haven't yet found an upper time bound for the c-threaderciser under
valgrind. On a machine, where the test normally runs in between 5 to 50
seconds, I saw
{noformat}
7: Test command: /usr/bin/python
"/home/jdanek/repos/qpid/qpid-proton/scripts/env.py" "--"
"TEST_EXE_PREFIX=/usr/bin/valgrind --tool=memcheck --leak-check=full
--error-exitcode=42 --quiet
--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/usr/bin/valgrind" "--tool=memcheck" "--leak-check=full" "--error-exitcode=42"
"--quiet"
"--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/home/jdanek/repos/qpid/qpid-proton/cmake-build-debug/c/tests/c-threaderciser"
7: Test timeout computed to be: 900
7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
connect, close-connect, wake, timeout, cancel-timeout]
Test #7: c-threaderciser ..***Timeout 900.10 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 968.50 sec
{noformat}
On yet another machine, I saw it timeout even with 1500 second limit.
The problem is, I don't know how to take a backtrace of a program running in
valgrind, to see if it is just running slow, or it will never terminate.
{noformat}
Attaching to process 5709
[New LWP 5737]
[New LWP 5741]
[New LWP 5743]
vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
171 m_syswrap/syscall-amd64-linux.S: No such file or directory.
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100330cd58,
tst=0x1002008410, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=1, trc=trc@entry=73)
at m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=1, trc=73)
at m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=1)
at m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=1)
at m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:154
#7 0x in ?? ()
(gdb) thread
[Current thread is 1 (LWP 5709)]
(gdb) info threads
Id Target Id Frame
* 1LWP 5709 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
2LWP 5737 "memcheck-amd64-" 0x001003b64110 in ?? ()
3LWP 5741 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
4LWP 5743 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
(gdb) thread 2
[Switching to thread 2 (LWP 5737)]
#0 0x001003b64110 in ?? ()
(gdb) bt
#0 0x001003b64110 in ?? ()
#1 0x0010064f6f10 in ?? ()
#2 0x592a95e8 in ?? ()
#3 0x0010064f6ef8 in ?? ()
#4 0x0010064f6f10 in ?? ()
#5 0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (LWP 5741)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100706bd48,
tst=0x1002012c70, syscallno=232) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=7, trc=trc@entry=73) at
m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=7, trc=73) at
m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=7) at
m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=7) at
m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=7) at m_syswrap/syswrap-linux.c:154
#7 0x580ee6cb in vgModuleLocal_start_thread_NORETURN (arg=) at m_syswrap/syswrap-linux.c:328
#8 0x580af95e in do_syscall_clone_amd64_linux ()
#9 0xdeadbeefdeadbeef in ?? ()
#10 0xdeadbeefdeadbeef in ?? ()
#11 0xdeadbeefdeadbeef in ?? ()
#12 0xdeadbeefdeadbeef in ?? ()
#13 0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (LWP 5743)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x1007673d48,
tst=0x1002016490, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=9, trc=trc@entry=73) at
m_syswrap/sysw
[jira] [Comment Edited] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182165#comment-17182165
]
Jiri Daněk edited comment on PROTON-2270 at 8/21/20, 9:57 PM:
--
Still, I haven't yet found an upper time bound for the c-threaderciser under
valgrind. On a machine, where the test normally runs in between 5 to 50
seconds, I saw
{noformat}
7: Test command: /usr/bin/python
"/home/jdanek/repos/qpid/qpid-proton/scripts/env.py" "--"
"TEST_EXE_PREFIX=/usr/bin/valgrind --tool=memcheck --leak-check=full
--error-exitcode=42 --quiet
--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/usr/bin/valgrind" "--tool=memcheck" "--leak-check=full" "--error-exitcode=42"
"--quiet"
"--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/home/jdanek/repos/qpid/qpid-proton/cmake-build-debug/c/tests/c-threaderciser"
7: Test timeout computed to be: 900
7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
connect, close-connect, wake, timeout, cancel-timeout]
Test #7: c-threaderciser ..***Timeout 900.10 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 968.50 sec
{noformat}
On yet another machine, I saw it timeout even with 1500 second limit.
The problem is, I don't know how to take a backtrace of a program running in
valgrind, to see if it is just running slow, or it will never terminate.
{noformat}
Attaching to process 5709
[New LWP 5737]
[New LWP 5741]
[New LWP 5743]
vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
171 m_syswrap/syscall-amd64-linux.S: No such file or directory.
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100330cd58,
tst=0x1002008410, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=1, trc=trc@entry=73)
at m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=1, trc=73)
at m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=1)
at m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=1)
at m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:154
#7 0x in ?? ()
(gdb) thread
[Current thread is 1 (LWP 5709)]
(gdb) info threads
Id Target Id Frame
* 1LWP 5709 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
2LWP 5737 "memcheck-amd64-" 0x001003b64110 in ?? ()
3LWP 5741 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
4LWP 5743 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
(gdb) thread 2
[Switching to thread 2 (LWP 5737)]
#0 0x001003b64110 in ?? ()
(gdb) bt
#0 0x001003b64110 in ?? ()
#1 0x0010064f6f10 in ?? ()
#2 0x592a95e8 in ?? ()
#3 0x0010064f6ef8 in ?? ()
#4 0x0010064f6f10 in ?? ()
#5 0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (LWP 5741)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100706bd48,
tst=0x1002012c70, syscallno=232) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=7, trc=trc@entry=73) at
m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=7, trc=73) at
m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=7) at
m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=7) at
m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=7) at m_syswrap/syswrap-linux.c:154
#7 0x580ee6cb in vgModuleLocal_start_thread_NORETURN (arg=) at m_syswrap/syswrap-linux.c:328
#8 0x580af95e in do_syscall_clone_amd64_linux ()
#9 0xdeadbeefdeadbeef in ?? ()
#10 0xdeadbeefdeadbeef in ?? ()
#11 0xdeadbeefdeadbeef in ?? ()
#12 0xdeadbeefdeadbeef in ?? ()
#13 0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (LWP 5743)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x1007673d48,
tst=0x1002016490, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=9, trc=trc@entry=73) at
m_syswrap/syswra
[jira] [Comment Edited] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182165#comment-17182165
]
Jiri Daněk edited comment on PROTON-2270 at 8/21/20, 9:57 PM:
--
Still, I haven't yet found an upper time bound for the c-threaderciser under
valgrind. On a machine, where the test normally runs in between 5 to 50
seconds, I saw
{noformat}
7: Test command: /usr/bin/python
"/home/jdanek/repos/qpid/qpid-proton/scripts/env.py" "--"
"TEST_EXE_PREFIX=/usr/bin/valgrind --tool=memcheck --leak-check=full
--error-exitcode=42 --quiet
--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/usr/bin/valgrind" "--tool=memcheck" "--leak-check=full" "--error-exitcode=42"
"--quiet"
"--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/home/jdanek/repos/qpid/qpid-proton/cmake-build-debug/c/tests/c-threaderciser"
7: Test timeout computed to be: 900
7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
connect, close-connect, wake, timeout, cancel-timeout]
Test #7: c-threaderciser ..***Timeout 900.10 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 968.50 sec
{nofomat}
On yet another machine, I saw it timeout even with 1500 second limit.
The problem is, I don't know how to take a backtrace of a program running in
valgrind, to see if it is just running slow, or it will never terminate.
{noformat}
Attaching to process 5709
[New LWP 5737]
[New LWP 5741]
[New LWP 5743]
vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
171 m_syswrap/syscall-amd64-linux.S: No such file or directory.
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100330cd58,
tst=0x1002008410, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=1, trc=trc@entry=73)
at m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=1, trc=73)
at m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=1)
at m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=1)
at m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:154
#7 0x in ?? ()
(gdb) thread
[Current thread is 1 (LWP 5709)]
(gdb) info threads
Id Target Id Frame
* 1LWP 5709 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
2LWP 5737 "memcheck-amd64-" 0x001003b64110 in ?? ()
3LWP 5741 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
4LWP 5743 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
(gdb) thread 2
[Switching to thread 2 (LWP 5737)]
#0 0x001003b64110 in ?? ()
(gdb) bt
#0 0x001003b64110 in ?? ()
#1 0x0010064f6f10 in ?? ()
#2 0x592a95e8 in ?? ()
#3 0x0010064f6ef8 in ?? ()
#4 0x0010064f6f10 in ?? ()
#5 0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (LWP 5741)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100706bd48,
tst=0x1002012c70, syscallno=232) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=7, trc=trc@entry=73) at
m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=7, trc=73) at
m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=7) at
m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=7) at
m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=7) at m_syswrap/syswrap-linux.c:154
#7 0x580ee6cb in vgModuleLocal_start_thread_NORETURN (arg=) at m_syswrap/syswrap-linux.c:328
#8 0x580af95e in do_syscall_clone_amd64_linux ()
#9 0xdeadbeefdeadbeef in ?? ()
#10 0xdeadbeefdeadbeef in ?? ()
#11 0xdeadbeefdeadbeef in ?? ()
#12 0xdeadbeefdeadbeef in ?? ()
#13 0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (LWP 5743)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x1007673d48,
tst=0x1002016490, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=9, trc=trc@entry=73) at
m_syswrap/syswrap
[jira] [Commented] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182165#comment-17182165
]
Jiri Daněk commented on PROTON-2270:
Still, I haven't yet found an upper time bound for the c-threaderciser under
valgrind. On a machine, where the test normally runs in between 5 to 50
seconds, I saw
{noformat}
7: Test command: /usr/bin/python
"/home/jdanek/repos/qpid/qpid-proton/scripts/env.py" "--"
"TEST_EXE_PREFIX=/usr/bin/valgrind --tool=memcheck --leak-check=full
--error-exitcode=42 --quiet
--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/usr/bin/valgrind" "--tool=memcheck" "--leak-check=full" "--error-exitcode=42"
"--quiet"
"--suppressions=/home/jdanek/repos/qpid/qpid-proton/tests/valgrind.supp"
"/home/jdanek/repos/qpid/qpid-proton/cmake-build-debug/c/tests/c-threaderciser"
7: Test timeout computed to be: 900
7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
connect, close-connect, wake, timeout, cancel-timeout]
Test #7: c-threaderciser ..***Timeout 900.10 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 968.50 sec
{nofomat}
On yet another machine, I saw it timeout even with 1500 second limit.
The problem is, I don't know how to take a backtrace of a program running in
valgrind, to see if it is just running slow, or it will never terminate.
{noformat}
Attaching to process 5709
[New LWP 5737]
[New LWP 5741]
[New LWP 5743]
vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
171 m_syswrap/syscall-amd64-linux.S: No such file or directory.
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK ()
at m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100330cd58,
tst=0x1002008410, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=1, trc=trc@entry=73)
at m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=1, trc=73)
at m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=1)
at m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=1)
at m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:154
#7 0x in ?? ()
(gdb) thread
[Current thread is 1 (LWP 5709)]
(gdb) info threads
Id Target Id Frame
* 1LWP 5709 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
2LWP 5737 "memcheck-amd64-" 0x001003b64110 in ?? ()
3LWP 5741 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
4LWP 5743 "memcheck-amd64-" vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
(gdb) thread 2
[Switching to thread 2 (LWP 5737)]
#0 0x001003b64110 in ?? ()
(gdb) bt
#0 0x001003b64110 in ?? ()
#1 0x0010064f6f10 in ?? ()
#2 0x592a95e8 in ?? ()
#3 0x0010064f6ef8 in ?? ()
#4 0x0010064f6f10 in ?? ()
#5 0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (LWP 5741)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x100706bd48,
tst=0x1002012c70, syscallno=232) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=7, trc=trc@entry=73) at
m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_syscall (tid=tid@entry=7, trc=73) at
m_scheduler/scheduler.c:1208
#4 0x5809db34 in vgPlain_scheduler (tid=tid@entry=7) at
m_scheduler/scheduler.c:1526
#5 0x580ee3d6 in thread_wrapper (tidW=7) at
m_syswrap/syswrap-linux.c:101
#6 run_a_thread_NORETURN (tidW=7) at m_syswrap/syswrap-linux.c:154
#7 0x580ee6cb in vgModuleLocal_start_thread_NORETURN (arg=) at m_syswrap/syswrap-linux.c:328
#8 0x580af95e in do_syscall_clone_amd64_linux ()
#9 0xdeadbeefdeadbeef in ?? ()
#10 0xdeadbeefdeadbeef in ?? ()
#11 0xdeadbeefdeadbeef in ?? ()
#12 0xdeadbeefdeadbeef in ?? ()
#13 0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (LWP 5743)]
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
171 in m_syswrap/syscall-amd64-linux.S
(gdb) bt
#0 vgModuleLocal_do_syscall_for_client_WRK () at
m_syswrap/syscall-amd64-linux.S:171
#1 0x580a0280 in do_syscall_for_client (syscall_mask=0x1007673d48,
tst=0x1002016490, syscallno=202) at m_syswrap/syswrap-main.c:2015
#2 vgPlain_client_syscall (tid=tid@entry=9, trc=trc@entry=73) at
m_syswrap/syswrap-main.c:2015
#3 0x5809b9eb in handle_sysca
[jira] [Resolved] (PROTON-2272) [c] Threadercizer build causes warnings and hence build failures on 32 bit builds
[
https://issues.apache.org/jira/browse/PROTON-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-2272.
-
Resolution: Fixed
> [c] Threadercizer build causes warnings and hence build failures on 32 bit
> builds
> -
>
> Key: PROTON-2272
> URL: https://issues.apache.org/jira/browse/PROTON-2272
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.32.0
>Reporter: Andrew Stitcher
>Priority: Minor
> Labels: release-notes
> Fix For: proton-c-0.33.0
>
>
> When building threadercizer for a 32 bit architecture using the default
> setting will cause a warning will be treated as an error:
> (this is from a build on Raspbian)
> {noformat}
> [1/5] Building C object
> c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o
> FAILED: c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o
> /usr/bin/cc -I/home/andrew/Coding/qpid-proton/src/c/include
> -I/home/andrew/Coding/qpid-proton/src/c/src -Ic/include -Ic/src -Ic/tests
> -I/home/andrew/Coding/qpid-proton/src/tests/include -fvisibility=hidden -O2
> -g -DNDEBUG-Werror -Wall -pedantic-errors -Wstrict-prototypes -Wvla
> -Wsign-compare -Wwrite-strings -std=c99 -MD -MT
> c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o -MF
> c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o.d -o
> c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o -c
> /home/andrew/Coding/qpid-proton/src/c/tests/threaderciser.c
> /home/andrew/Coding/qpid-proton/src/c/tests/threaderciser.c: In function
> ‘debug_impl’:
> /home/andrew/Coding/qpid-proton/src/c/tests/threaderciser.c:97:45: error:
> format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has
> type ‘unsigned int’ [-Werror=format=]
>i += assert_no_err(snprintf(i, end-i, "(%lx) ", (uintptr_t)
> pthread_self()));
>~~^ ~~
>%x
> cc1: all warnings being treated as errors
> {noformat}
> This issue has already been fixed for 0.33.
> It has a good workaround in 0.32 by giving -DENABLE_WARNING_ERROR=off to
> cmake. This should be release noted for 0.32
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2272) [c] Threadercizer build causes warnings and hence build failures on 32 bit builds
Andrew Stitcher created PROTON-2272:
---
Summary: [c] Threadercizer build causes warnings and hence build
failures on 32 bit builds
Key: PROTON-2272
URL: https://issues.apache.org/jira/browse/PROTON-2272
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-c-0.32.0
Reporter: Andrew Stitcher
Fix For: proton-c-0.33.0
When building threadercizer for a 32 bit architecture using the default setting
will cause a warning will be treated as an error:
(this is from a build on Raspbian)
{noformat}
[1/5] Building C object c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o
FAILED: c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o
/usr/bin/cc -I/home/andrew/Coding/qpid-proton/src/c/include
-I/home/andrew/Coding/qpid-proton/src/c/src -Ic/include -Ic/src -Ic/tests
-I/home/andrew/Coding/qpid-proton/src/tests/include -fvisibility=hidden -O2 -g
-DNDEBUG-Werror -Wall -pedantic-errors -Wstrict-prototypes -Wvla
-Wsign-compare -Wwrite-strings -std=c99 -MD -MT
c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o -MF
c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o.d -o
c/tests/CMakeFiles/c-threaderciser.dir/threaderciser.c.o -c
/home/andrew/Coding/qpid-proton/src/c/tests/threaderciser.c
/home/andrew/Coding/qpid-proton/src/c/tests/threaderciser.c: In function
‘debug_impl’:
/home/andrew/Coding/qpid-proton/src/c/tests/threaderciser.c:97:45: error:
format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has
type ‘unsigned int’ [-Werror=format=]
i += assert_no_err(snprintf(i, end-i, "(%lx) ", (uintptr_t) pthread_self()));
~~^ ~~
%x
cc1: all warnings being treated as errors
{noformat}
This issue has already been fixed for 0.33.
It has a good workaround in 0.32 by giving -DENABLE_WARNING_ERROR=off to cmake.
This should be release noted for 0.32
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1743) Add HTTP/2 support to the router
[ https://issues.apache.org/jira/browse/DISPATCH-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182147#comment-17182147 ] ASF subversion and git services commented on DISPATCH-1743: --- Commit ad024e47f1d466f17269d47d87b1dd56caf72670 in qpid-dispatch's branch refs/heads/dev-protocol-adaptors from Ganesh Murthy [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=ad024e4 ] DISPATCH-1743 - Use new body data API to convert AMQP to HTTP and vice versa" > Add HTTP/2 support to the router > > > Key: DISPATCH-1743 > URL: https://issues.apache.org/jira/browse/DISPATCH-1743 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add new feature to support HTTP/2 protocol on the router. > This feature involves the introduction of new entities to the router called > httpListener and httpConnector. The httpListener will accept HTTP/2 > connections and make an outbound connection using the httpConnector. > The router will use AMQP to route the messages. The router will act as a > protocol bridge. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182114#comment-17182114
]
Charles E. Rolke commented on PROTON-2270:
--
>>> In the CTest world, tests are free to set their own timeouts, overriding
>>> the default, if they "think they know better".
For users without a local build wherein they can edit cmake and rebuild, the
cli switch is the only way to go. It is possible to allow the ctest command
line user set the timeout. For instance, in qpid-dispatch:
{code:java}
> ctest -VV --timeout 1234 -R s_policy$
...
test 24
Start 24: system_tests_policy
24: Test command: /usr/bin/python
"/home/chug/git/qpid-dispatch/build/tests/run.py" "-m" "unittest" "-v"
"system_tests_policy"
24: Test timeout computed to be: 1234
...
{code}
> Threaderciser test does not honor ctest '--timeout' switch
> --
>
> Key: PROTON-2270
> URL: https://issues.apache.org/jira/browse/PROTON-2270
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.31.0
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Priority: Major
>
> Command line
> {code:java}
> > ctest -VV --timeout 600 -R threader
> {code}
> runs the test with
> {code:java}
> ...
> Start 7: c-threaderciser
> ...
> 7: Test timeout computed to be: 120
> ...
> {code}
> The test should respect the ctest switch and run for 600 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1763) Policy attribute description improvements from qdstat man page
Charles E. Rolke created DISPATCH-1763: -- Summary: Policy attribute description improvements from qdstat man page Key: DISPATCH-1763 URL: https://issues.apache.org/jira/browse/DISPATCH-1763 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation, Management Agent Affects Versions: 1.13.0 Reporter: Charles E. Rolke Assignee: Charles E. Rolke Recent improvements for qdstat man page include improved descriptions of policy and vhost configuration attributes. The improved text should be folded back into the management schema. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1744) Add HTTP/1.1 support to the router
[ https://issues.apache.org/jira/browse/DISPATCH-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182038#comment-17182038 ] ASF subversion and git services commented on DISPATCH-1744: --- Commit b3ef84df7e5e2b52e7dc5fe0a33c9ee174d57cda in qpid-dispatch's branch refs/heads/dev-protocol-adaptors from Ganesh Murthy [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=b3ef84d ] DISPATCH-1744: Added libnghttp2-dev to travis.yml > Add HTTP/1.1 support to the router > -- > > Key: DISPATCH-1744 > URL: https://issues.apache.org/jira/browse/DISPATCH-1744 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ganesh Murthy >Assignee: Ken Giusti >Priority: Major > > Add new feature to support HTTP/1.1 protocol on the router. > This feature involves the introduction of new entities to the router called > httpListener and httpConnector. The httpListener will accept HTTP/1.1 > connections and make an outbound connection using the httpConnector. > The router will use AMQP to route the messages. The router will act as a > protocol bridge. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182001#comment-17182001
]
Jiri Daněk commented on PROTON-2270:
[~chug] Thanks. The timeout of 120, I chose that based on runs with
addresssanitizer, and on Travis timeouts like
https://travis-ci.org/github/apache/qpid-proton/jobs/693871917#L1795.
Maybe I've just completely failed to pick a suitable timeout. It has to
certainly be <600, otherwise Travis may kill the job.
> Threaderciser test does not honor ctest '--timeout' switch
> --
>
> Key: PROTON-2270
> URL: https://issues.apache.org/jira/browse/PROTON-2270
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.31.0
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Priority: Major
>
> Command line
> {code:java}
> > ctest -VV --timeout 600 -R threader
> {code}
> runs the test with
> {code:java}
> ...
> Start 7: c-threaderciser
> ...
> 7: Test timeout computed to be: 120
> ...
> {code}
> The test should respect the ctest switch and run for 600 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2271) Valgrind failure in c_threaderciser test
Charles E. Rolke created PROTON-2271:
Summary: Valgrind failure in c_threaderciser test
Key: PROTON-2271
URL: https://issues.apache.org/jira/browse/PROTON-2271
Project: Qpid Proton
Issue Type: Bug
Components: build
Affects Versions: proton-c-0.31.0
Environment: Fedora 31
Reporter: Charles E. Rolke
>From PROTON-2270 research
{code:java}
7: Test timeout computed to be: 6000
7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
connect, close-connect, wake, timeout, cancel-timeout]
7: ==7576== 2,320 (1,408 direct, 912 indirect) bytes in 1 blocks are definitely
lost in loss record 148 of 156
7: ==7576==at 0x483BB1A: calloc (vg_replace_malloc.c:760)
7: ==7576==by 0x4854315: pn_listener (epoll.c:1617)
7: ==7576==by 0x402C9C: listener_ctx_new (threaderciser.c:264)
7: ==7576==by 0x402C9C: lpool_listen.part.0 (threaderciser.c:282)
7: ==7576==by 0x40338B: lpool_listen (threaderciser.c:379)
7: ==7576==by 0x40338B: global_do_stuff (threaderciser.c:379)
7: ==7576==by 0x40360F: handle (threaderciser.c:414)
7: ==7576==by 0x40360F: proactor_thread (threaderciser.c:476)
7: ==7576==by 0x48D34E1: start_thread (pthread_create.c:479)
7: ==7576==by 0x49ED6C2: clone (clone.S:95)
7: ==7576==
7: ==7576== 95,957 (1,128 direct, 94,829 indirect) bytes in 1 blocks are
definitely lost in loss record 156 of 156
7: ==7576==at 0x483980B: malloc (vg_replace_malloc.c:307)
7: ==7576==by 0x402C94: listener_ctx_new (threaderciser.c:263)
7: ==7576==by 0x402C94: lpool_listen.part.0 (threaderciser.c:282)
7: ==7576==by 0x40338B: lpool_listen (threaderciser.c:379)
7: ==7576==by 0x40338B: global_do_stuff (threaderciser.c:379)
7: ==7576==by 0x40368F: user_thread (threaderciser.c:397)
7: ==7576==by 0x48D34E1: start_thread (pthread_create.c:479)
7: ==7576==by 0x49ED6C2: clone (clone.S:95)
7: ==7576==
1/1 Test #7: c-threaderciser ..***Failed5.75 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 5.76 sec
The following tests FAILED:
7 - c-threaderciser (Failed)
Errors while running CTest{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181989#comment-17181989
]
Charles E. Rolke commented on PROTON-2270:
--
Agreed, I can edit the source. I usually don't edit the source of a release
candidate but today is special. I increased the value and see the tests pass:
{code:java}
1/1 Test #7: c-threaderciser .. Passed 282.17 sec
1/1 Test #7: c-threaderciser .. Passed5.34 sec
1/1 Test #7: c-threaderciser .. Passed 157.08 sec
1/1 Test #7: c-threaderciser .. Passed 41.55 sec
1/1 Test #7: c-threaderciser .. Passed 14.66 sec
1/1 Test #7: c-threaderciser .. Passed8.94 sec
1/1 Test #7: c-threaderciser .. Passed6.51 sec
1/1 Test #7: c-threaderciser .. Passed 34.11 sec
1/1 Test #7: c-threaderciser .. Passed 98.44 sec
1/1 Test #7: c-threaderciser .. Passed 120.51 sec
1/1 Test #7: c-threaderciser .. Passed 20.33 sec
1/1 Test #7: c-threaderciser .. Passed 74.19 sec
1/1 Test #7: c-threaderciser .. Passed 109.62 sec
1/1 Test #7: c-threaderciser .. Passed 10.63 sec
1/1 Test #7: c-threaderciser .. Passed 53.78 sec
1/1 Test #7: c-threaderciser .. Passed 148.81 sec
1/1 Test #7: c-threaderciser .. Passed 87.80 sec
1/1 Test #7: c-threaderciser .. Passed 121.31 sec
1/1 Test #7: c-threaderciser .. Passed 89.12 sec
1/1 Test #7: c-threaderciser .. Passed 49.93 sec
1/1 Test #7: c-threaderciser .. Passed 156.20 sec
1/1 Test #7: c-threaderciser .. Passed 20.03 sec
1/1 Test #7: c-threaderciser .. Passed 111.21 sec
1/1 Test #7: c-threaderciser .. Passed 142.96 sec
{code}
Execution times vary by a factor of 50 and are all much higher than the other
system. That said, a timeout value higher than 120 would improve the experience
on this system.
The string of test passes is broken, unfortunately, with a valgrind error
{code:java}
7: Test timeout computed to be: 6000
7: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
connect, close-connect, wake, timeout, cancel-timeout]
7: ==7576== 2,320 (1,408 direct, 912 indirect) bytes in 1 blocks are definitely
lost in loss record 148 of 156
7: ==7576==at 0x483BB1A: calloc (vg_replace_malloc.c:760)
7: ==7576==by 0x4854315: pn_listener (epoll.c:1617)
7: ==7576==by 0x402C9C: listener_ctx_new (threaderciser.c:264)
7: ==7576==by 0x402C9C: lpool_listen.part.0 (threaderciser.c:282)
7: ==7576==by 0x40338B: lpool_listen (threaderciser.c:379)
7: ==7576==by 0x40338B: global_do_stuff (threaderciser.c:379)
7: ==7576==by 0x40360F: handle (threaderciser.c:414)
7: ==7576==by 0x40360F: proactor_thread (threaderciser.c:476)
7: ==7576==by 0x48D34E1: start_thread (pthread_create.c:479)
7: ==7576==by 0x49ED6C2: clone (clone.S:95)
7: ==7576==
7: ==7576== 95,957 (1,128 direct, 94,829 indirect) bytes in 1 blocks are
definitely lost in loss record 156 of 156
7: ==7576==at 0x483980B: malloc (vg_replace_malloc.c:307)
7: ==7576==by 0x402C94: listener_ctx_new (threaderciser.c:263)
7: ==7576==by 0x402C94: lpool_listen.part.0 (threaderciser.c:282)
7: ==7576==by 0x40338B: lpool_listen (threaderciser.c:379)
7: ==7576==by 0x40338B: global_do_stuff (threaderciser.c:379)
7: ==7576==by 0x40368F: user_thread (threaderciser.c:397)
7: ==7576==by 0x48D34E1: start_thread (pthread_create.c:479)
7: ==7576==by 0x49ED6C2: clone (clone.S:95)
7: ==7576==
1/1 Test #7: c-threaderciser ..***Failed5.75 sec
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 5.76 sec
The following tests FAILED:
7 - c-threaderciser (Failed)
Errors while running CTest
{code}
Which should be addressed in a separate issue.
> Threaderciser test does not honor ctest '--timeout' switch
> --
>
> Key: PROTON-2270
> URL: https://issues.apache.org/jira/browse/PROTON-2270
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.31.0
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Priority: Major
>
> Command line
> {code:java}
> > ctest -VV --timeout 600 -R threader
> {code}
> runs the test with
> {code:java}
> ...
> Start 7: c-threaderciser
> ...
> 7: Test timeout computed to be: 120
> ...
> {code}
> The test should respect the ctest switch and run for 600 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#80
[jira] [Commented] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181933#comment-17181933
]
Jiri Daněk commented on PROTON-2270:
You can edit/delete line 104 in {{c/tests/CMakeLists.txt}},
https://github.com/apache/qpid-proton/blob/78b6bfb4602b8c4ff5ed0f07a59263cd844512ef/c/tests/CMakeLists.txt#L104.
> Threaderciser test does not honor ctest '--timeout' switch
> --
>
> Key: PROTON-2270
> URL: https://issues.apache.org/jira/browse/PROTON-2270
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.31.0
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Priority: Major
>
> Command line
> {code:java}
> > ctest -VV --timeout 600 -R threader
> {code}
> runs the test with
> {code:java}
> ...
> Start 7: c-threaderciser
> ...
> 7: Test timeout computed to be: 120
> ...
> {code}
> The test should respect the ctest switch and run for 600 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181929#comment-17181929
]
Charles E. Rolke commented on PROTON-2270:
--
>>> Did you actually ever observe the test to take more than 120 and then pass?
No, I have never observed the test running longer than 120 and passing.
Catch-22?
I suspect the test would always pass if allowed to run long enough. But it
can't run long longer than 120 so I can't see it pass.
> Threaderciser test does not honor ctest '--timeout' switch
> --
>
> Key: PROTON-2270
> URL: https://issues.apache.org/jira/browse/PROTON-2270
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.31.0
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Priority: Major
>
> Command line
> {code:java}
> > ctest -VV --timeout 600 -R threader
> {code}
> runs the test with
> {code:java}
> ...
> Start 7: c-threaderciser
> ...
> 7: Test timeout computed to be: 120
> ...
> {code}
> The test should respect the ctest switch and run for 600 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
[
https://issues.apache.org/jira/browse/PROTON-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181919#comment-17181919
]
Jiri Daněk commented on PROTON-2270:
I think this is not a bug. The {{ctest --timeout}} configures a default
timeout. In the CTest world, tests are free to set their own timeouts,
overriding the default, if they "think they know better". Did you actually ever
observe the test to take more than 120 and then pass?
> Threaderciser test does not honor ctest '--timeout' switch
> --
>
> Key: PROTON-2270
> URL: https://issues.apache.org/jira/browse/PROTON-2270
> Project: Qpid Proton
> Issue Type: Bug
> Components: build
>Affects Versions: proton-c-0.31.0
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Priority: Major
>
> Command line
> {code:java}
> > ctest -VV --timeout 600 -R threader
> {code}
> runs the test with
> {code:java}
> ...
> Start 7: c-threaderciser
> ...
> 7: Test timeout computed to be: 120
> ...
> {code}
> The test should respect the ctest switch and run for 600 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2270) Threaderciser test does not honor ctest '--timeout' switch
Charles E. Rolke created PROTON-2270:
Summary: Threaderciser test does not honor ctest '--timeout' switch
Key: PROTON-2270
URL: https://issues.apache.org/jira/browse/PROTON-2270
Project: Qpid Proton
Issue Type: Bug
Components: build
Affects Versions: proton-c-0.31.0
Environment: Fedora 31
Reporter: Charles E. Rolke
Command line
{code:java}
> ctest -VV --timeout 600 -R threader
{code}
runs the test with
{code:java}
...
Start 7: c-threaderciser
...
7: Test timeout computed to be: 120
...
{code}
The test should respect the ctest switch and run for 600 seconds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1762) Setting verifyHostname to false on connector means certificate is not verified at all
Gordon Sim created DISPATCH-1762: Summary: Setting verifyHostname to false on connector means certificate is not verified at all Key: DISPATCH-1762 URL: https://issues.apache.org/jira/browse/DISPATCH-1762 Project: Qpid Dispatch Issue Type: Bug Reporter: Gordon Sim You can connect even of the CA path specified does not exist. (Expectation from the configuration option name is that only the hostname verification is disabled, but that the validity of the certificate is still verified). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
