congliu的博客

你理解错我的意思了，我说的是你的声明中函数名写错了，就是应该是getRandomNumber的但是你声明的和在main中引用的是getRandomNumbers，多了个“s”，另外两个也是同样的问题。

函数名写错了，你声明的分别是：
void getRandomNumbers(short,short&,short&);
void displayProblem(char,short&,short&);
short calCorrectAnswer(char,short,short);
但是函数名是：
void getRandomNumber(short level,short&firstNum,short&secondNum)
void diaplayProblem(char operation,short&firstNum,short&secondNum)
short calCorrectionAnswer(char operation,short firstNum,short secondNum)
可以使用notepad++辅助检查。

最近有进一步研究发现 可以在connect超时时就把本次连接的套接字从临时会话队列中移除

if (CTimer::getTime() > ttl)
{
// Stop waiting for this connection
m_pRcvQueue->removeConnector(m_SocketID);

     // timeout
     e = CUDTException(1, 1, 0);
     break;
  }

果然还是要靠自己啊。
自己追踪了两天，发现是一个状态控制的原因，哪个list容器，原本应该在连接失败，调用close时被删除掉，但是因为(m_bConnecting)_的状态出现问题，
原本应是是true的，却变成了false。

if (m_bListening)
{
m_bListening = false;
m_pRcvQueue->removeListener(this);
}
else if (m_bConnecting)
{
m_pRcvQueue->removeConnector(m_SocketID);
}

猜测可能是recv 的work线程中的函数
// Check connection requests status for all sockets in the RendezvousQueue.
self->m_pRendezvousQueue->updateConnStatus();
将(m_bConnecting)_置为false（在超时的情况下）
// avoid sending too many requests, at most 1 request per 250ms
if (CTimer::getTime() - i->m_pUDT->m_llLastReqTime > 250000)
{
if (CTimer::getTime() >= i->m_ullTTL)
{
// connection timer expired, acknowledge app via epoll
i->m_pUDT->m_bConnecting = false;
CUDT::s_UDTUnited.m_EPoll.update_events(i->m_iID, i->m_pUDT->m_sPollID, UDT_EPOLL_ERR, true);
continue;
}
从而到时在connect失败是，调用close释放了UDT本身的空间，但是list却没有释放，而在list中有一个指针是指向UDT的空间的，而这个空间已经被释放，这样就会出错。
解决方案1：从根源解决
先释放list，在释放UDT时判断list是否释放，如果没有就释放。
解决方案2:简单解决
在connect失败后延时250ms以上，使(m_bConnecting)_得状态一定处于false，并改变删除list的判断条件，已false为释放出发点。
我用的是方案2，因为时间紧，目前未发现修改这个控制变量对其他地方的影响。

不知道你这个.o是自己编译的还是拷贝过来的，他不是说没定义那两个宏，我也是初学者，可能不正确。