Admin console not accessable after 15-1 update

[fvdw]

if you know how to make the code more robust we can change it and try, compiling is easy...

[brinka123]

I set up a toolchain for the android kernel for HTC mobile phone before, I found it not easy, had to learn with GIT too, but it worked. When you can help set up a toolchain for nzb for compilation, and the location where you get the code from, I can try. PM an explanation??
Do you compile on umbuntu?
First what I would do set some detection prints in it. To see were it goes wrong.

[fvdw]

I compile directly on the nas and have set up the compiler myself. Indeed it is not so to set it up and get a working one.
Adding print statements is a way to find the place but because it is not crashing very fast it can be come a time consuming issue
Also you need to know what could be wrong in the code. Analyzing all malloc calls in combination with recv could be an approach as well

ps I will once more recompile nzbget, I saw some warnings during earlier compile, maybe those give a hint on what could be the problem

[fvdw]

in compiling nzbget 12-0 1 warning was given

Code: Select all

UrlCoordinator.cpp: In member function 'virtual void UrlDownloader::ProcessHeader(const char*)':
UrlCoordinator.cpp:89:13: warning: converting to non-pointer type 'char' from NULL [-Wconversion-null]
    *szValue = NULL;
             ^

I repaired that and stated this nzbget version with kernel 199 with heavy samba load in parallel, it crashed after a few minutes with the oops 805 error
so this is not he problem

the last message in the log was "starting thread" in Thread.cpp:182:Startroutine it failed
here the code from that part, there is something critical with it

Code: Select all

void Thread::Start()
{
   debug("Starting Thread");

   m_bRunning = true;
   
   // NOTE: we must guarantee, that in a time we set m_bRunning
   // to value returned from pthread_create, the thread-object still exists.
   // This is not obviously!
   // pthread_create could wait long enough before returning result
   // back to allow the started thread to complete its job and terminate.
   // We lock mutex m_pMutexThread on calling pthread_create; the started thread
   // then also try to lock the mutex (see thread_handler) and therefore
   // must wait until we unlock it
   m_pMutexThread->Lock();

#ifdef WIN32
   m_pThreadObj = (HANDLE)_beginthread(Thread::thread_handler, 0, (void *)this);
   m_bRunning = m_pThreadObj != NULL;
#else
   pthread_attr_t m_Attr;
   pthread_attr_init(&m_Attr);
   pthread_attr_setdetachstate(&m_Attr, PTHREAD_CREATE_DETACHED);
   pthread_attr_setinheritsched(&m_Attr , PTHREAD_INHERIT_SCHED);
   m_bRunning = !pthread_create((pthread_t*)m_pThreadObj, &m_Attr, Thread::thread_handler, (void *) this);
   pthread_attr_destroy(&m_Attr);
#endif

   m_pMutexThread->Unlock();
}


it seems that nas is not really crashed, samba is keeping working only some functions seems not to work anymore...waiting for something ??

[fvdw]

something keep nzbget hanging after oops error it is still in ram but it cannot be killed

Code: Select all

root@nwsp2-5:/ # busybox pstree -p
init(1)-+-autoswitchusbd(1241)
        |-buttonsd(592)
        |-discoverd(1105)
        |-dropbear(1129)-+-dropbear(1505)---sh(1508)
        |                |-dropbear(1542)---sh(1545)---top(2393)
        |                `-dropbear(4554)---sh(4557)---busybox(4716)
        |-hostd(1193)
        |-httpd(1053)-+-httpd(1054)
        |             `-httpd(1055)
        |-killall(4442)
        |-nmbd(1065)
        |-noflushd(1062)
        |-ntpd(1226)
        |-nzbget(1564)-+-{nzbget}(1568)
        |              |-{nzbget}(1569)
        |              |-{nzbget}(1570)
        |              |-{nzbget}(1571)
        |              |-{nzbget}(1572)
        |              |-{nzbget}(3427)
        |              |-{nzbget}(3428)
        |              |-{nzbget}(3435)
        |              `-{nzbget}(3438)
        |-pptpd(1190)
        |-ps(3480)
        |-ps(4157)
        |-ps(4384)
        |-ps(4417)
        |-ps(4531)
        |-rpc.mountd(1153)
        |-rpc.statd(1155)
        |-rpcbind(1113)
        |-sh(1283)
        |-smbd(1068)-+-smbd(1069)
        |            `-smbd(1444)
        |-syncawayd(1102)
        |-temp-guard(1214)
        |-udevd(770)
        `-udhcpc(1024)
root@nwsp2-5:/ #

[fvdw]

it always seems to crash at this point (last entries in log file when oops error code is 805)

Code: Select all

Fri Mar 21 23:20:39 2014   3008361568   DEBUG   Do disconnecting (Connection.cpp:636:DoDisconnect)
Fri Mar 21 23:20:39 2014   3008361568   DEBUG   Destroying Connection (Connection.cpp:163:~Connection)
Fri Mar 21 23:20:39 2014   3008361568   DEBUG   Disconnecting (Connection.cpp:217:Disconnect)
Fri Mar 21 23:20:39 2014   3008361568   DEBUG   Destroying Thread (Thread.cpp:174:~Thread)
Fri Mar 21 23:20:39 2014   3062211680   DEBUG   Creating Connection (Connection.cpp:143:Connection)
Fri Mar 21 23:20:39 2014   3062211680   DEBUG   Creating Thread (Thread.cpp:159:Thread)
Fri Mar 21 23:20:39 2014   3062211680   DEBUG   Starting Thread (Thread.cpp:182:Start)
Fri Mar 21 23:20:39 2014   3062211680   DEBUG   fvdw ok create thread (Thread.cpp:209:Start)
Fri Mar 21 23:20:39 2014   3062211680   DEBUG   Accepting connection (Connection.cpp:452:Accept)

crash

when no crash the output continues like this

Code: Select all

Fri Mar 21 23:15:55 2014   3062211680   DEBUG   Creating Thread (Thread.cpp:159:Thread)
Fri Mar 21 23:15:55 2014   3062211680   DEBUG   Starting Thread (Thread.cpp:182:Start)
Fri Mar 21 23:15:55 2014   3062211680   DEBUG   fvdw ok create thread (Thread.cpp:209:Start)
Fri Mar 21 23:15:55 2014   3062211680   DEBUG   Accepting connection (Connection.cpp:452:Accept)
Fri Mar 21 23:15:55 2014   2966418528   DEBUG   Entering Thread-func (Thread.cpp:254:thread_handler)
Fri Mar 21 23:15:55 2014   2966418528   DEBUG   Receiving data (full buffer) (Connection.cpp:492:Recv)

This smells again that the recv kernel function is causing the issue

[brinka123]

What I understand from the comment is that the thread sets a lock, but can't yet until the calling function does the unlock.

Maybe the unlock isn't reached by a certain reason...

Where do you retreive the code from, I need the right source which you use. Maybe I can help finding it...


Kernel #166 is running a day already...

[fvdw]

if I compare kernel 3.13.6 with 3..9.5 then the changes described here http://cxsecurity.com/issue/WLB-2014010055

inet: prevent leakage of uninitialized memory to user in recv syscalls
Only update *addr_len when we actually fill in sockaddr, otherwise we
can return uninitialized memory from the stack to the caller in the
recvfrom, recvmmsg and recvmsg syscalls. Drop the the (addr_len == NULL)
checks because we only get called with a valid addr_len pointer either
from sock_common_recvmsg or inet_recvmsg.

as I understand this this might cause an oops error

The changes described here seem to be present in the 3.13.6 kernel but not in the 3.9.5 kernel
Thats logical because the changes describe there are 3.12.6 just copying those to 3.9.5 is not straight forward. :scratch

[fvdw]

this is the source code from nzbget

[fvdw]

I downloaded it from here: http://nzbget.net/download