<div dir="ltr">Thanks. Definitely something in rld DWARF support.<div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 7, 2018 at 2:36 PM, Cillian O'Donnell <span dir="ltr"><<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Valgrind, Invalid read of size 8<br><br>cpod@cpod ~/development/rtems/leon3 $ valgrind covoar -S /home/cpod/development/rtems/<wbr>test/rtems-tools/tester/rtems/<wbr>testing/coverage/score-<wbr>symbols.ini -O /home/cpod/coverage_test/test/<wbr>score -E/home/cpod/development/<wbr>rtems/test/rtems-tools/tester/<wbr>rtems/testing/coverage/<wbr>Explanations.txt -p RTEMS-5 -v sparc-rtems5/c/leon3/<wbr>testsuites/samples/hello/<wbr>hello.exe<br>==20928== Memcheck, a memory error detector<br>==20928== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.<br>==20928== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info<br>==20928== Command: covoar -S /home/cpod/development/rtems/<wbr>test/rtems-tools/tester/rtems/<wbr>testing/coverage/score-<wbr>symbols.ini -O /home/cpod/coverage_test/test/<wbr>score -E/home/cpod/development/<wbr>rtems/test/rtems-tools/tester/<wbr>rtems/testing/coverage/<wbr>Explanations.txt -p RTEMS-5 -v sparc-rtems5/c/leon3/<wbr>testsuites/samples/hello/<wbr>hello.exe<br>==20928== <br>==20928== Invalid read of size 8<br>==20928==    at 0x43FBDC: pop_back (stl_vector.h:951)<br>==20928==    by 0x43FBDC: rld::path::path_abs(std::__<wbr>cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rld-path.cpp:148)<br>==20928==    by 0x42BC49: rld::dwarf::compilation_unit::<wbr>compilation_unit(rld::dwarf::<wbr>file&, rld::dwarf::debug_info_entry&, unsigned long) (rld-dwarf.cpp:486)<br>==20928==    by 0x42D204: rld::dwarf::file::load_debug() (rld-dwarf.cpp:758)<br>==20928==    by 0x40DEC4: Coverage::ExecutableInfo::<wbr>ExecutableInfo(char const*, char const*) (ExecutableInfo.cc:33)<br>==20928==    by 0x4054B5: main (covoar.cc:330)<br>==20928==  Address 0x6d74610 is 32 bytes before a block of size 256 in arena "client"<br>==20928== <br>==20928== Invalid free() / delete / delete[] / realloc()<br>==20928==    at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_<wbr>memcheck-amd64-linux.so)<br>==20928==    by 0x43FBED: deallocate (new_allocator.h:110)<br>==20928==    by 0x43FBED: deallocate (alloc_traits.h:517)<br>==20928==    by 0x43FBED: _M_destroy (basic_string.h:185)<br>==20928==    by 0x43FBED: _M_dispose (basic_string.h:180)<br>==20928==    by 0x43FBED: ~basic_string (basic_string.h:543)<br>==20928==    by 0x43FBED: destroy<std::__cxx11::basic_<wbr>string<char> > (new_allocator.h:124)<br>==20928==    by 0x43FBED: destroy<std::__cxx11::basic_<wbr>string<char> > (alloc_traits.h:542)<br>==20928==    by 0x43FBED: pop_back (stl_vector.h:952)<br>==20928==    by 0x43FBED: rld::path::path_abs(std::__<wbr>cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rld-path.cpp:148)<br>==20928==    by 0x42BC49: rld::dwarf::compilation_unit::<wbr>compilation_unit(rld::dwarf::<wbr>file&, rld::dwarf::debug_info_entry&, unsigned long) (rld-dwarf.cpp:486)<br>==20928==    by 0x42D204: rld::dwarf::file::load_debug() (rld-dwarf.cpp:758)<br>==20928==    by 0x40DEC4: Coverage::ExecutableInfo::<wbr>ExecutableInfo(char const*, char const*) (ExecutableInfo.cc:33)<br>==20928==    by 0x4054B5: main (covoar.cc:330)<br>==20928==  Address 0x140 is not stack'd, malloc'd or (recently) free'd<br>==20928== <br>==20928== Invalid write of size 8<br>==20928==    at 0x43FD91: _M_local_data (basic_string.h:141)<br>==20928==    by 0x43FD91: basic_string (basic_string.h:399)<br>==20928==    by 0x43FD91: construct<std::__cxx11::basic_<wbr>string<char>, const std::__cxx11::basic_string<<wbr>char, std::char_traits<char>, std::allocator<char> >&> (new_allocator.h:120)<br>==20928==    by 0x43FD91: construct<std::__cxx11::basic_<wbr>string<char>, const std::__cxx11::basic_string<<wbr>char, std::char_traits<char>, std::allocator<char> >&> (alloc_traits.h:530)<br>==20928==    by 0x43FD91: push_back (stl_vector.h:917)<br>==20928==    by 0x43FD91: rld::path::path_abs(std::__<wbr>cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rld-path.cpp:152)<br>==20928==    by 0x42BC49: rld::dwarf::compilation_unit::<wbr>compilation_unit(rld::dwarf::<wbr>file&, rld::dwarf::debug_info_entry&, unsigned long) (rld-dwarf.cpp:486)<br>==20928==    by 0x42D204: rld::dwarf::file::load_debug() (rld-dwarf.cpp:758)<br>==20928==    by 0x40DEC4: Coverage::ExecutableInfo::<wbr>ExecutableInfo(char const*, char const*) (ExecutableInfo.cc:33)<br>==20928==    by 0x4054B5: main (covoar.cc:330)<br>==20928==  Address 0x6d74610 is 32 bytes before a block of size 256 in arena "client"<br>==20928== <br>==20928== <br>==20928== Process terminating with default action of signal 11 (SIGSEGV)<br>==20928==  Access not within mapped region at address 0xDAE8C28<br>==20928==    at 0x43F1A8: void std::__cxx11::basic_string<<wbr>char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) [clone .isra.30] (basic_string.tcc:221)<br>==20928==    by 0x43FDA2: _M_construct_aux<char*> (basic_string.h:195)<br>==20928==    by 0x43FDA2: _M_construct<char*> (basic_string.h:214)<br>==20928==    by 0x43FDA2: basic_string (basic_string.h:400)<br>==20928==    by 0x43FDA2: construct<std::__cxx11::basic_<wbr>string<char>, const std::__cxx11::basic_string<<wbr>char, std::char_traits<char>, std::allocator<char> >&> (new_allocator.h:120)<br>==20928==    by 0x43FDA2: construct<std::__cxx11::basic_<wbr>string<char>, const std::__cxx11::basic_string<<wbr>char, std::char_traits<char>, std::allocator<char> >&> (alloc_traits.h:530)<br>==20928==    by 0x43FDA2: push_back (stl_vector.h:917)<br>==20928==    by 0x43FDA2: rld::path::path_abs(std::__<wbr>cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (rld-path.cpp:152)<br>==20928==    by 0x42BC49: rld::dwarf::compilation_unit::<wbr>compilation_unit(rld::dwarf::<wbr>file&, rld::dwarf::debug_info_entry&, unsigned long) (rld-dwarf.cpp:486)<br>==20928==    by 0x42D204: rld::dwarf::file::load_debug() (rld-dwarf.cpp:758)<br>==20928==    by 0x40DEC4: Coverage::ExecutableInfo::<wbr>ExecutableInfo(char const*, char const*) (ExecutableInfo.cc:33)<br>==20928==    by 0x4054B5: main (covoar.cc:330)<br>==20928==  If you believe this happened as a result of a stack<br>==20928==  overflow in your program's main thread (unlikely but<br>==20928==  possible), you can try to increase the size of the<br>==20928==  main thread stack using the --main-stacksize= flag.<br>==20928==  The main thread stack size used in this run was 8388608.<br>==20928== <br>==20928== HEAP SUMMARY:<br>==20928==     in use at exit: 6,603,094 bytes in 39,763 blocks<br>==20928==   total heap usage: 98,260 allocs, 58,498 frees, 8,844,293 bytes allocated<br>==20928== <br>==20928== LEAK SUMMARY:<br>==20928==    definitely lost: 55 bytes in 3 blocks<br>==20928==    indirectly lost: 0 bytes in 0 blocks<br>==20928==      possibly lost: 0 bytes in 0 blocks<br>==20928==    still reachable: 6,603,039 bytes in 39,760 blocks<br>==20928==         suppressed: 0 bytes in 0 blocks<br>==20928== Rerun with --leak-check=full to see details of leaked memory<br>==20928== <br>==20928== For counts of detected and suppressed errors, rerun with: -v<br>==20928== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)<br>Segmentation fault<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 7 May 2018 at 20:16, Cillian O'Donnell <span dir="ltr"><<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Heres the gdb backtrace. rld-dwarf.cpp rld-path showing up near the bottom. I don't have valgrind, I'll get it now and see what I find there.<br><br>(gdb) bt<br>#0  0x00007ffff74aa428 in __GI_raise (sig=sig@entry=6)<br>    at ../sysdeps/unix/sysv/linux/rai<wbr>se.c:54<br>#1  0x00007ffff74ac02a in __GI_abort () at abort.c:89<br>#2  0x00007ffff74ec7ea in __libc_message (do_abort=do_abort@entry=2, <br>    fmt=fmt@entry=0x7ffff7605ed8 "*** Error in `%s': %s: 0x%s ***\n")<br>    at ../sysdeps/posix/libc_fatal.c:<wbr>175<br>#3  0x00007ffff74f537a in malloc_printerr (ar_ptr=<optimized out>, <br>    ptr=<optimized out>, str=0x7ffff7605f50 "free(): invalid next size (fast)", <br>    action=3) at malloc.c:5006<br>#4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3867<br>#5  0x00007ffff74f953c in __GI___libc_free (mem=<optimized out>) at malloc.c:2968<br>#6  0x000000000043fcee in __gnu_cxx::new_allocator<std::<wbr>__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::deallocate (this=0x7fffffffc730, <br>    __p=<optimized out>) at /usr/include/c++/5/ext/new_all<wbr>ocator.h:110<br>#7  std::allocator_traits<std::all<wbr>ocator<std::__cxx11::basic_str<wbr>ing<char, std::char_traits<char>, std::allocator<char> > > >::deallocate (__a=..., <br>    __n=<optimized out>, __p=<optimized out>)<br>    at /usr/include/c++/5/bits/alloc_<wbr>traits.h:517<br>#8  std::_Vector_base<std::__cxx11<wbr>::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::b<wbr>asic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_deallocate (this=0x7fffffffc730, <br>    __n=<optimized out>, __p=<optimized out>)<br>    at /usr/include/c++/5/bits/stl_ve<wbr>ctor.h:178<br>#9  std::_Vector_base<std::__cxx11<wbr>::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::b<wbr>asic_string<char, std::char_traits<char>, std::allocator<char> > > >::~_Vector_base (this=0x7fffffffc730, <br>    __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_ve<wbr>ctor.h:160<br>#10 std::vector<std::__cxx11::basi<wbr>c_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::b<wbr>asic_string<char, std::char_traits<char>, std::allocator<char> > > >::~vector (this=0x7fffffffc730, <br>    __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_ve<wbr>ctor.h:425<br>#11 rld::path::path_abs (path=...) at ../rtemstoolkit/rld-path.cpp:1<wbr>32<br>#12 0x000000000042bc4a in rld::dwarf::compilation_unit::<wbr>compilation_unit (<br>    this=0x7fffffffca30, debug=..., die=..., offset=<optimized out>)<br>    at ../rtemstoolkit/rld-dwarf.cpp:<wbr>486<br>#13 0x000000000042d205 in rld::dwarf::file::load_debug (this=this@entry=0x6bc568)<br>    at ../rtemstoolkit/rld-dwarf.cpp:<wbr>758<br>#14 0x000000000040dec5 in Coverage::ExecutableInfo::Exec<wbr>utableInfo (this=0x6bc3c0, <br>    theExecutableName=<optimized out>, theLibraryName=0x0)<br>    at ../tester/covoar/ExecutableInf<wbr>o.cc:33<br>#15 0x00000000004054b6 in main (argc=<optimized out>, argv=<optimized out>)<br>    at ../tester/covoar/covoar.cc:330<br><br></div><div class="m_6003438246185244237HOEnZb"><div class="m_6003438246185244237h5"><div class="gmail_extra"><br><div class="gmail_quote">On 7 May 2018 at 20:03, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_6003438246185244237m_-9155371500798737038h5">On Mon, May 7, 2018 at 1:59 PM, Cillian O'Donnell <span dir="ltr"><<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 7 May 2018 at 18:56, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi<div><br></div><div>I have attached a workaround. It seems that libgen.h has this:</div><div><br></div><div>

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">==============================<wbr>==========================</span>

<br></div><div><div>/* Return final component of PATH.</div><div><br></div><div>   This is the weird XPG version of this function.  It sometimes will</div><div>   modify its argument.  Therefore we normally use the GNU version (in</div><div>   <string.h>) and only if this header is included make the XPG</div><div>   version available under the real name.  */</div><div>extern char *__xpg_basename (char *__path) __THROW;</div><div>#define basename        __xpg_basename</div></div><div>==============================<wbr>==========================</div><div><br></div><div>Chris has used basename as a method name and even though that should</div><div>be perfectly acceptable, the macro above gets expanded, the name </div><div>gets changed (in some places) to rld::path::__xpg_basename()</div><span class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-"><div><br></div><div><div>      r.lowSourceLine = rld::path::basename (location);</div></div><div><br></div></span><div>IMO the fix is to add dirname to rld-files, use rld basename and dirname</div><div>exclusively, and avoid libgen.h at all costs.</div><div><br></div><div>I didn't do that much work. I got lucky in a couple of files by removing the</div><div>include of libgen.h since it wasn't needed but I had to leave it in one place.</div><div><br></div><div><div>$ grep dirname *.cc</div><div>GcovData.cc:    dirname( path );</div></div><div><br></div><div>Hopefully this lets you all proceed with Chris' patches and my slight hack</div><div>in place.</div></div></blockquote><div><br></div></span><div>Thanks Joel! The good news is that's building now with only a couple of warnings.<br><br></div><div>The bad news is..<br><br>cpod@cpod ~/development/rtems/leon3 $ covoar -S /home/cpod/development/rtems/t<wbr>est/rtems-tools/tester/rtems/t<wbr>esting/coverage/score-symbols.<wbr>ini -O /home/cpod/coverage_test/test/<wbr>score -E/home/cpod/development/rtems<wbr>/test/rtems-tools/tester/rtems<wbr>/testing/coverage/Explanations<wbr>.txt -p RTEMS-5 -v sparc-rtems5/c/leon3/testsuite<wbr>s/samples/hello/hello.exe<br>*** Error in `covoar': free(): invalid next size (fast): 0x0000000001000360 ***<br>======= Backtrace: =========<br>/lib/x86_64-linux-gnu/libc.so.<wbr>6(+0x777e5)[0x7fcd0b3477e5]<br>/lib/x86_64-linux-gnu/libc.so.<wbr>6(+0x8037a)[0x7fcd0b35037a]<br>/lib/x86_64-linux-gnu/libc.so.<wbr>6(cfree+0x4c)[0x7fcd0b35453c]<br>covoar[0x43fcee]<br>covoar[0x42bc4a]<br>covoar[0x42d205]<br>covoar[0x40dec5]<br>covoar[0x4054b6]<br>/lib/x86_64-linux-gnu/libc.so.<wbr>6(__libc_start_main+0xf0)[0x7f<wbr>cd0b2f0830]<br>covoar[0x4073e9]<br>======= Memory map: ========<br>00400000-004a8000 r-xp 00000000 08:07 3276534                       <wbr>     /home/cpod/development/rtems/t<wbr>est/rtems-tools/build/tester/c<wbr>ovoar/covoar<br>006a7000-006a8000 r--p 000a7000 08:07 3276534                       <wbr>     /home/cpod/development/rtems/t<wbr>est/rtems-tools/build/tester/c<wbr>ovoar/covoar<br>006a8000-006a9000 rw-p 000a8000 08:07 3276534                       <wbr>     /home/cpod/development/rtems/t<wbr>est/rtems-tools/build/tester/c<wbr>ovoar/covoar<br>006a9000-006aa000 rw-p 00000000 00:00 0 <br>00c6a000-01022000 rw-p 00000000 00:00 0                             <wbr>     [heap]<br>7fcd04000000-7fcd04021000 rw-p 00000000 00:00 0 <br>7fcd04021000-7fcd08000000 ---p 00000000 00:00 0 <br>7fcd0a9ae000-7fcd0ac36000 rw-p 00000000 00:00 0 <br>7fcd0ac36000-7fcd0afc7000 r--p 00000000 08:07 2759194                    /home/cpod/development/rtems/l<wbr>eon3/sparc-rtems5/c/leon3/test<wbr>suites/samples/hello/hello.exe<br>7fcd0afc7000-7fcd0b0cf000 r-xp 00000000 08:07 1838070                    /lib/x86_64-linux-gnu/<a href="http://libm-2.23.so" target="_blank">libm-2.2<wbr>3.so</a><br>7fcd0b0cf000-7fcd0b2ce000 ---p 00108000 08:07 1838070                    /lib/x86_64-linux-gnu/<a href="http://libm-2.23.so" target="_blank">libm-2.2<wbr>3.so</a><br>7fcd0b2ce000-7fcd0b2cf000 r--p 00107000 08:07 1838070                    /lib/x86_64-linux-gnu/<a href="http://libm-2.23.so" target="_blank">libm-2.2<wbr>3.so</a><br>7fcd0b2cf000-7fcd0b2d0000 rw-p 00108000 08:07 1838070                    /lib/x86_64-linux-gnu/<a href="http://libm-2.23.so" target="_blank">libm-2.2<wbr>3.so</a><br>7fcd0b2d0000-7fcd0b490000 r-xp 00000000 08:07 1842682                    /lib/x86_64-linux-gnu/<a href="http://libc-2.23.so" target="_blank">libc-2.2<wbr>3.so</a><br>7fcd0b490000-7fcd0b690000 ---p 001c0000 08:07 1842682                    /lib/x86_64-linux-gnu/<a href="http://libc-2.23.so" target="_blank">libc-2.2<wbr>3.so</a><br>7fcd0b690000-7fcd0b694000 r--p 001c0000 08:07 1842682                    /lib/x86_64-linux-gnu/<a href="http://libc-2.23.so" target="_blank">libc-2.2<wbr>3.so</a><br>7fcd0b694000-7fcd0b696000 rw-p 001c4000 08:07 1842682                    /lib/x86_64-linux-gnu/<a href="http://libc-2.23.so" target="_blank">libc-2.2<wbr>3.so</a><br>7fcd0b696000-7fcd0b69a000 rw-p 00000000 00:00 0 <br>7fcd0b69a000-7fcd0b6b0000 r-xp 00000000 08:07 1836727                    /lib/x86_64-linux-gnu/libgcc_s<wbr>.so.1<br>7fcd0b6b0000-7fcd0b8af000 ---p 00016000 08:07 1836727                    /lib/x86_64-linux-gnu/libgcc_s<wbr>.so.1<br>7fcd0b8af000-7fcd0b8b0000 rw-p 00015000 08:07 1836727                    /lib/x86_64-linux-gnu/libgcc_s<wbr>.so.1<br>7fcd0b8b0000-7fcd0ba22000 r-xp 00000000 08:07 1049309                    /usr/lib/x86_64-linux-gnu/libs<wbr>tdc++.so.6.0.21<br>7fcd0ba22000-7fcd0bc22000 ---p 00172000 08:07 1049309                    /usr/lib/x86_64-linux-gnu/libs<wbr>tdc++.so.6.0.21<br>7fcd0bc22000-7fcd0bc2c000 r--p 00172000 08:07 1049309                    /usr/lib/x86_64-linux-gnu/libs<wbr>tdc++.so.6.0.21<br>7fcd0bc2c000-7fcd0bc2e000 rw-p 0017c000 08:07 1049309                    /usr/lib/x86_64-linux-gnu/libs<wbr>tdc++.so.6.0.21<br>7fcd0bc2e000-7fcd0bc32000 rw-p 00000000 00:00 0 <br>7fcd0bc32000-7fcd0bc58000 r-xp 00000000 08:07 1838072                    /lib/x86_64-linux-gnu/<a href="http://ld-2.23.so" target="_blank">ld-2.23.<wbr>so</a><br>7fcd0bd72000-7fcd0be30000 rw-p 00000000 00:00 0 <br>7fcd0be56000-7fcd0be57000 rw-p 00000000 00:00 0 <br>7fcd0be57000-7fcd0be58000 r--p 00025000 08:07 1838072                    /lib/x86_64-linux-gnu/<a href="http://ld-2.23.so" target="_blank">ld-2.23.<wbr>so</a><br>7fcd0be58000-7fcd0be59000 rw-p 00026000 08:07 1838072                    /lib/x86_64-linux-gnu/<a href="http://ld-2.23.so" target="_blank">ld-2.23.<wbr>so</a><br>7fcd0be59000-7fcd0be5a000 rw-p 00000000 00:00 0 <br>7ffc5053b000-7ffc5055d000 rw-p 00000000 00:00 0                          [stack]<br>7ffc505d5000-7ffc505d7000 r--p 00000000 00:00 0                          [vvar]<br>7ffc505d7000-7ffc505d9000 r-xp 00000000 00:00 0                          [vdso]<br>ffffffffff600000-ffffffffff601<wbr>000 r-xp 00000000 00:00 0                  [vsyscall]<br>Aborted<br></div></div></div></div></blockquote><div><br></div></div></div><div>OK. Sadly this is progress. :)</div><div><br></div><div>Can you get a real backtrace in gdb? </div><div><br></div><div>Or run it under valgrind? It is either a double free or a write past the end of a buffer. Based on the</div><div>error mesage from glibc ("

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">*** Error in `covoar': free(): invalid next size (fast): 0x0000000001000360 ***"),</span><br style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">

</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I suspect it is a write past the end of a buffer and valgrind would be better to spot that.</span></div><div><div class="m_6003438246185244237m_-9155371500798737038h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Ultimate solution is probably simple. We just need to hear from Chris.</div><span class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-HOEnZb"><font color="#888888"><div><br></div><div>--joel</div><div><br></div></font></span></div><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-HOEnZb"><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 7, 2018 at 12:42 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, May 7, 2018 at 12:36 PM, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span><div><br><div class="gmail_quote"><div dir="ltr">On Mon, 7 May 2018, 22:57 Cillian O'Donnell, <<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Yeah I'm seeing the same as Joel, at least were further then we were :).<br><br>I've been mostly working on the rtems-tester support, so just to give an update. I spent all day Saturday and today on it. It's taking longer than expected, re-orienting myself and deciding what is needed and not needed now with the changes in covoar. The problems are not difficult, it's just taking some time re-organizing everything. My time is limited during the week, so it'll probably be next weekend before I can finish it off. Vijay if you have time during the week I could push what I have and you could take a stab at some of them and then I could it finish off next weekend if you haven't already.<br></div></blockquote></div></div></span><div dir="auto">please send them, I can look into them for sure.</div></div></blockquote><div><br></div></span><div>Keep plugging away.</div><div><br></div><div>I think there is something wrong in rld related to basename. My first thought was that the undefined symbol was because we didn't include the library. Now I think it is because something got misconfigured on Centos/Fedora/etc. Looking into this.</div><div><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625h5"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 May 2018 at 15:40, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, May 7, 2018 at 6:01 AM, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have added the path to libdwarf here </div></blockquote><div><br></div></span><div>That worked for me to build but not to link.</div><div><br></div><div>I'm not sure why this rld symbol turned up missing on Centos 7.</div><div><br></div><div>==============================<wbr>======================</div><div><br></div><div><div>$ ./waf -v</div><div>Waf: Entering directory `/home/joel/rtems-work/rtems-t<wbr>ools/build'</div><div>[228/229] Linking build/tester/covoar/trace-conv<wbr>erter</div><div>09:38:25 runner ['/usr/bin/g++', 'tester/covoar/TraceConverter.<wbr>cc.2.o', 'tester/covoar/TraceList.cc.2.<wbr>o', 'tester/covoar/TraceReaderBase<wbr>.cc.2.o', 'tester/covoar/TraceReaderLogQ<wbr>EMU.cc.2.o', 'tester/covoar/TraceWriterBase<wbr>.cc.2.o', 'tester/covoar/TraceWriterQEMU<wbr>.cc.2.o', '-o/home/joel/rtems-work/rtems<wbr>-tools/build/tester/covoar/tra<wbr>ce-converter', '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld', '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic']</div><div>[229/229] Linking build/tester/covoar/covoar</div><div>09:38:25 runner ['/usr/bin/g++', 'tester/covoar/covoar.cc.3.o', '-o/home/joel/rtems-work/rtems<wbr>-tools/build/tester/covoar/cov<wbr>oar', '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld', '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic']</div><span><div>tester/covoar/libccovoar.a(Des<wbr>iredSymbols.cc.1.o): In function `Coverage::DesiredSymbols::det<wbr>ermineSourceLines(Coverage::Co<wbr>verageRanges*, Coverage::ExecutableInfo*)':</div></span><div>/home/joel/rtems-work/rtems-to<wbr>ols/build/../tester/covoar/Des<wbr>iredSymbols.cc:413: undefined reference to `rld::path::__xpg_basename(std<wbr>::string const&)'</div><div>/home/joel/rtems-work/rtems-to<wbr>ols/build/../tester/covoar/Des<wbr>iredSymbols.cc:415: undefined reference to `rld::path::__xpg_basename(std<wbr>::string const&)'</div><span><div>collect2: error: ld returned 1 exit status</div><div><br></div></span><span><div>tester/covoar/libccovoar.a(Des<wbr>iredSymbols.cc.1.o): In function `Coverage::DesiredSymbols::det<wbr>ermineSourceLines(Coverage::Co<wbr>verageRanges*, Coverage::ExecutableInfo*)':</div></span><div>/home/joel/rtems-work/rtems-to<wbr>ols/build/../tester/covoar/Des<wbr>iredSymbols.cc:413: undefined reference to `rld::path::__xpg_basename(std<wbr>::string const&)'</div><div>/home/joel/rtems-work/rtems-to<wbr>ols/build/../tester/covoar/Des<wbr>iredSymbols.cc:415: undefined reference to `rld::path::__xpg_basename(std<wbr>::string const&)'</div><span><div>collect2: error: ld returned 1 exit status</div><div><br></div></span><div>Waf: Leaving directory `/home/joel/rtems-work/rtems-t<wbr>ools/build'</div><span><div>Build failed</div><div> -> task in 'trace-converter' failed with exit status 1: </div></span><div>        {task 34721616: cxxprogram TraceConverter.cc.2.o,TraceLis<wbr>t.cc.2.o,TraceReaderBase.cc.2.<wbr>o,TraceReaderLogQEMU.cc.2.o,Tr<wbr>aceWriterBase.cc.2.o,TraceWrit<wbr>erQEMU.cc.2.o -> trace-converter}</div><div>['/usr/bin/g++', 'tester/covoar/TraceConverter.<wbr>cc.2.o', 'tester/covoar/TraceList.cc.2.<wbr>o', 'tester/covoar/TraceReaderBase<wbr>.cc.2.o', 'tester/covoar/TraceReaderLogQ<wbr>EMU.cc.2.o', 'tester/covoar/TraceWriterBase<wbr>.cc.2.o', 'tester/covoar/TraceWriterQEMU<wbr>.cc.2.o', '-o/home/joel/rtems-work/rtems<wbr>-tools/build/tester/covoar/tra<wbr>ce-converter', '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld', '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic']</div><span><div> -> task in 'covoar' failed with exit status 1: </div></span><div>        {task 34820256: cxxprogram covoar.cc.3.o -> covoar}</div><div>['/usr/bin/g++', 'tester/covoar/covoar.cc.3.o', '-o/home/joel/rtems-work/rtems<wbr>-tools/build/tester/covoar/cov<wbr>oar', '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld', '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic']</div></div><div>==============================<wbr>======================</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625m_3354552205201062185m_-5109157323605541732h5"><div dir="ltr"><div><br></div><div>---</div><div><pre style="color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;white-space:pre-wrap">diff --git a/tester/covoar/wscript b/tester/covoar/wscript
index 55d5ec9..dd4ad83 100644
--- a/tester/covoar/wscript
+++ b/tester/covoar/wscript
@@ -63,6 +63,7 @@ def build(bld):
     rtl_includes = [rtemstoolkit,
                    rtemstoolkit + '/elftoolchain/libelf',
                    rtemstoolkit + '/elftoolchain/common',
+                   rtemstoolkit + '/elftoolchain/libdwarf',
                    rtemstoolkit + '/libiberty']
     if bld.env.DEST_OS == 'win32':
         rtl_includes += [rtemstoolkit + '/win32']</pre><span class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625m_3354552205201062185m_-5109157323605541732m_-3988439629750368059gmail-HOEnZb"><font color="#888888"><br></font></span></div></div><div class="gmail_extra"><span class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625m_3354552205201062185m_-5109157323605541732m_-3988439629750368059gmail-HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625m_3354552205201062185m_-5109157323605541732m_-3988439629750368059gmail-m_9093139070613751218gmail_signature"><div dir="ltr"><div><div dir="ltr">-- vijay</div></div></div></div></div></font></span><div><div class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625m_3354552205201062185m_-5109157323605541732m_-3988439629750368059gmail-h5">
<br><div class="gmail_quote">On 7 May 2018 at 13:30, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span>On 6 May 2018 at 13:29, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" rel="noreferrer" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/5/18 5:28 pm, Vijay Kumar Banerjee wrote:<span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 6 May 2018 at 08:54, Chris Johns <<a href="mailto:chrisj@rtems.org" rel="noreferrer" target="_blank">chrisj@rtems.org</a> <mailto:<a href="mailto:chrisj@rtems.org" rel="noreferrer" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
<br>
        Would you please try `waf clean build` to see if rebuilding<br>
        everything fixes this?<br>
<br>
still getting the same error .<br>
I'm using g++ 7.3.1 on fedora 27.<br>
</blockquote>
<br></span>
OK<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you have changed something in the code, can you please send a patch for the same ?<br>
</blockquote>
<br></span>
I have not changed anything. I do not have a Linux box to try.<span class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625m_3354552205201062185m_-5109157323605541732m_-3988439629750368059gmail-m_9093139070613751218m_3581814237704045480HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote></span><div>I tried to do it afresh as well, it's still failing to build.</div><div>Can someone please try to build it in a linux system ? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_6003438246185244237m_-9155371500798737038m_-1393279103389517632m_-1407832729160863067gmail-m_1408962617801198673m_323651706870341625m_3354552205201062185m_-5109157323605541732m_-3988439629750368059gmail-m_9093139070613751218m_3581814237704045480HOEnZb"><font color="#888888">
Chris<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/devel</a><br></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/devel</a><br></blockquote></div><br></div>
</blockquote></div></div></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>