Re: [naviserver-devel] ns_proxy hang

[David O. <da...@qc...>]

Thanks.

This does indeed seem to fix the test case I sent - however I'm now getting
a segmentation fault during the "make test".

It's during the second ns_proxy 5.10 test (there are two 5.10s) - "test
ns_proxy-5.10 {check killing active proxy}".

ns_close is being called on an invalid SlavePtr during ns_proxy cleanup.
Is this something platform specific?

[15/May/2017:13:56:37][1717.7ffff543a700][-command-] Notice: 5.10
[15/May/2017:13:56:38][1717.7fffc99dc700][-nsproxy:reap-] Warning: nsproxy:
zombie: 1782
[15/May/2017:13:56:38][1717.7fffc99dc700][-nsproxy:reap-] Warning:
[testpool]: pid 1785 won't die, send signal 9
[15/May/2017:13:56:38][1717.7ffff543a700][-command-] Notice: releasing busy
proxy testpool-8

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff543a700 (LWP 1722)]
0x00007fffeebe8ba8 in ReleaseProxy (interp=interp@entry=0x7ffff000cf80,
proxyPtr=0x7ffff0456c60) at nsproxylib.c:3261
3261            ns_close(proxyPtr->slavePtr->rfd);
(gdb) print proxyPtr
$1 = (Proxy *) 0x7ffff0456c60
(gdb) print proxyPtr->slavePtr
$2 = (Slave *) 0x0
(gdb) print *proxyPtr->slavePtr
Cannot access memory at address 0x0
(gdb) list
3256                result = Eval(interp, proxyPtr, Tcl_DStringValue(&ds),
-1);
3257            }
3258            Tcl_DStringFree(&ds);
3259        } else if (proxyPtr->state == Busy) {
3260            Ns_Log(Notice, "releasing busy proxy %s", proxyPtr->id);
3261            ns_close(proxyPtr->slavePtr->rfd);
3262            proxyPtr->slavePtr->rfd = NS_INVALID_FD;
3263        }
3264        if (proxyPtr->cmdToken != NULL) {
3265            /*
(gdb) bt
#0  0x00007fffeebe8ba8 in ReleaseProxy (interp=interp@entry=0x7ffff000cf80,
proxyPtr=0x7ffff0456c60) at nsproxylib.c:3261
#1  0x00007fffeebe8d5c in ReleaseHandles (interp=0x7ffff000cf80,
idataPtr=<optimized out>) at nsproxylib.c:3381
#2  0x00007fffeebe6876 in ProxyObjCmd (data=0x7ffff0024ab0,
interp=0x7ffff000cf80, objc=2, objv=0x7ffff001bcd8)
    at nsproxylib.c:1668
#3  0x00007ffff71bae59 in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so
#4  0x00007ffff720195e in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so
#5  0x00007ffff7200897 in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so
#6  0x00007ffff71bc6e6 in TclEvalObjEx () from /usr/lib/x86_64-linux-gnu/
libtcl8.5.so
#7  0x00007ffff724442f in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so




On 13 May 2017 at 19:53, Gustaf Neumann <ne...@wu...> wrote:

> Hi David,
>
> i've committed a version to bitbucket, that should address the problem.
> Here is what's seems to happen:
> a) in your example, you are sending exec commands with huge output and a
> eval-timeout  of 1ms
> b) NaviServer stops it side the eval more or less immediately (after one
> ms)
> c) the slave still tries to send the data, but runs into a blocking
> write operation
> d) the slave does react in this state by "normal" interactions, causing
> the hang.
>
> After my change, NaviServer closes in ReleaseProxy() its end manually,
> in case the slave is busy.
> -g
> PS: it is clear, that we do not see in our production environment this
> problem, since we are not using an eval timeout.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>