Assertion 'tres.status == VexTransOK' failed

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Assertion 'tres.status == VexTransOK' failed

Nagendra Kumar Goel (नगेन्द्र गोयल)
I am trying to run valgrind on a multithreaded websockets based program, to check for memory leaks. Valgrind crashes in the middle of the program with following errors:

--17214-- REDIR: 0x6e44620 (libc.so.6:__memcpy_chk) redirected to 0x4a28770 (_vgnU_ifunc_wrapper)
--17214-- REDIR: 0x6e7c2a0 (libc.so.6:__memcpy_chk_avx_unaligned) redirected to 0x4c34e10 (__memcpy_chk)

valgrind: m_translate.c:1772 (vgPlain_translate): Assertion 'tres.status == VexTransOK' failed.

host stacktrace:
==17214==    at 0x38086843: show_sched_status_wrk (m_libcassert.c:378)
==17214==    by 0x38086944: report_and_quit (m_libcassert.c:449)
==17214==    by 0x38086AD1: vgPlain_assert_fail (m_libcassert.c:515)
==17214==    by 0x380A5606: vgPlain_translate (m_translate.c:1772)
==17214==    by 0x380DB83B: handle_chain_me (scheduler.c:1076)
==17214==    by 0x380DD36F: vgPlain_scheduler (scheduler.c:1420)
==17214==    by 0x380EC716: thread_wrapper (syswrap-linux.c:103)
==17214==    by 0x380EC716: run_a_thread_NORETURN (syswrap-linux.c:156)
==17214==    by 0x380EC9AA: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:329)
==17214==    by 0x3811619D: ??? (in /usr/local/lib/valgrind/memcheck-amd64-linux)
==17214==    by 0xDEADBEEFDEADBEEE: ???
==17214==    by 0xDEADBEEFDEADBEEE: ???
==17214==    by 0xDEADBEEFDEADBEEE: ???

sched status:
  running_tid=3

Thread 1: status = VgTs_WaitSys (lwpid 17214)
==17214==    at 0x516C9DD: pthread_join (pthread_join.c:90)
==17214==    by 0x6546B96: std::thread::join() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==17214==    by 0xE6A489: WebSocketServer::StartThreadService() (WebSocket-Server.cc:364)
==17214==    by 0xE6A11D: WebSocketServer::run() (WebSocket-Server.cc:321)
==17214==    by 0xE5EFCA: main (kws-WebSocket-Server.cc:37)

Thread 2: status = VgTs_WaitSys (lwpid 17215)
==17214==    at 0x6E29B5D: ??? (syscall-template.S:84)
==17214==    by 0x1612440: _lws_plat_service_tsi (lws-plat-unix.c:147)
==17214==    by 0x1600AAD: lws_service_tsi (service.c:1159)
==17214==    by 0xE6A14B: WebSocketServer::ThreadService(unsigned int) (WebSocket-Server.cc:325)
==17214==    by 0xE74AC1: void std::_Mem_fn_base<void (WebSocketServer::*)(unsigned int), true>::operator()<unsigned int, void>(WebSocketServer*, unsigned int&&) const (functional:600)
==17214==    by 0xE74A3E: void std::_Bind_simple<std::_Mem_fn<void (WebSocketServer::*)(unsigned int)> (WebSocketServer*, unsigned int)>::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (functional:1531)
==17214==    by 0xE748F5: std::_Bind_simple<std::_Mem_fn<void (WebSocketServer::*)(unsigned int)> (WebSocketServer*, unsigned int)>::operator()() (functional:1520)
==17214==    by 0xE74885: std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (WebSocketServer::*)(unsigned int)> (WebSocketServer*, unsigned int)> >::_M_run() (thread:115)
==17214==    by 0x6546C7F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==17214==    by 0x516B709: start_thread (pthread_create.c:333)
==17214==    by 0x6E3582C: clone (clone.S:109)

Thread 3: status = VgTs_Runnable (lwpid 17216)
==17214==    at 0x1497463: sgemm_kernel (sgemm_kernel_16x4_haswell.S:1284)


  I have tried changing the operating system (from fedora to mint and ubuntu). I also checked out the latest valgrind valgrind --version

valgrind-3.13.0.SVN to see if that will help me alleviate the issue. It did not help. Can someone please advise how to get around this issue.


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Assertion 'tres.status == VexTransOK' failed

John Reiser
On 01/16/2017 07:14 AM, Nagendra Kumar Goel (नगेन्द्र गोयल) wrote:
> I am trying to run valgrind on a multithreaded websockets based program, to check for memory leaks. Valgrind crashes in the middle of the program with following errors:
>
> --17214-- REDIR: 0x6e44620 (libc.so.6:__memcpy_chk) redirected to 0x4a28770 (_vgnU_ifunc_wrapper)
> --17214-- REDIR: 0x6e7c2a0 (libc.so.6:__memcpy_chk_avx_unaligned) redirected to 0x4c34e10 (__memcpy_chk)
>
> valgrind: m_translate.c:1772 (vgPlain_translate): Assertion 'tres.status == VexTransOK' failed.

There is no workaround.  The bug must be fixed.

Please file a bug report.  https://valgrind.org > Bug reports
Copy+paste from your message into the bug report, add a title.
PLEASE INCLUDE THE VERSION OF VALGRIND and the operating system (uname -a).


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Assertion 'tres.status == VexTransOK' failed

Julian Seward-2
In reply to this post by Nagendra Kumar Goel (नगेन्द्र गोयल)

> valgrind: m_translate.c:1772 (vgPlain_translate): Assertion 'tres.status ==
> VexTransOK' failed.

That is a very strange failure.  It might just be believable that the front
end failed somehow whilst parsing handwritten assembly in this file

> Thread 3: status = VgTs_Runnable (lwpid 17216)
> ==17214==    at 0x1497463: sgemm_kernel (sgemm_kernel_16x4_haswell.S:1284)

Can you re-run with --trace-flags=10000000 and mail the last 50 lines before
the failure here?  I want to see what bit of code it was trying to process
at the time it failed.

J


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Assertion 'tres.status == VexTransOK' failed

Nagendra Kumar Goel (नगेन्द्र गोयल)
Please see below. sgemm comes from openblas : http://www.openblas.net/ 

==17348== Memcheck, a memory error detector
==17348== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17348== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==17348== Command: ./a.out new.conf seg
==17348==
==== SB 0 (evchecks 0) [tid 1] 0x40012d0 UNKNOWN_FUNCTION /lib/x86_64-linux-gnu/ld-2.19.so+0x12d0
==== SB 1 (evchecks 1) [tid 1] 0x4004ac5 _dl_start+85 /lib/x86_64-linux-gnu/ld-2.19.so+0x4ac5
==== SB 2 (evchecks 2) [tid 1] 0x4004b1f _dl_start+175 /lib/x86_64-linux-gnu/ld-2.19.so+0x4b1f
==== SB 3 (evchecks 3) [tid 1] 0x4004b08 _dl_start+152 /lib/x86_64-linux-gnu/ld-2.19.so+0x4b08
==== SB 4 (evchecks 6) [tid 1] 0x4004b25 _dl_start+181 /lib/x86_64-linux-gnu/ld-2.19.so+0x4b25
.
.
.
==== SB 38875 (evchecks 11190178207) [tid 1] 0xda8f94 sgemm_tn+1316 a.out+0xda8f94
==== SB 38876 (evchecks 11190178208) [tid 1] 0xda8c82 sgemm_tn+530 a.out+0xda8c82
==== SB 38877 (evchecks 11190178209) [tid 1] 0xda8cbb sgemm_tn+587 a.out+0xda8cbb
==== SB 38878 (evchecks 11190178210) [tid 1] 0x20c83f0 sgemm_incopy_HASWELL a.out+0x20c83f0
==== SB 38879 (evchecks 11190178211) [tid 1] 0x20c843f sgemm_incopy_HASWELL+79 a.out+0x20c843f
==== SB 38880 (evchecks 11190178212) [tid 1] 0x20c8565 sgemm_incopy_HASWELL+373 a.out+0x20c8565
==== SB 38881 (evchecks 11190178213) [tid 1] 0x20c856b sgemm_incopy_HASWELL+379 a.out+0x20c856b
==== SB 38882 (evchecks 11190178214) [tid 1] 0x20c86cb sgemm_incopy_HASWELL+731 a.out+0x20c86cb
==== SB 38883 (evchecks 11190178215) [tid 1] 0x20c8813 sgemm_incopy_HASWELL+1059 a.out+0x20c8813
==== SB 38884 (evchecks 11190178216) [tid 1] 0x20c8588 sgemm_incopy_HASWELL+408 a.out+0x20c8588
==== SB 38885 (evchecks 11190178217) [tid 1] 0x20c86ee sgemm_incopy_HASWELL+766 a.out+0x20c86ee
==== SB 38886 (evchecks 11190178218) [tid 1] 0x20c8833 sgemm_incopy_HASWELL+1091 a.out+0x20c8833
==== SB 38887 (evchecks 11190178327) [tid 1] 0x20c887f sgemm_incopy_HASWELL+1167 a.out+0x20c887f
==== SB 38888 (evchecks 11190178328) [tid 1] 0x20c8a0d sgemm_incopy_HASWELL+1565 a.out+0x20c8a0d
==== SB 38889 (evchecks 11190178329) [tid 1] 0x20c8a2a sgemm_incopy_HASWELL+1594 a.out+0x20c8a2a
==== SB 38890 (evchecks 11190179650) [tid 1] 0x20c8a40 sgemm_incopy_HASWELL+1616 a.out+0x20c8a40
==== SB 38891 (evchecks 11190179651) [tid 1] 0x20c8a6c sgemm_incopy_HASWELL+1660 a.out+0x20c8a6c
==== SB 38892 (evchecks 11190179652) [tid 1] 0x20c8ac1 sgemm_incopy_HASWELL+1745 a.out+0x20c8ac1
==== SB 38893 (evchecks 11190179653) [tid 1] 0x20c8bf9 sgemm_incopy_HASWELL+2057 a.out+0x20c8bf9
==== SB 38894 (evchecks 11190179654) [tid 1] 0x20c8ad8 sgemm_incopy_HASWELL+1768 a.out+0x20c8ad8
==== SB 38895 (evchecks 11190179763) [tid 1] 0x20c8c05 sgemm_incopy_HASWELL+2069 a.out+0x20c8c05
==== SB 38896 (evchecks 11190179764) [tid 1] 0x20c8c4b sgemm_incopy_HASWELL+2139 a.out+0x20c8c4b
==== SB 38897 (evchecks 11190179765) [tid 1] 0x20c8c5c sgemm_incopy_HASWELL+2156 a.out+0x20c8c5c
==== SB 38898 (evchecks 11190179766) [tid 1] 0x20c8ca1 sgemm_incopy_HASWELL+2225 a.out+0x20c8ca1
==== SB 38899 (evchecks 11190179767) [tid 1] 0x20c8cb8 sgemm_incopy_HASWELL+2248 a.out+0x20c8cb8
==== SB 38900 (evchecks 11190179876) [tid 1] 0x20c8d09 sgemm_incopy_HASWELL+2329 a.out+0x20c8d09
==== SB 38901 (evchecks 11190179877) [tid 1] 0x20c8d43 sgemm_incopy_HASWELL+2387 a.out+0x20c8d43
==== SB 38902 (evchecks 11190179878) [tid 1] 0x20c8dd1 sgemm_incopy_HASWELL+2529 a.out+0x20c8dd1
==== SB 38903 (evchecks 11190179879) [tid 1] 0x20c8e29 sgemm_incopy_HASWELL+2617 a.out+0x20c8e29
==== SB 38904 (evchecks 11190179880) [tid 1] 0xda8cec sgemm_tn+636 a.out+0xda8cec
==== SB 38905 (evchecks 11190179881) [tid 1] 0xda8cfc sgemm_tn+652 a.out+0xda8cfc
==== SB 38906 (evchecks 11190179882) [tid 1] 0xda8d34 sgemm_tn+708 a.out+0xda8d34
==== SB 38907 (evchecks 11190179883) [tid 1] 0x20c9610 sgemm_oncopy_HASWELL a.out+0x20c9610
==== SB 38908 (evchecks 11190179884) [tid 1] 0x20c9650 sgemm_oncopy_HASWELL+64 a.out+0x20c9650
==== SB 38909 (evchecks 11190179885) [tid 1] 0x20c9709 sgemm_oncopy_HASWELL+249 a.out+0x20c9709
==== SB 38910 (evchecks 11190179886) [tid 1] 0x20c9720 sgemm_oncopy_HASWELL+272 a.out+0x20c9720
==== SB 38911 (evchecks 11190179940) [tid 1] 0x20c9814 sgemm_oncopy_HASWELL+516 a.out+0x20c9814
==== SB 38912 (evchecks 11190179941) [tid 1] 0x20c987d sgemm_oncopy_HASWELL+621 a.out+0x20c987d
==== SB 38913 (evchecks 11190179942) [tid 1] 0x20c9897 sgemm_oncopy_HASWELL+647 a.out+0x20c9897
==== SB 38914 (evchecks 11190180053) [tid 1] 0x20c98a8 sgemm_oncopy_HASWELL+664 a.out+0x20c98a8
==== SB 38915 (evchecks 11190180054) [tid 1] 0x20c998a sgemm_oncopy_HASWELL+890 a.out+0x20c998a
==== SB 38916 (evchecks 11190180055) [tid 1] 0x20c9a0b sgemm_oncopy_HASWELL+1019 a.out+0x20c9a0b
==== SB 38917 (evchecks 11190180056) [tid 1] 0xda8d7c sgemm_tn+780 a.out+0xda8d7c
==== SB 38918 (evchecks 11190180057) [tid 1] 0x20bfa00 sgemm_kernel_HASWELL a.out+0x20bfa00
==== SB 38919 (evchecks 11190180058) [tid 1] 0x20bfa44 sgemm_kernel_HASWELL+68 a.out+0x20bfa44
==== SB 38920 (evchecks 11190180059) [tid 1] 0x20bfa4e sgemm_kernel_HASWELL+78 a.out+0x20bfa4e
==== SB 38921 (evchecks 11190180060) [tid 1] 0x20bfa58 sgemm_kernel_HASWELL+88 a.out+0x20bfa58
==== SB 38922 (evchecks 11190180061) [tid 1] 0x20bfa98 sgemm_kernel_HASWELL+152 a.out+0x20bfa98
==== SB 38923 (evchecks 11190180062) [tid 1] 0x20bfac0 sgemm_kernel_HASWELL+192 a.out+0x20bfac0
==== SB 38924 (evchecks 11190180172) [tid 1] 0x20bfae3 sgemm_kernel_HASWELL+227 a.out+0x20bfae3
==== SB 38925 (evchecks 11190180173) [tid 1] 0x20bfb0a sgemm_kernel_HASWELL+266 a.out+0x20bfb0a
==== SB 38926 (evchecks 11190180174) [tid 1] 0x20bfb2c sgemm_kernel_HASWELL+300 a.out+0x20bfb2c
==== SB 38927 (evchecks 11190180175) [tid 1] 0x20bfc63 sgemm_kernel_HASWELL+611 a.out+0x20bfc63

valgrind: m_translate.c:1772 (vgPlain_translate): Assertion 'tres.status == VexTransOK' failed.

host stacktrace:
==17348==    at 0x38089E9A: show_sched_status_wrk (m_libcassert.c:343)
==17348==    by 0x38089FB4: report_and_quit (m_libcassert.c:419)
==17348==    by 0x3808A14A: vgPlain_assert_fail (m_libcassert.c:485)
==17348==    by 0x380AA31C: vgPlain_translate (m_translate.c:1772)
==17348==    by 0x380DFBBB: handle_chain_me (scheduler.c:1076)
==17348==    by 0x380E1947: vgPlain_scheduler (scheduler.c:1420)
==17348==    by 0x380F18F0: thread_wrapper (syswrap-linux.c:103)
==17348==    by 0x380F18F0: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 17348)
==17348==    at 0x20BFC63: sgemm_kernel_HASWELL (in a.out)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.


On Tue, Jan 17, 2017 at 6:12 AM, Julian Seward <[hidden email]> wrote:

> valgrind: m_translate.c:1772 (vgPlain_translate): Assertion 'tres.status ==
> VexTransOK' failed.

That is a very strange failure.  It might just be believable that the front
end failed somehow whilst parsing handwritten assembly in this file

> Thread 3: status = VgTs_Runnable (lwpid 17216)
> ==17214==    at 0x1497463: sgemm_kernel (sgemm_kernel_16x4_haswell.S:1284)

Can you re-run with --trace-flags=10000000 and mail the last 50 lines before
the failure here?  I want to see what bit of code it was trying to process
at the time it failed.

J



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Loading...