Not sure if this helps you - it may be entirely expected behaviour, but I
attached gbp to the nsproxy process and got a backtrace from the 2 test
cases I mentioned, immediately after the "ns_proxy eval...".
In the case with no hang the nsproxy process is waiting in RecvBuf:
#0 0x00007ffff6593250 in __libc_readv (fd=6,
vector=vector@entry=0x7fffffffe8a0,
count=count@entry=2)
at ../sysdeps/unix/sysv/linux/readv.c:54
#1 0x00007ffff7bd717f in RecvBuf (slavePtr=0x7fffffffe930, ms=-1,
dsPtr=0x7fffffffe970) at nsproxylib.c:1319
#2 0x00007ffff7bd6391 in Ns_ProxyMain (argc=47, argv=0x7fffffffea50,
init=0x7fffffffe970) at nsproxylib.c:578
#3 0x00007ffff64d3b45 in __libc_start_main (main=0x400730 <main>, argc=4,
argv=0x7fffffffec48, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffec38) at libc-start.c:287
#4 0x0000000000400765 in _start ()
The case which hangs, the nsproxy process is still waiting in SendBuf after
the "ns_proxy eval..." ends:
#0 0x00007ffff65932f0 in __libc_writev (fd=7,
vector=vector@entry=0x7fffffffe8b0,
count=count@entry=2)
at ../sysdeps/unix/sysv/linux/writev.c:54
#1 0x00007ffff7bd6fcc in SendBuf (slavePtr=0x7fffffffe930, ms=-1,
dsPtr=<optimized out>) at nsproxylib.c:1245
#2 0x00007ffff7bd6365 in Ns_ProxyMain (argc=47, argv=0x7fffffffea50,
init=0x7fffffffe970) at nsproxylib.c:613
#3 0x00007ffff64d3b45 in __libc_start_main (main=0x400730 <main>, argc=4,
argv=0x7fffffffec48, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffec38) at libc-start.c:287
#4 0x0000000000400765 in _start ()
On 10 May 2017 at 15:27, Gustaf Neumann <neum...@wu.ac.at> wrote:
> I'll look at it at the weekend - unless someone else can fix this before
> this.
>
> -g
> Am 10.05.17 um 16:00 schrieb David Osborne:
>
> Increasing waittimeout doesn't seem to have any effect on this problem.
>
> I have backtraces of all threads at the point of the hang here:
> https://gist.github.com/davidqc/ebee38528b0a40a0b8d028981ad933e6
>
> Thread 19 I think is the culprit:
>
> Thread 19 (Thread 0x7fffaaffd700 (LWP 17652)):
> #0 0x00007ffff6322b89 in __libc_waitpid (pid=pid@entry=17651,
> stat_loc=stat_loc@entry=0x7fffaaffcde4, options=options@entry=0)
> at ../sysdeps/unix/sysv/linux/waitpid.c:40
> #1 0x00007ffff7b5aa4c in Ns_WaitForProcess (pid=17651, exitcodePtr=0x0) at
> exec.c:178
> #2 0x00007ffff1b68615 in ReaperThread (UNUSED_arg=0x44f3) at
> nsproxylib.c:2935
> #3 0x00007ffff74b886d in NsThreadMain (arg=<optimized out>) at thread.c:232
> #4 0x00007ffff74b98a9 in ThreadMain (arg=<optimized out>) at pthread.c:830
> #5 0x00007ffff5e500a4 in start_thread (arg=0x7fffaaffd700) at
> pthread_create.c:309
> #6 0x00007ffff635162d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
>
------------------------------------------------------------------------------
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
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
