We're using the default connsperthread which appears to be 10,000
I don't see the thread listed in "info threads" but it's 0x7f58517dd700. Is
there a better way to get info on it?
(gdb) frame 7
#7 0x00007f5859ef0ffc in JoinConnThread (threadPtr=0x7f585181dda0) at
queue.c:1688
1688 Ns_ThreadJoin(threadPtr, &argArg);
(gdb) list
1683 {
1684 void *argArg;
1685
1686 assert(threadPtr != NULL);
1687
1688 Ns_ThreadJoin(threadPtr, &argArg);
1689 /*
1690 * There is no need to free ConnThreadArg here, since it is
1691 * allocated in the driver
1692 */
(gdb) print *threadPtr
$6 = (Ns_Thread) 0x7f58517dd700
(gdb) info threads
Id Target Id Frame
25 Thread 0x7f5851698700 (LWP 26443) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
24 Thread 0x7f5851cae700 (LWP 26453) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
23 Thread 0x7f5851d30700 (LWP 26450) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
22 Thread 0x7f5851616700 (LWP 26445) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
21 Thread 0x7f585185f700 (LWP 26455) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
20 Thread 0x7f58569a3700 (LWP 25531) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
19 Thread 0x7f5851baa700 (LWP 25582) 0x00007f58588f2344 in
pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
18 Thread 0x7f585179c700 (LWP 1123) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
17 Thread 0x7f5851b69700 (LWP 25629) 0x00007f58588f2344 in
pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
16 Thread 0x7f5851aa6700 (LWP 25648) 0x00007f5858dd8ac3 in poll () from
/lib/x86_64-linux-gnu/libc.so.6
15 LWP 11460 0x00007f58595fd768 in ?? () from
/usr/lib/libtcl8.5.so.0
14 Thread 0x7f5851ae7700 (LWP 25640) 0x00007f58588f2344 in
pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
13 Thread 0x7f5853374700 (LWP 25532) 0x00007f5858dd8ac3 in poll () from
/lib/x86_64-linux-gnu/libc.so.6
12 Thread 0x7f5851b28700 (LWP 25630) 0x00007f58588f2344 in
pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
11 Thread 0x7f5851beb700 (LWP 25571) 0x00007f5858dd8ac3 in poll () from
/lib/x86_64-linux-gnu/libc.so.6
10 Thread 0x7f5851d71700 (LWP 25555) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
9 Thread 0x7f5851c6d700 (LWP 11229) 0x00007f5858dd8ac3 in poll () from
/lib/x86_64-linux-gnu/libc.so.6
8 Thread 0x7f58586da700 (LWP 25528) 0x00007f5858ddd203 in select ()
from /lib/x86_64-linux-gnu/libc.so.6
7 Thread 0x7f5851657700 (LWP 26452) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
6 Thread 0x7f585a363700 (LWP 25524) 0x00007f5858d39597 in ?? () from
/lib/x86_64-linux-gnu/libc.so.6
5 Thread 0x7f5851cef700 (LWP 16374) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
4 Thread 0x7f585171a700 (LWP 26448) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
3 Thread 0x7f585175b700 (LWP 26441) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
2 Thread 0x7f58516d9700 (LWP 16376) 0x00007f58588f26bb in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
* 1 Thread 0x7f585181e700 (LWP 11461) 0x00007f5858d39165 in raise ()
from /lib/x86_64-linux-gnu/libc.so.6
On 26 March 2015 at 12:38, Gustaf Neumann <neum...@wu.ac.at> wrote:
> Am 26.03.15 um 13:11 schrieb David Osborne:
>
> Hi Gustaf,
>
> The crashes we are seeing are not during shutdown, but during normal
> server operation which is why we are concerned about them. The system
> recovers quickly due to daemontools, but the scheduled tasks running at the
> time of the crash are aborted.
>
> can you check, what thread was shutting down (in your backtrace:
> 0x7f585181dda0)
> what value for connsperthread are you using?
>
>
> There is nothing in the syslog to indicate a memory problem or oom
> killer being invoked.
>
> As for a Tcl bug, we might potentially be able to upgrade the version of
> Tcl use to 8.5.17 from the Debian testing distribution (currently we use
> 8.5.11). But I wouldn't like to do that on the production system unless
> there was very good reason.
>
> there is no change regarding to this problem in the Tcl 8.5.* family
>
>
> Do you know more about the Tcl bug that caused your last crash?
>
> I have to dig this out. The problem was with the memory management of
> tcl-objs,
> where appending to a tcl-obj could lead to overshoot the capabilities of
> the length field.
> This was fixed in tcl 8.6 and tcl 8.5 (at least 8.5.15). If you were hit
> by this
> bug, the backtrace would look very differently.
>
> -g
>
>
>
>
> On 26 March 2015 at 11:18, Gustaf Neumann <neum...@wu.ac.at> wrote:
>
>> Hi David,
>>
>> We have this issue of shutdown in test-cases and during server shutdown
>> since
>> several years. It is annoying, but mostly harmless. The last time i
>> looked into
>> the problem, i got the impression that it depends on a not fully
>> predictable
>> shutdown order, which is not completely in our hands due to tcl
>> interactions.
>>
>> i would be alert, if you see this problem in other situations. For our
>> production
>> system, i saw the last crash months ago (happend due to a Tcl-bug with
>> doubling the size of a dstring over 2gb). Another "crash" on a different
>> system
>> turned out to be due to linux's oom killer.
>>
>> -g
>>
>
>
> --
> Univ.Prof. Dr. Gustaf Neumann
> WU Vienna
> Institute of Information Systems and New Media
> Welthandelsplatz 1, A-1020 Vienna, Austria
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
--
David Osborne
Qcode Software Limited
http://www.qcode.co.uk
T: +44 (0)1463 896484
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
