caget segmentation fault
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Triaged
|
Undecided
|
Jeff Hill |
Bug Description
base= R3.14.12
host arch= linux-x86_64
trying to caget an existing channel over a slow network yields a Segmentation fault:
% caget lbb:heartbeat
Channel connect timed out: 'lbb:heartbeat' not found.
Segmentation fault (core dumped)
from the same terminal session, I can access the channel increasing the wait time:
% caget -w5 lbb:heartbeat
lbb:heartbeat 58
Despite the message saying 'channel not found' when I get the core dump, channel that really do not exist handle well:
% caget lbb:doesnotexist
Channel connect timed out: 'lbb:doesnotexist' not found.
recompiled linux-x86_64-debug that also core dump using the same example:
% gdb -e ./bin/linux-
GNU gdb (GDB) Fedora (7.2-41.fc14)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://
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-
For bug reporting instructions, please see:
<http://
[New Thread 6235]
[New Thread 6236]
[New Thread 6233]
[New Thread 6231]
[New Thread 6232]
Missing separate debuginfo for /export/
Try: yum --disablerepo='*' --enablerepo=
Missing separate debuginfo for /export/
Try: yum --disablerepo='*' --enablerepo=
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo=
Reading symbols from /export/
Loaded symbols for /export/
Reading symbols from /export/
Loaded symbols for /export/
Reading symbols from /lib64/
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/lib64/
Loaded symbols for /usr/lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/
Loaded symbols for /lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/
Loaded symbols for /lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/
Reading symbols from /lib64/
Loaded symbols for /lib64/
Core was generated by `./bin/
Program terminated with signal 11, Segmentation fault.
#0 0x00007f612b874538 in tsDLList<
230 nextNode.pPrev = theNode.pPrev;
Missing separate debuginfos, use: debuginfo-install glibc-2.13-1.x86_64 libgcc-
(gdb) t apply all bt
Thread 5 (Thread 0x7f612b597700 (LWP 6232)):
#0 0x000000387760b3b4 in pthread_
#1 0x00007f612b5fdebc in condWait (condId=0x24f99a8, mutexId=0x24f9980) at ../../.
#2 0x00007f612b5fe214 in epicsEventWait (pevent=0x24f9980) at ../../.
#3 0x00007f612b5f6dfa in epicsEvent::wait (this=0x24f9838) at ../../.
#4 0x00007f612b5f3707 in ipAddrToAsciiEn
#5 0x00007f612b5f542c in epicsThreadCall
#6 0x00007f612b5fc85e in start_routine (arg=0x24f9bb0) at ../../.
#7 0x0000003877606ccb in start_thread () from /lib64/
#8 0x0000003876ae0c2d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f612b599740 (LWP 6231)):
#0 0x000000387760b3b4 in pthread_
#1 0x00007f612b5fdebc in condWait (condId=0x24f92e8, mutexId=0x24f92c0) at ../../.
#2 0x00007f612b5fe214 in epicsEventWait (pevent=0x24f92c0) at ../../.
#3 0x00007f612b5f6dfa in epicsEvent::wait (this=0x24f8fd8) at ../../.
#4 0x00007f612b860871 in cac::~cac (this=0x24f8de0, __in_chrg=<value optimized out>) at ../cac.cpp:312
#5 0x00007f612b860d0e in cac::~cac (this=0x24f8de0, __in_chrg=<value optimized out>) at ../cac.cpp:343
#6 0x00007f612b889889 in epics_auto_
from /export/
#7 0x00007f612b888ddc in epics_auto_
from /export/
#8 0x00007f612b8867de in ca_client_
#9 0x00007f612b886a60 in ca_client_
#10 0x00007f612b86b8bd in ca_context_destroy () at ../access.cpp:252
#11 0x0000000000403737 in ?? ()
#12 0x00007fff34f759f8 in ?? ()
#13 0x0000000200000100 in ?? ()
#14 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7f612b516700 (LWP 6233)):
#0 0x000000387760b71e in pthread_
#1 0x00007f612b5fde78 in condTimedwait (condId=0x24fa1c8, mutexId=0x24fa1a0, time=0x7f612b51
#2 0x00007f612b5fe34a in epicsEventWaitW
#3 0x00007f612b5f6e6c in epicsEvent::wait (this=0x24f9f70, timeOut=
#4 0x00007f612b605749 in timerQueueActiv
#5 0x00007f612b5f542c in epicsThreadCall
#6 0x00007f612b5fc85e in start_routine (arg=0x24fa3d0) at ../../.
#7 0x0000003877606ccb in start_thread () from /lib64/
#8 0x0000003876ae0c2d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f612b1ca700 (LWP 6236)):
#0 0x000000387760b71e in pthread_
#1 0x00007f612b5fde78 in condTimedwait (condId=
#2 0x00007f612b5fe34a in epicsEventWaitW
#3 0x00007f612b5f6e6c in epicsEvent::wait (this=0x7f61240
#4 0x00007f612b5f57cf in epicsThread:
#5 0x00007f612b87c4aa in tcpRecvThread:
#6 0x00007f612b87bc67 in tcpSendThread::run (this=0x7f61240
#7 0x00007f612b5f542c in epicsThreadCall
#8 0x00007f612b5fc85e in start_routine (arg=0x7f612400
#9 0x0000003877606ccb in start_thread () from /lib64/
#10 0x0000003876ae0c2d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f612b24b700 (LWP 6235)):
#0 0x00007f612b874538 in tsDLList<
#1 0x00007f612b8815f2 in tcpiiu:
#2 0x00007f612b863764 in cac::createChan
#3 0x00007f612b863b80 in cac::executeRes
#4 0x00007f612b87f006 in tcpiiu:
#5 0x00007f612b87c961 in tcpRecvThread::run (this=0x7f61240
#6 0x00007f612b5f542c in epicsThreadCall
#7 0x00007f612b5fc85e in start_routine (arg=0x7f612400
---Type <return> to continue, or q <return> to quit---
#8 0x0000003877606ccb in start_thread () from /lib64/
#9 0x0000003876ae0c2d in clone () from /lib64/libc.so.6
(gdb)
This appears to be similar to the 2nd issue in bug 717252.
This crash appears that it might be fixed by prior revision 12173 (occurring on 2011-01-15) to ca/tcpiiu.cpp. Unfortunately, I am having trouble finding a bug report to link to in launchpad.