> warning: exec file is newer than core file.
Unfortunately, the difference appears to be too large. The stack
trace is mostly nonsensical. Just a hint that (de)serialization
is happening.
On 10/26/18 5:37 AM, Heinz Junkes wrote:
> Hi Michael,
> the #132 solved the pvlist issue. Thanks for that.
>
> The pvget segmentation fault is still existing (It might be that the reason is on the server side, its my famous tinkered rtems-epics stuff)
> And as usual, I need your help again to get deeper into this.
Since the issue is with a host side tool, can you
try to reproduce with a clean build? This would
also be a useful pre-release data point.
https://github.com/epics-base/epics-base
Also, what is the type/Structure of the PV which is being retrieved?
> I have:
>
> epics@kannsein:~$ gdb pvget core
> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from pvget...done.
>
> warning: exec file is newer than core file.
> [New LWP 53453]
> [New LWP 53452]
> [New LWP 53444]
> [New LWP 53450]
> [New LWP 53446]
> [New LWP 53451]
> [New LWP 53447]
> [New LWP 53454]
> [New LWP 53448]
> [New LWP 53449]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `pvget CRYAFM:struckNTNDArray'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x00007f57be8fcad7 in std::tr1::__shared_ptr<unsigned short, (__gnu_cxx::_Lock_policy)2>::__shared_ptr (this=<optimized out>)
> at /usr/include/c++/5/tr1/shared_ptr.h:547
> 547 : _M_ptr(0), _M_refcount() // never throws
> [Current thread is 1 (Thread 0x7f57bb9fe700 (LWP 53453))]
> (gdb) thread apply all backtrace
>
> Thread 10 (Thread 0x7f57bbc02700 (LWP 53449)):
> #0 0x00007f57bdd58333 in recvfrom () at ../sysdeps/unix/syscall-template.S:84
> #1 0x00007f57bec730c7 in recvfrom (__addr_len=0x7f57bbc01d48, __addr=0x7f57bbc01d60, __flags=0, __n=65487, __buf=0x145a098,
> __fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/socket2.h:76
> #2 epics::pvAccess::BlockingUDPTransport::run (this=0x1419bd0) at ../../src/remote/blockingUDPTransport.cpp:223
> #3 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #4 0xffffffffffffffff in ?? ()
> #5 0xffffffffffffffff in ?? ()
> #6 0xffffffffffffffff in ?? ()
> #7 0xffffffffffffffff in ?? ()
> #8 0xffffffffffffffff in ?? ()
> #9 0xffffffffffffffff in ?? ()
> #10 0xffffffffffffffff in ?? ()
> #11 0xffffffffffffffff in ?? ()
> #12 0xffffffffffffffff in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffffffffffff in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> Thread 9 (Thread 0x7f57bf2a0700 (LWP 53448)):
> #0 0x00007f57bdd58333 in recvfrom () at ../sysdeps/unix/syscall-template.S:84
> #1 0x00007f57bec730c7 in recvfrom (__addr_len=0x7f57bf29fd48, __addr=0x7f57bf29fd60, __flags=0, __n=65487, __buf=0x143a0c8,
> __fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/socket2.h:76
> #2 epics::pvAccess::BlockingUDPTransport::run (this=0x14198c0) at ../../src/remote/blockingUDPTransport.cpp:223
> #3 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #4 0xffffffffffffffff in ?? ()
> #5 0xffffffffffffffff in ?? ()
> #6 0xffffffffffffffff in ?? ()
> #7 0xffffffffffffffff in ?? ()
> #8 0xffffffffffffffff in ?? ()
> #9 0xffffffffffffffff in ?? ()
> #10 0xffffffffffffffff in ?? ()
> #11 0xffffffffffffffff in ?? ()
> #12 0xffffffffffffffff in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffffffffffff in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> Thread 8 (Thread 0x7f57bb7fd700 (LWP 53454)):
> #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> #1 0x00007f57be5f6eeb in osiSockDiscoverBroadcastAddresses (pList=0x7f57ac01a60c, socket=128, pMatchAddr=0x9)
> at ../../src/osi/os/default/osdNetIntf.c:81
> #2 0x7f276cf0b2fc3d00 in ?? ()
> ---Type <return> to continue, or q <return> to quit---
> #3 0x0000000000000001 in ?? ()
> #4 0x00007f57ac0009d0 in ?? ()
> #5 0x00007f57bec82c50 in epics::pvData::ByteBuffer::put (count=140014784597424, src_offset=0,
> src=0x7f57bed1e138 <epics::pvAccess::detail::PADDING_BYTES> "\377\377\377\377\377\377\377\377", this=<optimized out>)
> at /home/epics/BASE/base-7.0/include/pv/byteBuffer.h:451
> #6 epics::pvAccess::detail::AbstractCodec::alignBuffer (this=0x7f57ac000a88, alignment=<optimized out>) at ../../src/remote/codec.cpp:582
> #7 0x00007f57ac000b48 in ?? ()
> #8 0x00007f57bec8759a in epics::pvAccess::detail::BlockingTCPTransportCodec::sendThread (this=0x7f57bf31fd6f)
> at ../../src/remote/codec.cpp:1166
> #9 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #10 0xffffffffffffffff in ?? ()
> #11 0xffffffffffffffff in ?? ()
> #12 0xffffffffffffffff in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffffffffffff in ?? ()
> #15 0xffffffffffffffff in ?? ()
> #16 0xffffffffffffffff in ?? ()
> #17 0xffffffffffffffff in ?? ()
> #18 0xffffffffffffffff in ?? ()
> #19 0xffffffffffffffff in ?? ()
> #20 0xffffffffffffffff in ?? ()
> #21 0x0000000000000000 in ?? ()
>
> Thread 7 (Thread 0x7f57bf321700 (LWP 53447)):
> #0 0x00007f57bdd58333 in recvfrom () at ../sysdeps/unix/syscall-template.S:84
> #1 0x00007f57bec730c7 in recvfrom (__addr_len=0x7f57bf320d48, __addr=0x7f57bf320d60, __flags=0, __n=65487, __buf=0x141a0f8,
> __fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/socket2.h:76
> #2 epics::pvAccess::BlockingUDPTransport::run (this=0x1419050) at ../../src/remote/blockingUDPTransport.cpp:223
> #3 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #4 0xffffffffffffffff in ?? ()
> #5 0xffffffffffffffff in ?? ()
> #6 0xffffffffffffffff in ?? ()
> #7 0xffffffffffffffff in ?? ()
> #8 0xffffffffffffffff in ?? ()
> #9 0xffffffffffffffff in ?? ()
> #10 0xffffffffffffffff in ?? ()
> #11 0xffffffffffffffff in ?? ()
> #12 0xffffffffffffffff in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffffffffffff in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> Thread 6 (Thread 0x7f57bbb00700 (LWP 53451)):
> #0 0x00007f57bdd58333 in recvfrom () at ../sysdeps/unix/syscall-template.S:84
> ---Type <return> to continue, or q <return> to quit---
> #1 0x00007f57bec730c7 in recvfrom (__addr_len=0x7f57bbaffd48, __addr=0x7f57bbaffd60, __flags=0, __n=65487, __buf=0x149ad78,
> __fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/socket2.h:76
> #2 epics::pvAccess::BlockingUDPTransport::run (this=0x149ab70) at ../../src/remote/blockingUDPTransport.cpp:223
> #3 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #4 0xffffffffffffffff in ?? ()
> #5 0xffffffffffffffff in ?? ()
> #6 0xffffffffffffffff in ?? ()
> #7 0xffffffffffffffff in ?? ()
> #8 0xffffffffffffffff in ?? ()
> #9 0xffffffffffffffff in ?? ()
> #10 0xffffffffffffffff in ?? ()
> #11 0xffffffffffffffff in ?? ()
> #12 0xffffffffffffffff in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffffffffffff in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> Thread 5 (Thread 0x7f57bf3a2700 (LWP 53446)):
> #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
> #1 0x00007f57be5f7099 in epicsMessageQueueCreate (capacity=21068572, maxMessageSize=393) at ../../src/osi/os/default/osdMessageQueue.cpp:74
> #2 0x0000000000406470 in __gxx_personality_v0@plt ()
> #3 0x3fcbc332ab5f2510 in ?? ()
> #4 0x000000005bd037ab in ?? ()
> #5 0x00000000042f7132 in ?? ()
> #6 0x00007f57b4000930 in ?? ()
> #7 0x7f276cf0b2fc3d00 in ?? ()
> #8 0x0000000001417930 in ?? ()
> #9 0x0000000001417938 in ?? ()
> #10 0x0000000001418fc0 in ?? ()
> #11 0x00007f57be899aa5 in epics::pvData::Timer::run (this=0x1417b1c) at ../../src/misc/timer.cpp:84
> #12 0x0000000001417930 in ?? ()
> #13 0x0000000001417938 in ?? ()
> #14 0x0000000001418fc0 in ?? ()
> #15 0x00007f57be89a86c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose (this=0x30)
> at /usr/include/c++/5/bits/basic_string.h:179
> #16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0x30, __in_chrg=<optimized out>)
> at /usr/include/c++/5/bits/basic_string.h:543
> #17 epics::pvData::Status::~Status (this=0x0, __in_chrg=<optimized out>) at ../../src/misc/pv/status.h:68
> #18 epics::pvData::Status::~Status (this=0x0, __in_chrg=<optimized out>) at ../../src/misc/pv/status.h:68
> #19 0x00007f57bf3a1dc0 in ?? ()
> #20 0x00007f57bf3a1de0 in ?? ()
> #21 0x00007f57bf3a1dd0 in ?? ()
> #22 0x0000000036319a2a in ?? ()
> #23 0x0000000032dc970a in ?? ()
> ---Type <return> to continue, or q <return> to quit---
> #24 0x0000000036319a29 in ?? ()
> #25 0x000000003ab9772f in ?? ()
> #26 0x0000000001418760 in ?? ()
> #27 0x0000000001418fc0 in ?? ()
> #28 0x0000000036319a2b in ?? ()
> #29 0x00000000042f590e in ?? ()
> #30 0x0000000036319a2b in ?? ()
> #31 0x00000000042f590e in ?? ()
> #32 0x0000000001417968 in ?? ()
> #33 0x7f276cf0b2fc3d00 in ?? ()
> #34 0x0000000001417968 in ?? ()
> #35 0x0000000001417968 in ?? ()
> #36 0x0000000000000000 in ?? ()
>
> Thread 4 (Thread 0x7f57bbb81700 (LWP 53450)):
> #0 0x00007f57bdd58333 in recvfrom () at ../sysdeps/unix/syscall-template.S:84
> #1 0x00007f57bec730c7 in recvfrom (__addr_len=0x7f57bbb80d48, __addr=0x7f57bbb80d60, __flags=0, __n=65487, __buf=0x147aa58,
> __fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/socket2.h:76
> #2 epics::pvAccess::BlockingUDPTransport::run (this=0x147a850) at ../../src/remote/blockingUDPTransport.cpp:223
> #3 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #4 0xffffffffffffffff in ?? ()
> #5 0xffffffffffffffff in ?? ()
> #6 0xffffffffffffffff in ?? ()
> #7 0xffffffffffffffff in ?? ()
> #8 0xffffffffffffffff in ?? ()
> #9 0xffffffffffffffff in ?? ()
> #10 0xffffffffffffffff in ?? ()
> #11 0xffffffffffffffff in ?? ()
> #12 0xffffffffffffffff in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffffffffffff in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> Thread 3 (Thread 0x7f57bf3a4740 (LWP 53444)):
> #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
> #1 0x00007f57be5f7099 in epicsMessageQueueCreate (capacity=21056140, maxMessageSize=393) at ../../src/osi/os/default/osdMessageQueue.cpp:74
> #2 0x00000000014152e0 in ?? ()
> #3 0x4008000000000000 in ?? ()
> #4 0x000000005bd037ac in ?? ()
> #5 0x000000003abb2474 in ?? ()
> #6 0x0000000000000000 in ?? ()
>
> Thread 2 (Thread 0x7f57bba7f700 (LWP 53452)):
> #0 0x00007f57bdd58333 in recvfrom () at ../sysdeps/unix/syscall-template.S:84
> ---Type <return> to continue, or q <return> to quit---
> #1 0x00007f57bec730c7 in recvfrom (__addr_len=0x7f57bba7ed48, __addr=0x7f57bba7ed60, __flags=0, __n=65487, __buf=0x14bb928,
> __fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/socket2.h:76
> #2 epics::pvAccess::BlockingUDPTransport::run (this=0x14bb720) at ../../src/remote/blockingUDPTransport.cpp:223
> #3 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #4 0xffffffffffffffff in ?? ()
> #5 0xffffffffffffffff in ?? ()
> #6 0xffffffffffffffff in ?? ()
> #7 0xffffffffffffffff in ?? ()
> #8 0xffffffffffffffff in ?? ()
> #9 0xffffffffffffffff in ?? ()
> #10 0xffffffffffffffff in ?? ()
> #11 0xffffffffffffffff in ?? ()
> #12 0xffffffffffffffff in ?? ()
> #13 0xffffffffffffffff in ?? ()
> #14 0xffffffffffffffff in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> Thread 1 (Thread 0x7f57bb9fe700 (LWP 53453)):
> #0 0x00007f57be8fcad7 in std::tr1::__shared_ptr<unsigned short, (__gnu_cxx::_Lock_policy)2>::__shared_ptr (this=<optimized out>)
> at /usr/include/c++/5/tr1/shared_ptr.h:547
> #1 std::tr1::shared_ptr<unsigned short>::shared_ptr (this=<optimized out>) at /usr/include/c++/5/tr1/shared_ptr.h:990
> #2 epics::pvData::detail::shared_vector_base<unsigned short>::shared_vector_base (O=..., this=<optimized out>)
> at ../../src/misc/pv/sharedVector.h:160
> #3 epics::pvData::shared_vector<unsigned short, void>::shared_vector (t=..., O=..., this=<optimized out>)
> at ../../src/misc/pv/sharedVector.h:396
> #4 epics::pvData::thaw<epics::pvData::shared_vector<unsigned short const, void> > (src=...) at ../../src/misc/pv/sharedVector.h:903
> #5 epics::pvData::PVValueArray<unsigned short>::deserialize (this=0x7f57a4002c00, pbuffer=0x2d5, pcontrol=0x7f57ac0009d8)
> at ../../src/factory/PVDataCreateFactory.cpp:225
> #6 0x00007f57be8dbace in __gnu_cxx::__atomic_add_single (__val=<optimized out>, __mem=<optimized out>)
> at /usr/include/c++/5/ext/atomicity.h:74
> #7 __gnu_cxx::__atomic_add_dispatch (__val=<optimized out>, __mem=<optimized out>) at /usr/include/c++/5/ext/atomicity.h:98
> #8 std::tr1::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_add_ref_copy (this=<optimized out>) at /usr/include/c++/5/tr1/shared_ptr.h:128
> #9 std::tr1::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count (__r=..., this=<optimized out>)
> at /usr/include/c++/5/tr1/shared_ptr.h:348
> #10 std::tr1::__shared_ptr<epics::pvData::PVField const, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<epics::pvData::PVField> (__r=...,
> this=<optimized out>) at /usr/include/c++/5/tr1/shared_ptr.h:573
> #11 std::tr1::shared_ptr<epics::pvData::PVField const>::shared_ptr<epics::pvData::PVField> (__r=..., this=<optimized out>)
> at /usr/include/c++/5/tr1/shared_ptr.h:1003
> #12 epics::pvData::PVUnion::get (this=<optimized out>) at ../pv/pvData.h:939
> #13 epics::pvData::PVUnion::dumpValue (this=<optimized out>, o=...) at ../../src/factory/PVUnion.cpp:184
> #14 0x00007f57ac0009d8 in ?? ()
> #15 0x00000000014dc810 in ?? ()
> #16 0x00000000014dc550 in ?? ()
> #17 0x00007f57bb9fdaf0 in ?? ()
> ---Type <return> to continue, or q <return> to quit---
> #18 0x00007f57ac000a18 in ?? ()
> #19 0x00007f57bb9fdd20 in ?? ()
> #20 0x00000000014dc648 in ?? ()
> #21 0x0000000000000050 in ?? ()
> #22 0x00007f57bec9d73c in (anonymous namespace)::ChannelGetImpl::normalResponse (this=0x7f57a4002ba0,
> transport=std::tr1::shared_ptr (count 1314147887, weak 1920090435) 0x7f57beb9e868 <vtable for epics::pvData::BitSet+16>,
> payloadBuffer=0x7f57be8d0cfd <epics::pvData::PVStructure::dumpValue(std::ostream&) const+189>, status=...)
> at ../../src/remoteClient/clientContextImpl.cpp:653
> #23 0x00007f57bec96978 in (anonymous namespace)::BaseRequestImpl::response (this=0x14dc550,
> transport=std::tr1::shared_ptr (count 6, weak 1) 0x7f57ac0009d8, version=<optimized out>, payloadBuffer=0x7f57ac000a18)
> at ../../src/remoteClient/clientContextImpl.cpp:294
> #24 0x00007f57bec98aa2 in (anonymous namespace)::ResponseRequestHandler::handleResponse (this=<optimized out>, responseFrom=<optimized out>,
> transport=std::tr1::shared_ptr (count 6, weak 1) 0x7f57ac0009d8, version=1 '\001', command=<optimized out>, payloadSize=<optimized out>,
> payloadBuffer=0x7f57ac000a18) at ../../src/remoteClient/clientContextImpl.cpp:2502
> #25 0x00007f57bec9574f in (anonymous namespace)::ClientResponseHandler::handleResponse (this=<optimized out>, responseFrom=<optimized out>,
> transport=..., version=<optimized out>, command=<optimized out>, payloadSize=<optimized out>, payloadBuffer=0x7f57ac000a18)
> at ../../src/remoteClient/clientContextImpl.cpp:3008
> #26 0x00007f57bec879b5 in epics::pvAccess::detail::BlockingTCPTransportCodec::processApplicationMessage (this=0x7f57ac0009d0)
> at ../../src/remote/pv/codec.h:352
> #27 epics::pvAccess::detail::AbstractCodec::processReadNormal (this=0x7f57ac0009d0) at ../../src/remote/codec.cpp:224
> #28 0x00007f57bec87e95 in epics::pvAccess::detail::AbstractCodec::processRead (this=this@entry=0x7f57ac0009d0)
> at ../../src/remote/codec.cpp:128
> #29 0x00007f57bec87faa in epics::pvAccess::detail::BlockingTCPTransportCodec::receiveThread (this=0x7f57ac0009d0)
> at ../../src/remote/codec.cpp:1138
> #30 0x00007f57be5edc99 in epicsMutexOsiInit () at ../../src/osi/epicsMutex.cpp:81
> #31 0xffffffffffffffff in ?? ()
> #32 0xffffffffffffffff in ?? ()
> #33 0xffffffffffffffff in ?? ()
> #34 0xffffffffffffffff in ?? ()
> #35 0xffffffffffffffff in ?? ()
> #36 0xffffffffffffffff in ?? ()
> #37 0xffffffffffffffff in ?? ()
> #38 0xffffffffffffffff in ?? ()
> #39 0xffffffffffffffff in ?? ()
> #40 0xffffffffffffffff in ?? ()
> #41 0xffffffffffffffff in ?? ()
> #42 0x0000000000000000 in ?? ()
> (gdb)
>
>
>
> Danke, Heinz
>> On 25. Oct 2018, at 18:09, Michael Davidsaver <[email protected]> wrote:
>>
>> On 10/25/18 7:45 AM, Patrik Marschalik wrote:
>>> Hi Michael,
>>>
>>> the issue is even stranger.
>>>
>>> We have a host with one network interface, starting a testServer in one
>>> terminal and calling pvlist in another one shows nothing. pvlist
>>> localhost works as expected. Do you have an idea what might be the
>>> problem?
>>
>> At least in part #132 which is now fixed.
>>
>> https://github.com/epics-base/pvAccessCPP/issues/132
>>
>> Which revisions of the various modules are you building?
>>
>> Also, could you extract line numbers from the stack trace?
>> 0x7fe7638179c5 isn't very meaningful :) Please run the following,
>> replacing the addresses with those from a newer run if you have
>> rebuilt the executables/libraries.
>>
>>> addr2line -e ./path/to/pvget 0x7fe7638179c5 0x7fe76234bfc6 0x7fe762345bfb
>>
>>
>>> Thanks
>>>
>>> Patrik
>>>
>>> On Wed, Oct 24, 2018 at 09:37:29PM +0200, Heinz Junkes wrote:
>>>> Hi Michael,
>>>>
>>>> this I got got today from Patrik once:
>>>>
>>>> *** Error in `pvget': munmap_chunk(): invalid pointer:
>>>> 0x00007fe74e0a1010 ***
>>>> ======= Backtrace: =========
>>>> /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7fe762345bfb]
>>>> /lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7fe76234bfc6]
>>>> /home/patrik/GITHUB/epics-base/epics-base/lib/linux-x86_64/libpvAccess.so.6.0.1(_ZN5epics8pvAccess6detail25BlockingTCPTransportCodecD2Ev+0x425)[0x7fe7638179c5]
>>>>
>>>> But there's a more general problem on our side.
>>>>
>>>> It has something to do with multiple networks? And I still haven't understood the impact of all the environments.
>>>>
>>>> Starting testserver:
>>>>
>>>> epics@kannsein:~$ testServer
>>>> VERSION : pvAccess Server v6.0.1-SNAPSHOT
>>>> PROVIDER_NAMES : local,
>>>> BEACON_ADDR_LIST :
>>>> AUTO_BEACON_ADDR_LIST : 1
>>>> BEACON_PERIOD : 15
>>>> BROADCAST_PORT : 5076
>>>> SERVER_PORT : 5075
>>>> RCV_BUFFER_SIZE : 16384
>>>> IGNORE_ADDR_LIST:
>>>> INTF_ADDR_LIST : 0.0.0.0
>>>>
>>>>
>>>> On an other Terminal
>>>>
>>>> epics@kannsein:~/BASE/epics-base$ pvlist
>>>> (no output)
>>>> epics@kannsein:~/BASE/epics-base$ pvlist 141.14.133.59
>>>> testADC
>>>> testAggregate
>>>> testBinaryCounter
>>>> testCounter
>>>> testHistogram
>>>> testMP
>>>> testNameValue
>>>> testRandom
>>>> testTable
>>>>
>>>> epics@kannsein:~/BASE/epics-base$ pvlist 10.20.30.1
>>>> testADC
>>>> testAggregate
>>>> testBinaryCounter
>>>> testCounter
>>>> testHistogram
>>>> testMP
>>>> testNameValue
>>>> testRandom
>>>> testTable
>>>>
>>>> Seems to works on both networks. But why no output on pvlist (without arguments) ?
>>>>
>>>> epics@kannsein:~$ export EPICS_PVAS_AUTO_BEACON_ADDR_LIST=NO
>>>> epics@kannsein:~$ export EPICS_PVAS_BEACON_ADDR_LIST=10.20.30.1
>>>> epics@kannsein:~$ export EPICS_PVAS_INTF_ADDR_LIST=10.20.30.1
>>>> epics@kannsein:~$ testServer
>>>> VERSION : pvAccess Server v6.0.1-SNAPSHOT
>>>> PROVIDER_NAMES : local,
>>>> BEACON_ADDR_LIST : 10.20.30.1
>>>> AUTO_BEACON_ADDR_LIST : 0
>>>> BEACON_PERIOD : 15
>>>> BROADCAST_PORT : 5076
>>>> SERVER_PORT : 5075
>>>> RCV_BUFFER_SIZE : 16384
>>>> IGNORE_ADDR_LIST:
>>>> INTF_ADDR_LIST : 10.20.30.1
>>>>
>>>>
>>>> After 15 about 15 seconds the other terminal shows
>>>>
>>>> epics@kannsein:~/BASE/epics-base$ pvlist
>>>> GUID 0x0CC9D05B00000000422E1420 version 1: tcp@[10.20.30.1:5075]
>>>> epics@kannsein:~/BASE/epics-base$ pvlist 0x0CC9D05B00000000422E1420
>>>> Failed to resolve GUID '0x0CC9D05B00000000422E1420’!
>>>>
>>>> After that no more output on pvlist without arguments????
>>>> epics@kannsein:~/BASE/epics-base$ pvlist
>>>> epics@kannsein:~/BASE/epics-base$
>>>>
>>>> this still works
>>>>
>>>> epics@kannsein:~/BASE/epics-base$ pvlist 10.20.30.1
>>>> testADC
>>>> testAggregate
>>>> testBinaryCounter
>>>> testCounter
>>>> testHistogram
>>>> testMP
>>>> testNameValue
>>>> testRandom
>>>> testTable
>>>>
>>>> What is the right way to define the environments in our situation?
>>>>
>>>> Thank you Heinz
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Fritz-Haber-Institut | Phone: (+49 30) 8413-4270
>>>> Heinz Junkes | Fax (G3+G4): (+49 30) 8413-5900
>>>> Faradayweg 4-6 |
>>>> D - 14195 Berlin | E-Mail: [email protected]
>>>> ------------------------------------------------------------------------------
>>>>
>>>>> On 24. Oct 2018, at 16:15, Michael Davidsaver <[email protected]> wrote:
>>>>>
>>>>> What modules versions/revisions are involved? Can you use gdb
>>>>> to extract a stack trace from the core file?
>>>>>
>>>>>
>>>>> On 10/24/18 5:54 AM, Heinz Junkes wrote:
>>>>>> Using epics-base master on Ubuntu 16.4 (same on debian 9)
>>>>>>
>>>>>> pvget -> segmentation fault
>>>>>>
>>>>>> epics@kannsein:/var/log$ pvget CRYAFM:struckNTTable
>>>>>> CRYAFM:struckNTTable
>>>>>> epics:nt/NTTable:1.0
>>>>>> time_t timeStamp 2018-10-24T15:27:48.075 0
>>>>>> string[] labels [The SIS TS,The X,The Y,The Z]
>>>>>> structure value
>>>>>> double[] ts [0,0,0,0,0,0,0,0,100,0,0,0,0,0,0,0,200,0,0,0,0,0,0,0,300,0,0,0,0,0,0,0,400,0,0,0,0,0,0,0,500,0,0,0,0,0,0,0,600,0,0,0,0,0,0,0,700,0,0,0,0,0,0,0,800,0,0,0,0,0,0,0,900,0,0,0,0,0,0,0,1000,0,0,0,0,0,0,0,1100,0,0,0,0,0,0,0,1200,0,0,0]
>>>>>> double[] X []
>>>>>> double[] Y []
>>>>>> double[] Z []
>>>>>>
>>>>>>
>>>>>> Segmentation fault (core dumped)
>>>>>>
>>>>>>
>>>>>> In kern.log we can find
>>>>>> Oct 24 14:42:11 kannsein kernel: [788447.325497] traps: pvget[55565] general protection ip:7f6e9577c512 sp:7fffe1ea90d0 error:0 in libc-2.23.so[7f6e956f8000+1c0000]
>>>>>> Oct 24 14:42:19 kannsein kernel: [788456.015443] traps: pvget[55587] general protection ip:7f00b8c3a512 sp:7ffdbf0c6150 error:0 in libc-2.23.so[7f00b8bb6000+1c0000]
>>>>>> Oct 24 14:43:04 kannsein kernel: [788500.715803] traps: pvget[55616] general protection ip:7f88c21b8512 sp:7ffcf2fdba60 error:0 in libc-2.23.so[7f88c2134000+1c0000]
>>>>>> Oct 24 14:45:14 kannsein kernel: [788630.968783] traps: pvget[55636] general protection ip:7f4d4fa00512 sp:7ffc280a7b40 error:0 in libc-2.23.so[7f4d4f97c000+1c0000]
>>>>>> Oct 24 14:45:27 kannsein kernel: [788643.257952] traps: pvget[55648] general protection ip:7f088b665512 sp:7ffcc5d6ed40 error:0 in libc-2.23.so[7f088b5e1000+1c0000]
>>>>>> Oct 24 14:46:09 kannsein kernel: [788685.910016] traps: pvget[55661] general protection ip:7f750da52512 sp:7ffd13bdf0b0 error:0 in libc-2.23.so[7f750d9ce000+1c0000]
>>>>>> Oct 24 14:46:21 kannsein kernel: [788697.759313] traps: pvget[55673] general protection ip:7f859f104512 sp:7fff5629ff80 error:0 in libc-2.23.so[7f859f080000+1c0000]
>>>>>> Oct 24 14:47:10 kannsein kernel: [788746.457913] traps: pvget[55685] general protection ip:7f9d4348f512 sp:7fffd170dba0 error:0 in libc-2.23.so[7f9d4340b000+1c0000]
>>>>>> Oct 24 14:47:27 kannsein kernel: [788763.257920] traps: pvget[55697] general protection ip:7fc04a7b2512 sp:7ffc9e722280 error:0 in libc-2.23.so[7fc04a72e000+1c0000]
>>>>>> Oct 24 14:47:40 kannsein kernel: [788776.330929] traps: pvget[55709] general protection ip:7f0774726512 sp:7ffd41eb8d90 error:0 in libc-2.23.so[7f07746a2000+1c0000]
>>>>>>
>>>>>> earlier this morning:
>>>>>>
>>>>>> Oct 24 11:13:14 kannsein kernel: [775910.021560] TCP-rx[53453]: segfault at 7f57bb5fd028 ip 00007f57be8fcad7 sp 00007f57bb9fd890 error 6 in libpvData.so.7.0.1[7f57be826000+178000]
>>>>>> Oct 24 11:14:06 kannsein kernel: [775961.525926] TCP-rx[53465]: segfault at 7fcbd9a80028 ip 00007fcbdcd7fad7 sp 00007fcbd9e80890 error 6 in libpvData.so.7.0.1[7fcbdcca9000+178000]
>>>>>> Oct 24 11:27:12 kannsein kernel: [776747.380789] TCP-rx[53569]: segfault at 7efe437dd020 ip 00007efe46adcad7 sp 00007efe43bdd890 error 6 in libpvData.so.7.0.1[7efe46a06000+178000]
>>>>>> Oct 24 11:27:54 kannsein kernel: [776790.105153] TCP-rx[53586]: segfault at 7fdb33afc038 ip 00007fdb3ae14ad7 sp 00007fdb33efc890 error 6 in libpvData.so.7.0.1[7fdb3ad3e000+178000]
>>>>>> Oct 24 13:24:55 kannsein kernel: [783811.567841] TCP-rx[53954]: segfault at 7f9e25019038 ip 00007f9e28318ad7 sp 00007f9e25419890 error 6 in libpvData.so.7.0.1[7f9e28242000+178000]
>>>>>> Oct 24 13:25:18 kannsein kernel: [783834.055359] TCP-rx[53983]: segfault at 7f04138fc000 ip 00007f0416bfbad7 sp 00007f0413cfc890 error 6 in libpvData.so.7.0.1[7f0416b25000+178000]
>>>>>> Oct 24 13:26:06 kannsein kernel: [783882.134154] TCP-rx[53998]: segfault at 7f9094ad6038 ip 00007f9097dd5ad7 sp 00007f9094ed6890 error 6 in libpvData.so.7.0.1[7f9097cff000+178000]
>>>>>> Oct 24 13:26:31 kannsein kernel: [783907.132452] TCP-rx[54010]: segfault at 7f16139fa010 ip 00007f1616cf9ad7 sp 00007f1613dfa890 error 6 in libpvData.so.7.0.1[7f1616c23000+178000]
>>>>>> Oct 24 13:26:45 kannsein kernel: [783921.247824] TCP-rx[54022]: segfault at 7f7cfebe6010 ip 00007f7d01ee5ad7 sp 00007f7cfefe6890 error 6 in libpvData.so.7.0.1[7f7d01e0f000+178000]
>>>>>> Oct 24 13:31:08 kannsein kernel: [784183.770344] TCP-rx[54084]: segfault at 7fcce9f67020 ip 00007fcced266ad7 sp 00007fccea367890 error 6 in libpvData.so.7.0.1[7fcced190000+178000]
>>>>>>
>>>>>>
>>>>>> Sometimes it works well … ;-(
>>>>>>
>>>>>> System runs with two network-domains (141.14.128.0, 10.0.30.0)
>>>>>>
>>>>>> Any ideas?
>>>>>> Heinz
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
>>>>>> Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
>>>>>> [General Data Protection Regulation (GDPR)] der Europaeischen Union.
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
> ----------------------------------------------------------------------
> Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
> Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
> [General Data Protection Regulation (GDPR)] der Europaeischen Union.
>
- References:
- segmentation error pvdata -> libc Heinz Junkes
- Re: segmentation error pvdata -> libc Michael Davidsaver
- Re: segmentation error pvdata -> libc Patrik Marschalik
- Re: segmentation error pvdata -> libc Michael Davidsaver
- Re: segmentation error pvdata -> libc Heinz Junkes
- Navigate by Date:
- Prev:
Re: segmentation error pvdata -> libc Heinz Junkes
- Next:
Re: DM recommedation. J. Lewis Muir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: segmentation error pvdata -> libc Heinz Junkes
- Next:
DM recommedation. Kline, David
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|