Admin console not accessable after 15-1 update

[fvdw]

it is still running this morning (the one with memcpy tot memove change) and kernel 199

[brinka123]

When this is stable, maybe remove the delay, and test this (so with the memove).
Probably your read this already, memove accepts overlapping source and distance, but is slower...

My setup with #166 kernel is still like a rock....

[fvdw]

it is still running, yep memmove will be a little slower but you will never notice it looking to download speeds in general achieved by nzbget

I will let it run for at least one more day before trying with the usleep(100)

[brinka123]

Kernel #166 still running, stable as a rock...

[fvdw]

ok, here kernel #199 with adapted nzbget still runs after two days. This evening i will stop it and do a trial with only the memmove and taking out the usleep(100)

[fvdw]

it crashed with usleep(100) taken out and keeping the memmove instead of memcpy
and again the same last lines in log file

Code: Select all

Wed Mar 26 00:33:35 2014   3061871712   DEBUG   Creating Thread (Thread.cpp:159:Thread)
Wed Mar 26 00:33:35 2014   3061871712   DEBUG   Starting Thread (Thread.cpp:182:Start)
Wed Mar 26 00:33:35 2014   3061871712   DEBUG   fvdw ok create thread (Thread.cpp:209:Start)
Wed Mar 26 00:33:35 2014   3061871712   DEBUG   Accepting connection (Connection.cpp:454:Accept)


so memcpy doesn't seem to be the problem also memmove fails (forgot to look in dmesg output to see if it now mentions memmove)

so seems we are dealing here with a timing option...no idea yet why here timing is an issue :scratch
this is the full code of the function involved

Code: Select all

char* Connection::ReadLine(char* pBuffer, int iSize, int* pBytesRead)
{
   if (m_eStatus != csConnected)
   {
      return NULL;
   }

   char* pBufPtr = pBuffer;
   iSize--; // for trailing '0'
   int iBytesRead = 0;
   int iBufAvail = m_iBufAvail; // local variable is faster
   char* szBufPtr = m_szBufPtr; // local variable is faster
   while (iSize)
   {
      if (!iBufAvail)
      {
         iBufAvail = recv(m_iSocket, m_szReadBuf, CONNECTION_READBUFFER_SIZE, 0);
         if (iBufAvail < 0)
         {
            ReportError("Could not receive data on socket", NULL, true, 0);
            break;
         }
         else if (iBufAvail == 0)
         {
            break;
         }
         szBufPtr = m_szReadBuf;
         m_szReadBuf[iBufAvail] = '\0';
      }
      
      int len = 0;
      char* p = (char*)memchr(szBufPtr, '\n', iBufAvail);
      if (p)
      {
         len = (int)(p - szBufPtr + 1);
      }
      else
      {
         len = iBufAvail;
      }
      
      if (len > iSize)
      {
         len = iSize;
      }
//      debug("fvdw readline 2");
              usleep(100);
              memmove(pBufPtr, szBufPtr, len);
//      debug("fvdw realine 4");
      pBufPtr += len;
      szBufPtr += len;
      iBufAvail -= len;
      iBytesRead += len;
      iSize -= len;
      
      if (p)
      {
         break;
      }
   }
   *pBufPtr = '\0';
   
   m_iBufAvail = iBufAvail > 0 ? iBufAvail : 0; // copy back to member
   m_szBufPtr = szBufPtr; // copy back to member
   
   if (pBytesRead)
   {
      *pBytesRead = iBytesRead;
   }
   
   if (pBufPtr == pBuffer)
   {
      return NULL;
   }
   
   return pBuffer;
}

next: a trial with memcpy restored and again putting in usleep(100)

[brinka123]

No memory allocation problems seen?
The memcpy/memmve uses a pointer created by malloc...

[fvdw]

No memory allocation problems seen?
The memcpy/memmve uses a pointer created by malloc...

nope..no trace in the log of the message added in the code for malloc failure

[brinka123]

Still believe it has to do with malloc:

See http://linux.die.net/man/3/malloc

Specially the following sentence:

Code: Select all

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer. For more information, see the description of /proc/sys/vm/overcommit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file Documentation/vm/overcommit-accounting.

The out of memory can be a temporary, very short moment. Due to delays, problems don't have to occur.

Read also this regarding over commit:
http://www.etalabs.net/overcommit.html

To set the overcommit policy:
https://pracops.com/wiki/index.php/Memory_overcommit_(Linux)

Maybe try a test with original 15-1 setup and set "don't over commit"?

[fvdw]

he out of memory can be a temporary, very short moment. Due to delays, problems don't have to occur.

agree it shouldn't occur,

the nzbeget version with only the usleep runs ok since 24 hours now.