mi_new ()

Nobody has claimed this yet.

Hi,
my class code snippet :
```
char * const CGrowingBuffer::Append(const char *pBuf, int nLen)
{
if(nLen <=0)return NULL;

if(m_nCurrPos + nLen > m_nSize)
{
char *pOldBuf = m_pBuffer;
m_pBuffer = new char[m_nCurrPos + nLen]; // line 40
memcpy(m_pBuffer,pOldBuf,m_nSize);
m_nSize = m_nCurrPos + nLen;
delete [] pOldBuf;
}

memcpy(&m_pBuffer[m_nCurrPos],pBuf,nLen);
m_nCurrPos += nLen;
return &m_pBuffer[m_nCurrPos - nLen];
}

void CGrowingBuffer::Reset()
{
m_nCurrPos = 0;
}
```

my calling code:
```
recv_msg[recv_msg_len] = '\0';
Ft_DEBUG <<"recv msg: " << recv_msg <<" type: " << type << " recv_msg_len: " << recv_msg_len << endl;
SgeInMsgMemPool& pool = SgeInMsgMemPool::GetInstance();
auto* pCGrowingBuffer = pool.Get();
if (pCGrowingBuffer) {
pCGrowingBuffer->Reset();
pCGrowingBuffer->Append(recv_msg, recv_msg_len); // line 76
ptr->Enqueue(pCGrowingBuffer);
} else {
Ft_ERROR << "failed to get buffer: " << pool.GetLastGetErrorMsg() << endl;
}
```

coredump:

Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /home/sgesys/flex/libs/libxerces-c-3.1.so
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/df/7633d16d4b4063b8cd02ccdbb11acaa15526f5.debug
Core was generated by `sge_flex -nodeid SGE_FLEX'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000065599e in mi_new ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-222.el7.x86_64 libgcc-4.8.5-28.el7.x86_64 libstdc++-4.8.5-28.el7.x86_64 zlib-1.2.7-17.el7.x86_64
(gdb) bt full
#0 0x000000000065599e in mi_new ()
No symbol table info available.
#1 0x00000000006bc300 in CGrowingBuffer::Append (this=this@entry=0x7f7da2c01fe0,
pBuf=pBuf@entry=0xa39a40 "I00=02,Q52=[{O64=38859658,Q25=38859658.000000,Q26=7035.000000,Q36=5528.000000,Q28=27900.000000,Q29=0.044413,Q27=13114460,Q30=25627162642000,Q31=6594.000000,Q11=20200807,Q12=12:35:05,I10=Ag(T+D),I11=\260", ..., nLen=896) at CGrowingBuffer.cpp:40
pOldBuf =
#2 0x000000000054ec14 in sge_recv_msg (msg=0x7f7da3080c10 "I00=\200\003", type=, con_len=, ctx=) at SgeProxy.cpp:76
recv_msg_len = 896
ret =
pctx =
ptr = 0x7f7da0d40000
__PRETTY_FUNCTION__ = "void sge_recv_msg(const char*, int, unsigned int, void*)"
#3 0x00007f7db3ae502b in __cb_handle_msg (msg=0x7f7da3080c00) at api.c:110
ptr = 0x7f7da0ca0aa0
gtp_msg_session = 0x7f7da3080c00
gtp_msg = 0x7f7da3080c10 "I00=\200\003"
#4 0x00007f7db3ae78b2 in __p_recv_msg (msg=0x7f7da3080c00) at api_lrm.c:333
ret = 0
#5 0x00007f7db2f4a8bf in __p_routine (param=0x0) at z_mpool.c:411
head = 0x7f7da3080c00
ret = 0
count1 = 1
count2 = 0
rt = 0
#6 0x00007f7db29addd5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#7 0x00007f7db12e9b3d in clone () from /lib64/libc.so.6
No symbol table info available.

it seems allocating 896 bytes crashed the program and my server has 32GB memory. what could cause mi_new to fail? I need to improve my code to capture std::bad_alloc exception

Start with the provided stack trace in CGrowingBuffer.cpp:40 and SgeProxy.cpp:76, then inspect the surrounding allocation and message-handling paths. Determine whether the reported 896-byte allocation failure is reproducible and document the actual failure cause and appropriate diagnostic or error-handling outcome.

Written by the indexing model from the issue text.