Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jeff R. <dv...@di...> - 2015-04-09 21:43:11
|
Hi all, I finally got around to checking in this change that I've had sitting around for some time. It adds a configuration parameter "compresspreinit" to control if the server allocates and initializes zlib buffers at startup time or the first time they are needed. I put this in initially because I was having trouble starting a test server on a somewhat memory-starved machine, and the previous behavior allocated a buffer for each connection in maxconns (which defaults to 100), even if those buffers are never used. Gustaf already did the other half of the change, to initialize the buffers when they are needed if they were not initialized already (in changeset 8c76e6855c84, 2 years ago), I've just had this part of it sitting around since then. Cheers, -J |
|
From: Gustaf N. <ne...@wu...> - 2015-04-06 15:15:32
|
Dear Friends of NaviServer,
The release of NaviServer 4.99.7 attracted many people to
NaviServer, who found some bugs (some old, some new), serious
enough for a bug-fix release.
Below is the preliminary summary of the changes since the release
of 4.99.7. I've placed the release candidates to
sourceforge as 4.99.8a.
The plan is to release this version on the forthcoming weekend,
if nothing comes up.
all the best
-gustaf neumann
======================================
NaviServer 4.99.8, released 2015-04-XX
======================================
Changes relative to 4.99.7
37 files changed, 672 insertions(+), 377 deletions(-)
New Features:
* ns_md5, ns_sha1: added binary support
When data passed to function, use Tcl byte-array operations instead
of string operations
Bug Fixes:
* Fixed bug reported by Wolfgang Winkler, when " ns_urldecode --" was
called (switched to regular argv parser)
* Fixed bug, when "ns_conn content" was called without content
potential race conditions on thread exits
* Fixed potential race conditions on thread exits
* ns_md5: md5-Code generation was broken
(probably since a long time, due to a mix up of somewhat tricky casts)
* Fixed warning in interaction between TCP_CORK and nsssl
* Fixed bug, where one thread frees a nsv-array, but an internal
representation of an Tcl_Obj for this array was still active in
another thread
* Fixed a bug with in https client commands (ns_ssl) when paths and parameters
are passed.
* Fixed nsphp compilation (and "make php").
Many thanks to Branden Graves for feedback and testing.
Configuration Changes:
* Improved sample configuration for OpenACS and nsssl
* Improved Makefiles (reduce redundancy for CFLAGS)
* Improved rpath handling in configure.ac for Linux distros,
where TCL_CC_SEARCH_FLAGS and TCL_LD_SEARCH_FLAGS are set
empty, like e.g.Debian
Command Line Changes:
Code Changes:
* Extended Regression Test:
- Added test set for ns_md5, compared results with other implementations
- Added binary regression test for ns_md5 and ns_sha1
- Added test set for ns_md5
- Improved robustness of tests for ns_parseargs
- Added tests for "ns_urldecode --"
- Added test set infrastrucure (nstest::https, server setup) and
test cases for nsssl
* Reduced implicit type conversions and other minor code cleanups
* Protect against potential buffer overruns
|
|
From: David O. <da...@qc...> - 2015-03-26 13:07:15
|
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 <ne...@wu...> 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 <ne...@wu...> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
--
David Osborne
Qcode Software Limited
http://www.qcode.co.uk
T: +44 (0)1463 896484
|
|
From: Gustaf N. <ne...@wu...> - 2015-03-26 12:39:01
|
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 <ne...@wu... > <mailto:ne...@wu...>> 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 |
|
From: David O. <da...@qc...> - 2015-03-26 12:11:48
|
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. 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. Do you know more about the Tcl bug that caused your last crash? On 26 March 2015 at 11:18, Gustaf Neumann <ne...@wu...> 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 > > |
|
From: Gustaf N. <ne...@wu...> - 2015-03-26 11:18:51
|
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
Am 26.03.15 um 11:42 schrieb David Osborne:
> Hi again,
>
> We've been getting an intermittent server crash on our live system for
> a while now which hits us every weeks or so.
>
> The nsd daemon crashes with the above error and daemontools restarts it.
> Having done a search I believe this is seen sometimes on server
> shutdown where it's pretty harmless... but in these cases the server
> is not (expectedly) shutting down.
>
> We've now managed to get a core dump of the most recent occurrence.
> Is anyone able to give us any pointers on how we can try to narrow
> this down?
>
> It's Naviserver 4.99.7 (but was also happening in 4.99.6 - and I think
> 4.99.5) on Debian 7.7 (Wheezy) and Tcl 8.5.11-2
>
>
> [-conn:tlc_erp:20-] Fatal: nsthreads: pthread_join failed in
> Ns_ThreadJoin: Invalid argument
>
> (gdb) bt
> #0 0x00007f5858d39165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x00007f5858d3c3e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2 0x00007f5859ee9639 in Panic (fmt=<optimized out>) at log.c:707
> #3 0x00007f58595d6e12 in Tcl_PanicVA () from /usr/lib/libtcl8.5.so.0
> #4 0x00007f58595d6f8c in Tcl_Panic () from /usr/lib/libtcl8.5.so.0
> #5 0x00007f585984e6f0 in NsThreadFatal (func=<optimized out>,
> osfunc=<optimized out>, err=<optimized out>) at error.c:62
> #6 0x00007f5859850561 in Ns_ThreadJoin (thread=<optimized out>,
> argPtr=<optimized out>) at pthread.c:459
> #7 0x00007f5859ef0ffc in JoinConnThread (threadPtr=0x7f585181dda0) at
> queue.c:1688
> #8 NsConnThread (arg=0x2db7d70) at queue.c:1368
> #9 0x00007f585984f8ac in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> #10 0x00007f5859850899 in ThreadMain (arg=<optimized out>) at
> pthread.c:809
> #11 0x00007f58588edb50 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #12 0x00007f5858de370d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> #13 0x0000000000000000 in ?? ()
>
> (gdb) frame 8
> #8 NsConnThread (arg=0x2db7d70) at queue.c:1368
> 1368 JoinConnThread(&joinThread);
> (gdb) list
> 1363 }
> 1364
> 1365 joinThread = servPtr->pools.joinThread;
> 1366 Ns_ThreadSelf(&servPtr->pools.joinThread);
> 1367 if (joinThread != NULL) {
> 1368 JoinConnThread(&joinThread);
> 1369 }
> 1370
> 1371 Ns_Log(Notice, "exiting: %s", exitMsg);
> 1372
> (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) frame 6
> #6 0x00007f5859850561 in Ns_ThreadJoin (thread=<optimized out>,
> argPtr=<optimized out>) at pthread.c:459
> 459 NsThreadFatal("Ns_ThreadJoin", "pthread_join", err);
> (gdb) list
> 454
> 455 assert(thread != NULL);
> 456
> 457 err = pthread_join(thr, argPtr);
> 458 if (err != 0) {
> 459 NsThreadFatal("Ns_ThreadJoin", "pthread_join", err);
> 460 }
> 461 }
> 462
> 463 ^L
>
>
>
>
> Regards,
>
> --
> David Osborne
> Qcode Software Limited
> http://www.qcode.co.uk
>
>
>
> ------------------------------------------------------------------------------
> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria
|
|
From: David O. <da...@qc...> - 2015-03-26 10:42:12
|
Hi again,
We've been getting an intermittent server crash on our live system for a
while now which hits us every weeks or so.
The nsd daemon crashes with the above error and daemontools restarts it.
Having done a search I believe this is seen sometimes on server shutdown
where it's pretty harmless... but in these cases the server is not
(expectedly) shutting down.
We've now managed to get a core dump of the most recent occurrence.
Is anyone able to give us any pointers on how we can try to narrow this
down?
It's Naviserver 4.99.7 (but was also happening in 4.99.6 - and I think
4.99.5) on Debian 7.7 (Wheezy) and Tcl 8.5.11-2
[-conn:tlc_erp:20-] Fatal: nsthreads: pthread_join failed in Ns_ThreadJoin:
Invalid argument
(gdb) bt
#0 0x00007f5858d39165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f5858d3c3e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f5859ee9639 in Panic (fmt=<optimized out>) at log.c:707
#3 0x00007f58595d6e12 in Tcl_PanicVA () from /usr/lib/libtcl8.5.so.0
#4 0x00007f58595d6f8c in Tcl_Panic () from /usr/lib/libtcl8.5.so.0
#5 0x00007f585984e6f0 in NsThreadFatal (func=<optimized out>,
osfunc=<optimized out>, err=<optimized out>) at error.c:62
#6 0x00007f5859850561 in Ns_ThreadJoin (thread=<optimized out>,
argPtr=<optimized out>) at pthread.c:459
#7 0x00007f5859ef0ffc in JoinConnThread (threadPtr=0x7f585181dda0) at
queue.c:1688
#8 NsConnThread (arg=0x2db7d70) at queue.c:1368
#9 0x00007f585984f8ac in NsThreadMain (arg=<optimized out>) at thread.c:227
#10 0x00007f5859850899 in ThreadMain (arg=<optimized out>) at pthread.c:809
#11 0x00007f58588edb50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#12 0x00007f5858de370d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#13 0x0000000000000000 in ?? ()
(gdb) frame 8
#8 NsConnThread (arg=0x2db7d70) at queue.c:1368
1368 JoinConnThread(&joinThread);
(gdb) list
1363 }
1364
1365 joinThread = servPtr->pools.joinThread;
1366 Ns_ThreadSelf(&servPtr->pools.joinThread);
1367 if (joinThread != NULL) {
1368 JoinConnThread(&joinThread);
1369 }
1370
1371 Ns_Log(Notice, "exiting: %s", exitMsg);
1372
(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) frame 6
#6 0x00007f5859850561 in Ns_ThreadJoin (thread=<optimized out>,
argPtr=<optimized out>) at pthread.c:459
459 NsThreadFatal("Ns_ThreadJoin", "pthread_join", err);
(gdb) list
454
455 assert(thread != NULL);
456
457 err = pthread_join(thr, argPtr);
458 if (err != 0) {
459 NsThreadFatal("Ns_ThreadJoin", "pthread_join", err);
460 }
461 }
462
463 ^L
Regards,
--
David Osborne
Qcode Software Limited
http://www.qcode.co.uk
|
|
From: Gustaf N. <ne...@wu...> - 2015-03-26 10:26:08
|
Dear Ian, No, this is not a known problem. I assume, you have updated naviserver AND the modules. Do you have a test case where this behavior can be reproduced? We were running OpenACS.org for a while with dbipg without this problem. But, what we noticed was the following: - ndbipg needed a larger cachesize for prepared statements. Otherwise, one runs quickly into cache trashing, where for a full cache each sql query requires cache eviction, which can bring the system to a crawl, when SQL queries are high. (cachesize 1024*1024). - nsdbipg works nicely, when all constants are replaced by bind variables. When the query contains constants (e.g. acs object ids in OpenACS), then the same query is kept multiple times with different constants in the prepared-statements cache requiring more and more cache. - We all agree that it is the best not to have such SQL queries with constants, but when a complex framework is used, rewriting all queries can be substantial work (OpenACS with DotLRN contains about 1000 tables and views). Furthermore, when there are subquery expressions based on "in" (like "... item_id in (1, 99, 703)") with expressions of different lengths, then current bind variables run into a limit (one would still need with the current approach different sequences for every potential length). After having addressed most of problems in the packages used on openacs.org, that last problem caused us for the time being to switch back to nsdbpg on openacs.org. Can it be that you ran into the problem with the cache trashing? It might be worth the try to increase the cachesize.... -g Am 25.03.15 um 15:04 schrieb Ian Harding: > Hello! > > I just upgraded to the latest and greatest naviserver and am having > some issues. > > All my db connections eventually get tied up with > > deallocate dbipg_6832018 > > type of queries that appear to be stuck. I haven't done any research > into this yet, but was wondering if this is a known bug. > > If not I will get the version information and whatever else I can find > about locks, etc. Any other things I should look at let me know. > > Ian > > > ------------------------------------------------------------------------------ > 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Univ.Prof. Dr. Gustaf Neumann WU Vienna Institute of Information Systems and New Media Welthandelsplatz 1, A-1020 Vienna, Austria |
|
From: Ian H. <har...@gm...> - 2015-03-25 14:04:14
|
Hello! I just upgraded to the latest and greatest naviserver and am having some issues. All my db connections eventually get tied up with deallocate dbipg_6832018 type of queries that appear to be stuck. I haven't done any research into this yet, but was wondering if this is a known bug. If not I will get the version information and whatever else I can find about locks, etc. Any other things I should look at let me know. Ian |
|
From: David O. <da...@qc...> - 2015-03-12 09:42:47
|
Thanks again Gustaf. Yes, it definitely felt like it was more of an annoyance than a operational problem. We haven't rolled out the new version to any of our busy servers yet but in test it's looking pretty good now. Regards, -- David Osborne Qcode Software Limited http://www.qcode.co.uk On 11 March 2015 at 10:25, Gustaf Neumann <ne...@wu...> wrote: > Forgot to mention: the "error" was not a crash or incorrect result, but > a ns_log error message > complaining about an expected condition. The NaviServer was just > wondering, why it got > a request to uncork a socket, which as not corked. > > Nevertheless, something which has to be fixed. > -g > > Am 11.03.15 um 11:15 schrieb Gustaf Neumann: > > Hi David, > > yes, exactlty. It is strange that this did not show up earlier, but since > we use naviserver > on most sites with openacs, this was not an issue, since ns_return or > "ns_writer submitfile" > don't reach the nested corking cases as in fastpath + ssl. In sites > without ssl, this bug > does not show up at all. > > we should develop test cases for nsssl. > > Anyhow, we will do some more testing and we should publish a bugfix release > soon... if nothing more shows up, maybe this weekend. > > many thanks for your help! > > -g > > > > > ------------------------------------------------------------------------------ > 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > |
|
From: Gustaf N. <ne...@wu...> - 2015-03-11 10:25:17
|
Forgot to mention: the "error" was not a crash or incorrect result, but a ns_log error message complaining about an expected condition. The NaviServer was just wondering, why it got a request to uncork a socket, which as not corked. Nevertheless, something which has to be fixed. -g Am 11.03.15 um 11:15 schrieb Gustaf Neumann: > Hi David, > > yes, exactlty. It is strange that this did not show up earlier, but > since we use naviserver > on most sites with openacs, this was not an issue, since ns_return or > "ns_writer submitfile" > don't reach the nested corking cases as in fastpath + ssl. In sites > without ssl, this bug > does not show up at all. > > we should develop test cases for nsssl. > > Anyhow, we will do some more testing and we should publish a bugfix > release > soon... if nothing more shows up, maybe this weekend. > > many thanks for your help! > > -g > |
|
From: Gustaf N. <ne...@wu...> - 2015-03-11 10:15:45
|
Hi David,
yes, exactlty. It is strange that this did not show up earlier, but
since we use naviserver
on most sites with openacs, this was not an issue, since ns_return or
"ns_writer submitfile"
don't reach the nested corking cases as in fastpath + ssl. In sites
without ssl, this bug
does not show up at all.
we should develop test cases for nsssl.
Anyhow, we will do some more testing and we should publish a bugfix release
soon... if nothing more shows up, maybe this weekend.
many thanks for your help!
-g
Am 10.03.15 um 11:43 schrieb David Osborne:
> Could this be the problem? Sees to alleviate the symptoms for me
> certainly..
>
> diff -r 096278955dc1 nsd/sockfile.c
> --- a/nsd/sockfile.c Wed Mar 04 04:29:31 2015 +0100
> +++ b/nsd/sockfile.c Tue Mar 10 10:42:44 2015 +0000
> @@ -386,7 +386,7 @@
> int
> Ns_SockCork(Ns_Sock *sock, int cork)
> {
> - int success = 1;
> + int success = 0;
> #ifdef TCP_CORK
> Sock *sockPtr = (Sock *)sock;
>
>
>
> On 9 March 2015 at 16:24, David Osborne <da...@qc...
> <mailto:da...@qc...>> wrote:
>
> Hi again,
>
> We're getting some Error messages when we're browsing fastpath
> pages running tip via https.
> Not sure of this is anything to actually to worry about since
> there doesn't seem to be any side-effect except for the frequent
> error messages in the log.
>
> *[09/Mar/2015:15:59:06][17560.7fffedf37700][-conn:default:4-]
> Error: socket: trying to uncork an uncorked socket 10*
>
> It appears pretty much every time we click on a link.
>
> *
> *
> *Test case:
> *
>
> Building with the tip versions of naviserver and nsssl (but with
> the configure.ac <http://configure.ac> change to CCRFLAG/LDRFLAG
> we discussed)
>
> Add the following to the end of the default
> /usr/local/ns/conf/nsd-config.tcl:
>
> ns_section ns/server/default/module/nsssl
> ns_param certificate /usr/local/ns/modules/nsssl/server.pem
> ns_param address 0.0.0.0
> ns_param port 443
> ns_param ciphers
> "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!RC4
> "
> ns_param protocols "!SSLv2"
> ns_param verify 0
>
> ns_param extraheaders {
> Strict-Transport-Security "max-age=31536000; includeSubDomains"
> X-Frame-Options SAMEORIGIN
> X-Content-Type-Options nosniff
> }
>
> List nsssl.so in the module list
>
> ns_section "ns/server/default/modules"
> ns_param nscp nscp.so
> ns_param nssock nssock.so
> ns_param nslog nslog.so
> ns_param nscgi nscgi.so
> ns_param nsdb nsdb.so
> ns_param nsssl nsssl.so
>
> Do the following to generate a self-signed cert:
>
> openssl genrsa 1024 > host.key
> openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert
> cat host.cert host.key > server.pem
> rm -rf host.cert host.key
> openssl dhparam 2048 >> server.pem
>
>
>
> Run:
> /usr/local/ns/bin/nsd -c -u root -t /usr/local/ns/conf/nsd-config.tcl
>
> Browsing to https://servername/doc/index.html then clicking on one
> of the command names (eg. to take us
> https://servername/doc/naviserver/files/ns_adp_break.html) will
> cause the error.
>
>
> I tried to catch this in gdb by setting a breakpoint on Ns_Log
> with severity Error:
>
> ...
> [09/Mar/2015:15:49:37][17543.7fffef22d700][-sched-] Notice: sched:
> starting
> [Switching to Thread 0x7fffedf37700 (LWP 17554)]
>
> Breakpoint 3, Ns_Log (severity=severity@entry=2,
> fmt=fmt@entry=0x7ffff7bbabe0 "socket: trying to uncork an uncorked
> socket %d")
> at log.c:481
> 481 {
> (gdb) bt
> #0 Ns_Log (severity=severity@entry=2,
> fmt=fmt@entry=0x7ffff7bbabe0 "socket: trying to uncork an uncorked
> socket %d")
> at log.c:481
> #1 0x00007ffff7b91516 in Ns_SockCork
> (sock=sock@entry=0x7ffff001c9a0, cork=cork@entry=0) at sockfile.c:405
> #2 0x00007ffff7b9166a in SendFd (sock=sock@entry=0x7ffff001c9a0,
> fd=11, offset=10165, length=length@entry=10165,
> timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=flags@entry=0,
> sendProc=sendProc@entry=0x7fffee798b70 <Send>)
> at sockfile.c:481
> #3 0x00007ffff7b913e9 in NsSockSendFileBufsIndirect
> (sock=0x7ffff001c9a0, bufs=<optimized out>, nbufs=<optimized out>,
> timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=0,
> sendProc=0x7fffee798b70 <Send>) at sockfile.c:309
> #4 0x00007ffff7b75fc7 in NsDriverSendFile (sockPtr=<optimized
> out>, bufs=bufs@entry=0x7fffedf363a0, nbufs=nbufs@entry=1,
> flags=flags@entry=0) at driver.c:1133
> #5 0x00007ffff7b72ea9 in Ns_ConnSendFileVec
> (conn=conn@entry=0x66ecb0, bufs=bufs@entry=0x7fffedf363a0, nbufs=1)
> at connio.c:525
> #6 0x00007ffff7b8be86 in ReturnRange (conn=conn@entry=0x66ecb0,
> type=type@entry=0x627c90 "text/html", fd=fd@entry=11,
> data=data@entry=0x0, len=len@entry=10165) at return.c:988
> #7 0x00007ffff7b8bc64 in ReturnOpen (conn=conn@entry=0x66ecb0,
> status=status@entry=200, type=type@entry=0x627c90 "text/html",
> chan=chan@entry=0x0, fp=fp@entry=0x0, fd=fd@entry=11, len=10165)
> at return.c:881
> #8 0x00007ffff7b8bbe5 in Ns_ConnReturnOpenFd
> (conn=conn@entry=0x66ecb0, status=status@entry=200,
> type=type@entry=0x627c90 "text/html", fd=fd@entry=11,
> len=<optimized out>) at return.c:854
> #9 0x00007ffff7b7c7fd in FastReturn (conn=conn@entry=0x66ecb0,
> status=status@entry=200, type=0x627c90 "text/html",
> type@entry=0x0, file=0x7fffedf36b00
> "/usr/local/ns/pages/doc/naviserver/files/ns_adp_ctl.html") at
> fastpath.c:570
> #10 0x00007ffff7b7c4c3 in Ns_FastPathProc (UNUSED_arg=<optimized
> out>, conn=0x66ecb0) at fastpath.c:244
> #11 0x00007ffff7b85059 in Ns_ConnRunRequest
> (conn=conn@entry=0x66ecb0) at op.c:293
> #12 0x00007ffff7b89283 in ConnRun (connPtr=0x66ecb0,
> argPtr=0x16c6a70) at queue.c:1513
> #13 NsConnThread (arg=0x16c6a70) at queue.c:1229
> #14 0x00007ffff74ea77c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> #15 0x00007ffff74eb6c9 in ThreadMain (arg=<optimized out>) at
> pthread.c:809
> #16 0x00007ffff64ed0a4 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #17 0x00007ffff69ebccd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) frame 0
> #0 Ns_Log (severity=severity@entry=2,
> fmt=fmt@entry=0x7ffff7bbabe0 "socket: trying to uncork an uncorked
> socket %d")
> at log.c:481
> 481 {
> (gdb) frame 1
> #1 0x00007ffff7b91516 in Ns_SockCork
> (sock=sock@entry=0x7ffff001c9a0, cork=cork@entry=0) at sockfile.c:405
> 405 Ns_Log(Error, "socket: trying to uncork an uncorked socket %d",
> (gdb) print *sock
> $1 = {driver = 0x654c50, sock = 10, sa = {sin_family = 2, sin_port
> = 46046, sin_addr = {s_addr = 191146176},
> sin_zero = "\000\000\000\000\000\000\000"}, arg = 0x7ffff006f510}
>
|
|
From: Gustaf N. <ne...@wu...> - 2015-03-10 10:54:52
|
I'll look into this this evening.
-g
Am 10.03.15 um 11:43 schrieb David Osborne:
> Could this be the problem? Sees to alleviate the symptoms for me
> certainly..
>
> diff -r 096278955dc1 nsd/sockfile.c
> --- a/nsd/sockfile.c Wed Mar 04 04:29:31 2015 +0100
> +++ b/nsd/sockfile.c Tue Mar 10 10:42:44 2015 +0000
> @@ -386,7 +386,7 @@
> int
> Ns_SockCork(Ns_Sock *sock, int cork)
> {
> - int success = 1;
> + int success = 0;
> #ifdef TCP_CORK
> Sock *sockPtr = (Sock *)sock;
>
>
>
> On 9 March 2015 at 16:24, David Osborne <da...@qc...
> <mailto:da...@qc...>> wrote:
>
> Hi again,
>
> We're getting some Error messages when we're browsing fastpath
> pages running tip via https.
> Not sure of this is anything to actually to worry about since
> there doesn't seem to be any side-effect except for the frequent
> error messages in the log.
>
> *[09/Mar/2015:15:59:06][17560.7fffedf37700][-conn:default:4-]
> Error: socket: trying to uncork an uncorked socket 10*
>
> It appears pretty much every time we click on a link.
>
> *
> *
> *Test case:
> *
>
> Building with the tip versions of naviserver and nsssl (but with
> the configure.ac <http://configure.ac> change to CCRFLAG/LDRFLAG
> we discussed)
>
> Add the following to the end of the default
> /usr/local/ns/conf/nsd-config.tcl:
>
> ns_section ns/server/default/module/nsssl
> ns_param certificate /usr/local/ns/modules/nsssl/server.pem
> ns_param address 0.0.0.0
> ns_param port 443
> ns_param ciphers
> "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!RC4
> "
> ns_param protocols "!SSLv2"
> ns_param verify 0
>
> ns_param extraheaders {
> Strict-Transport-Security "max-age=31536000; includeSubDomains"
> X-Frame-Options SAMEORIGIN
> X-Content-Type-Options nosniff
> }
>
> List nsssl.so in the module list
>
> ns_section "ns/server/default/modules"
> ns_param nscp nscp.so
> ns_param nssock nssock.so
> ns_param nslog nslog.so
> ns_param nscgi nscgi.so
> ns_param nsdb nsdb.so
> ns_param nsssl nsssl.so
>
> Do the following to generate a self-signed cert:
>
> openssl genrsa 1024 > host.key
> openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert
> cat host.cert host.key > server.pem
> rm -rf host.cert host.key
> openssl dhparam 2048 >> server.pem
>
>
>
> Run:
> /usr/local/ns/bin/nsd -c -u root -t /usr/local/ns/conf/nsd-config.tcl
>
> Browsing to https://servername/doc/index.html then clicking on one
> of the command names (eg. to take us
> https://servername/doc/naviserver/files/ns_adp_break.html) will
> cause the error.
>
>
> I tried to catch this in gdb by setting a breakpoint on Ns_Log
> with severity Error:
>
> ...
> [09/Mar/2015:15:49:37][17543.7fffef22d700][-sched-] Notice: sched:
> starting
> [Switching to Thread 0x7fffedf37700 (LWP 17554)]
>
> Breakpoint 3, Ns_Log (severity=severity@entry=2,
> fmt=fmt@entry=0x7ffff7bbabe0 "socket: trying to uncork an uncorked
> socket %d")
> at log.c:481
> 481 {
> (gdb) bt
> #0 Ns_Log (severity=severity@entry=2,
> fmt=fmt@entry=0x7ffff7bbabe0 "socket: trying to uncork an uncorked
> socket %d")
> at log.c:481
> #1 0x00007ffff7b91516 in Ns_SockCork
> (sock=sock@entry=0x7ffff001c9a0, cork=cork@entry=0) at sockfile.c:405
> #2 0x00007ffff7b9166a in SendFd (sock=sock@entry=0x7ffff001c9a0,
> fd=11, offset=10165, length=length@entry=10165,
> timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=flags@entry=0,
> sendProc=sendProc@entry=0x7fffee798b70 <Send>)
> at sockfile.c:481
> #3 0x00007ffff7b913e9 in NsSockSendFileBufsIndirect
> (sock=0x7ffff001c9a0, bufs=<optimized out>, nbufs=<optimized out>,
> timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=0,
> sendProc=0x7fffee798b70 <Send>) at sockfile.c:309
> #4 0x00007ffff7b75fc7 in NsDriverSendFile (sockPtr=<optimized
> out>, bufs=bufs@entry=0x7fffedf363a0, nbufs=nbufs@entry=1,
> flags=flags@entry=0) at driver.c:1133
> #5 0x00007ffff7b72ea9 in Ns_ConnSendFileVec
> (conn=conn@entry=0x66ecb0, bufs=bufs@entry=0x7fffedf363a0, nbufs=1)
> at connio.c:525
> #6 0x00007ffff7b8be86 in ReturnRange (conn=conn@entry=0x66ecb0,
> type=type@entry=0x627c90 "text/html", fd=fd@entry=11,
> data=data@entry=0x0, len=len@entry=10165) at return.c:988
> #7 0x00007ffff7b8bc64 in ReturnOpen (conn=conn@entry=0x66ecb0,
> status=status@entry=200, type=type@entry=0x627c90 "text/html",
> chan=chan@entry=0x0, fp=fp@entry=0x0, fd=fd@entry=11, len=10165)
> at return.c:881
> #8 0x00007ffff7b8bbe5 in Ns_ConnReturnOpenFd
> (conn=conn@entry=0x66ecb0, status=status@entry=200,
> type=type@entry=0x627c90 "text/html", fd=fd@entry=11,
> len=<optimized out>) at return.c:854
> #9 0x00007ffff7b7c7fd in FastReturn (conn=conn@entry=0x66ecb0,
> status=status@entry=200, type=0x627c90 "text/html",
> type@entry=0x0, file=0x7fffedf36b00
> "/usr/local/ns/pages/doc/naviserver/files/ns_adp_ctl.html") at
> fastpath.c:570
> #10 0x00007ffff7b7c4c3 in Ns_FastPathProc (UNUSED_arg=<optimized
> out>, conn=0x66ecb0) at fastpath.c:244
> #11 0x00007ffff7b85059 in Ns_ConnRunRequest
> (conn=conn@entry=0x66ecb0) at op.c:293
> #12 0x00007ffff7b89283 in ConnRun (connPtr=0x66ecb0,
> argPtr=0x16c6a70) at queue.c:1513
> #13 NsConnThread (arg=0x16c6a70) at queue.c:1229
> #14 0x00007ffff74ea77c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> #15 0x00007ffff74eb6c9 in ThreadMain (arg=<optimized out>) at
> pthread.c:809
> #16 0x00007ffff64ed0a4 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #17 0x00007ffff69ebccd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) frame 0
> #0 Ns_Log (severity=severity@entry=2,
> fmt=fmt@entry=0x7ffff7bbabe0 "socket: trying to uncork an uncorked
> socket %d")
> at log.c:481
> 481 {
> (gdb) frame 1
> #1 0x00007ffff7b91516 in Ns_SockCork
> (sock=sock@entry=0x7ffff001c9a0, cork=cork@entry=0) at sockfile.c:405
> 405 Ns_Log(Error, "socket: trying to uncork an uncorked socket %d",
> (gdb) print *sock
> $1 = {driver = 0x654c50, sock = 10, sa = {sin_family = 2, sin_port
> = 46046, sin_addr = {s_addr = 191146176},
> sin_zero = "\000\000\000\000\000\000\000"}, arg = 0x7ffff006f510}
>
>
>
>
>
>
> --
> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria
|
|
From: David O. <da...@qc...> - 2015-03-10 10:44:04
|
Could this be the problem? Sees to alleviate the symptoms for me certainly..
diff -r 096278955dc1 nsd/sockfile.c
--- a/nsd/sockfile.c Wed Mar 04 04:29:31 2015 +0100
+++ b/nsd/sockfile.c Tue Mar 10 10:42:44 2015 +0000
@@ -386,7 +386,7 @@
int
Ns_SockCork(Ns_Sock *sock, int cork)
{
- int success = 1;
+ int success = 0;
#ifdef TCP_CORK
Sock *sockPtr = (Sock *)sock;
On 9 March 2015 at 16:24, David Osborne <da...@qc...> wrote:
> Hi again,
>
> We're getting some Error messages when we're browsing fastpath pages
> running tip via https.
> Not sure of this is anything to actually to worry about since there
> doesn't seem to be any side-effect except for the frequent error messages
> in the log.
>
> *[09/Mar/2015:15:59:06][17560.7fffedf37700][-conn:default:4-] Error:
> socket: trying to uncork an uncorked socket 10*
>
> It appears pretty much every time we click on a link.
>
>
>
> *Test case:*
>
> Building with the tip versions of naviserver and nsssl (but with the
> configure.ac change to CCRFLAG/LDRFLAG we discussed)
>
> Add the following to the end of the default
> /usr/local/ns/conf/nsd-config.tcl:
>
> ns_section ns/server/default/module/nsssl
> ns_param certificate
> /usr/local/ns/modules/nsssl/server.pem
> ns_param address 0.0.0.0
> ns_param port 443
> ns_param ciphers
> "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!RC4
> "
> ns_param protocols "!SSLv2"
> ns_param verify 0
>
> ns_param extraheaders {
> Strict-Transport-Security "max-age=31536000; includeSubDomains"
> X-Frame-Options SAMEORIGIN
> X-Content-Type-Options nosniff
> }
>
> List nsssl.so in the module list
>
> ns_section "ns/server/default/modules"
> ns_param nscp nscp.so
> ns_param nssock nssock.so
> ns_param nslog nslog.so
> ns_param nscgi nscgi.so
> ns_param nsdb nsdb.so
> ns_param nsssl nsssl.so
>
> Do the following to generate a self-signed cert:
>
> openssl genrsa 1024 > host.key
> openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert
> cat host.cert host.key > server.pem
> rm -rf host.cert host.key
> openssl dhparam 2048 >> server.pem
>
>
>
> Run:
> /usr/local/ns/bin/nsd -c -u root -t /usr/local/ns/conf/nsd-config.tcl
>
> Browsing to https://servername/doc/index.html then clicking on one of the
> command names (eg. to take us
> https://servername/doc/naviserver/files/ns_adp_break.html) will cause the
> error.
>
>
> I tried to catch this in gdb by setting a breakpoint on Ns_Log with
> severity Error:
>
> ...
> [09/Mar/2015:15:49:37][17543.7fffef22d700][-sched-] Notice: sched: starting
> [Switching to Thread 0x7fffedf37700 (LWP 17554)]
>
> Breakpoint 3, Ns_Log (severity=severity@entry=2, fmt=fmt@entry=0x7ffff7bbabe0
> "socket: trying to uncork an uncorked socket %d")
> at log.c:481
> 481 {
> (gdb) bt
> #0 Ns_Log (severity=severity@entry=2, fmt=fmt@entry=0x7ffff7bbabe0
> "socket: trying to uncork an uncorked socket %d")
> at log.c:481
> #1 0x00007ffff7b91516 in Ns_SockCork (sock=sock@entry=0x7ffff001c9a0,
> cork=cork@entry=0) at sockfile.c:405
> #2 0x00007ffff7b9166a in SendFd (sock=sock@entry=0x7ffff001c9a0, fd=11,
> offset=10165, length=length@entry=10165,
> timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=flags@entry=0,
> sendProc=sendProc@entry=0x7fffee798b70 <Send>)
> at sockfile.c:481
> #3 0x00007ffff7b913e9 in NsSockSendFileBufsIndirect (sock=0x7ffff001c9a0,
> bufs=<optimized out>, nbufs=<optimized out>,
> timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=0,
> sendProc=0x7fffee798b70 <Send>) at sockfile.c:309
> #4 0x00007ffff7b75fc7 in NsDriverSendFile (sockPtr=<optimized out>,
> bufs=bufs@entry=0x7fffedf363a0, nbufs=nbufs@entry=1,
> flags=flags@entry=0) at driver.c:1133
> #5 0x00007ffff7b72ea9 in Ns_ConnSendFileVec (conn=conn@entry=0x66ecb0,
> bufs=bufs@entry=0x7fffedf363a0, nbufs=1)
> at connio.c:525
> #6 0x00007ffff7b8be86 in ReturnRange (conn=conn@entry=0x66ecb0,
> type=type@entry=0x627c90 "text/html", fd=fd@entry=11,
> data=data@entry=0x0, len=len@entry=10165) at return.c:988
> #7 0x00007ffff7b8bc64 in ReturnOpen (conn=conn@entry=0x66ecb0,
> status=status@entry=200, type=type@entry=0x627c90 "text/html",
> chan=chan@entry=0x0, fp=fp@entry=0x0, fd=fd@entry=11, len=10165) at
> return.c:881
> #8 0x00007ffff7b8bbe5 in Ns_ConnReturnOpenFd (conn=conn@entry=0x66ecb0,
> status=status@entry=200,
> type=type@entry=0x627c90 "text/html", fd=fd@entry=11, len=<optimized
> out>) at return.c:854
> #9 0x00007ffff7b7c7fd in FastReturn (conn=conn@entry=0x66ecb0,
> status=status@entry=200, type=0x627c90 "text/html",
> type@entry=0x0, file=0x7fffedf36b00
> "/usr/local/ns/pages/doc/naviserver/files/ns_adp_ctl.html") at
> fastpath.c:570
> #10 0x00007ffff7b7c4c3 in Ns_FastPathProc (UNUSED_arg=<optimized out>,
> conn=0x66ecb0) at fastpath.c:244
> #11 0x00007ffff7b85059 in Ns_ConnRunRequest (conn=conn@entry=0x66ecb0) at
> op.c:293
> #12 0x00007ffff7b89283 in ConnRun (connPtr=0x66ecb0, argPtr=0x16c6a70) at
> queue.c:1513
> #13 NsConnThread (arg=0x16c6a70) at queue.c:1229
> #14 0x00007ffff74ea77c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> #15 0x00007ffff74eb6c9 in ThreadMain (arg=<optimized out>) at pthread.c:809
> #16 0x00007ffff64ed0a4 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #17 0x00007ffff69ebccd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) frame 0
> #0 Ns_Log (severity=severity@entry=2, fmt=fmt@entry=0x7ffff7bbabe0
> "socket: trying to uncork an uncorked socket %d")
> at log.c:481
> 481 {
> (gdb) frame 1
> #1 0x00007ffff7b91516 in Ns_SockCork (sock=sock@entry=0x7ffff001c9a0,
> cork=cork@entry=0) at sockfile.c:405
> 405 Ns_Log(Error, "socket: trying to uncork an uncorked socket
> %d",
> (gdb) print *sock
> $1 = {driver = 0x654c50, sock = 10, sa = {sin_family = 2, sin_port =
> 46046, sin_addr = {s_addr = 191146176},
> sin_zero = "\000\000\000\000\000\000\000"}, arg = 0x7ffff006f510}
>
>
>
>
--
David Osborne
Qcode Software Limited
http://www.qcode.co.uk
T: +44 (0)1463 896484
|
|
From: David O. <da...@qc...> - 2015-03-09 16:24:21
|
Hi again,
We're getting some Error messages when we're browsing fastpath pages
running tip via https.
Not sure of this is anything to actually to worry about since there doesn't
seem to be any side-effect except for the frequent error messages in the
log.
*[09/Mar/2015:15:59:06][17560.7fffedf37700][-conn:default:4-] Error:
socket: trying to uncork an uncorked socket 10*
It appears pretty much every time we click on a link.
*Test case:*
Building with the tip versions of naviserver and nsssl (but with the
configure.ac change to CCRFLAG/LDRFLAG we discussed)
Add the following to the end of the default
/usr/local/ns/conf/nsd-config.tcl:
ns_section ns/server/default/module/nsssl
ns_param certificate
/usr/local/ns/modules/nsssl/server.pem
ns_param address 0.0.0.0
ns_param port 443
ns_param ciphers
"ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!RC4
"
ns_param protocols "!SSLv2"
ns_param verify 0
ns_param extraheaders {
Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Frame-Options SAMEORIGIN
X-Content-Type-Options nosniff
}
List nsssl.so in the module list
ns_section "ns/server/default/modules"
ns_param nscp nscp.so
ns_param nssock nssock.so
ns_param nslog nslog.so
ns_param nscgi nscgi.so
ns_param nsdb nsdb.so
ns_param nsssl nsssl.so
Do the following to generate a self-signed cert:
openssl genrsa 1024 > host.key
openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert
cat host.cert host.key > server.pem
rm -rf host.cert host.key
openssl dhparam 2048 >> server.pem
Run:
/usr/local/ns/bin/nsd -c -u root -t /usr/local/ns/conf/nsd-config.tcl
Browsing to https://servername/doc/index.html then clicking on one of the
command names (eg. to take us
https://servername/doc/naviserver/files/ns_adp_break.html) will cause the
error.
I tried to catch this in gdb by setting a breakpoint on Ns_Log with
severity Error:
...
[09/Mar/2015:15:49:37][17543.7fffef22d700][-sched-] Notice: sched: starting
[Switching to Thread 0x7fffedf37700 (LWP 17554)]
Breakpoint 3, Ns_Log (severity=severity@entry=2, fmt=fmt@entry=0x7ffff7bbabe0
"socket: trying to uncork an uncorked socket %d")
at log.c:481
481 {
(gdb) bt
#0 Ns_Log (severity=severity@entry=2, fmt=fmt@entry=0x7ffff7bbabe0
"socket: trying to uncork an uncorked socket %d")
at log.c:481
#1 0x00007ffff7b91516 in Ns_SockCork (sock=sock@entry=0x7ffff001c9a0,
cork=cork@entry=0) at sockfile.c:405
#2 0x00007ffff7b9166a in SendFd (sock=sock@entry=0x7ffff001c9a0, fd=11,
offset=10165, length=length@entry=10165,
timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=flags@entry=0,
sendProc=sendProc@entry=0x7fffee798b70 <Send>)
at sockfile.c:481
#3 0x00007ffff7b913e9 in NsSockSendFileBufsIndirect (sock=0x7ffff001c9a0,
bufs=<optimized out>, nbufs=<optimized out>,
timeoutPtr=timeoutPtr@entry=0x7fffedf36110, flags=0,
sendProc=0x7fffee798b70 <Send>) at sockfile.c:309
#4 0x00007ffff7b75fc7 in NsDriverSendFile (sockPtr=<optimized out>,
bufs=bufs@entry=0x7fffedf363a0, nbufs=nbufs@entry=1,
flags=flags@entry=0) at driver.c:1133
#5 0x00007ffff7b72ea9 in Ns_ConnSendFileVec (conn=conn@entry=0x66ecb0,
bufs=bufs@entry=0x7fffedf363a0, nbufs=1)
at connio.c:525
#6 0x00007ffff7b8be86 in ReturnRange (conn=conn@entry=0x66ecb0,
type=type@entry=0x627c90 "text/html", fd=fd@entry=11,
data=data@entry=0x0, len=len@entry=10165) at return.c:988
#7 0x00007ffff7b8bc64 in ReturnOpen (conn=conn@entry=0x66ecb0,
status=status@entry=200, type=type@entry=0x627c90 "text/html",
chan=chan@entry=0x0, fp=fp@entry=0x0, fd=fd@entry=11, len=10165) at
return.c:881
#8 0x00007ffff7b8bbe5 in Ns_ConnReturnOpenFd (conn=conn@entry=0x66ecb0,
status=status@entry=200,
type=type@entry=0x627c90 "text/html", fd=fd@entry=11, len=<optimized
out>) at return.c:854
#9 0x00007ffff7b7c7fd in FastReturn (conn=conn@entry=0x66ecb0,
status=status@entry=200, type=0x627c90 "text/html",
type@entry=0x0, file=0x7fffedf36b00
"/usr/local/ns/pages/doc/naviserver/files/ns_adp_ctl.html") at
fastpath.c:570
#10 0x00007ffff7b7c4c3 in Ns_FastPathProc (UNUSED_arg=<optimized out>,
conn=0x66ecb0) at fastpath.c:244
#11 0x00007ffff7b85059 in Ns_ConnRunRequest (conn=conn@entry=0x66ecb0) at
op.c:293
#12 0x00007ffff7b89283 in ConnRun (connPtr=0x66ecb0, argPtr=0x16c6a70) at
queue.c:1513
#13 NsConnThread (arg=0x16c6a70) at queue.c:1229
#14 0x00007ffff74ea77c in NsThreadMain (arg=<optimized out>) at thread.c:227
#15 0x00007ffff74eb6c9 in ThreadMain (arg=<optimized out>) at pthread.c:809
#16 0x00007ffff64ed0a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#17 0x00007ffff69ebccd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) frame 0
#0 Ns_Log (severity=severity@entry=2, fmt=fmt@entry=0x7ffff7bbabe0
"socket: trying to uncork an uncorked socket %d")
at log.c:481
481 {
(gdb) frame 1
#1 0x00007ffff7b91516 in Ns_SockCork (sock=sock@entry=0x7ffff001c9a0,
cork=cork@entry=0) at sockfile.c:405
405 Ns_Log(Error, "socket: trying to uncork an uncorked socket
%d",
(gdb) print *sock
$1 = {driver = 0x654c50, sock = 10, sa = {sin_family = 2, sin_port = 46046,
sin_addr = {s_addr = 191146176},
sin_zero = "\000\000\000\000\000\000\000"}, arg = 0x7ffff006f510}
|
|
From: Gustaf N. <ne...@wu...> - 2015-03-07 19:32:35
|
Dear David, I agree, that NaviServer's "private" libraries are perfect examples of Debian's exception rule. so, i think, we should use the change that you suggested. -g Am 06.03.15 um 13:57 schrieb David Osborne: > Thanks - that was very helpful Gustaf. > > I'm using the Debian tclConfig.sh which does indeed clear those > variables. > > # Flags to pass to ld, such as "-R /usr/local/tcl/lib", that tell the > # run-time dynamic linker where to look for shared libraries such as > # libtcl.so. Used when linking applications. Only works if there > # is a variable "LIB_RUNTIME_DIR" defined in the Makefile. > TCL_CC_SEARCH_FLAGS='' > TCL_LD_SEARCH_FLAGS='' > > Debian does discourage the use of rpath in general except in the > following case which I think applies in this instance: > https://wiki.debian.org/RpathIssue > "Currently, the only generally accepted use of this feature in Debian > is to add non-standard library path (like /usr/lib/<package>) to > libraries that are only intended to be used by the executables or > other libraries within the same source package." > > > So I can understand why Tcl8.5 doesn't have rpath's set in > tclConfig.sh on Debian. > > Which would be the best way to include an rpath to the private > naviserver libraries (libnsdb.so, libnsd.so, libnsthread.so etc.) > during the Naviserver build so the nsd binary can find them? > > It seems strange that I would need to change the TCL_*_SEARCH_FLAGS to > achieve this. > > > > On 6 March 2015 at 10:12, Gustaf Neumann <ne...@wu... > <mailto:ne...@wu...>> wrote: > > Hi David, > > When i add the following two lines > > echo "---TCL_CC_SEARCH_FLAGS=$TCL_CC_SEARCH_FLAGS > CC_SEARCH_FLAGS=$CC_SEARCH_FLAGS" > echo "---TCL_LD_SEARCH_FLAGS=$TCL_LD_SEARCH_FLAGS > LD_SEARCH_FLAGS=$LD_SEARCH_FLAGS" > > before the setting of CCRFLAG and LDRFLAG on ubuntu (12.04.5 LTS), > i see > on the console > > ---TCL_CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > ---TCL_LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > > i.e., CC_SEARCH_FLAGS is the same as TCL_CC_SEARCH_FLAGS, etc. > i would assume that this is on your system different. It looks to > me as if > the TCL_* variants should be used, since these are tailored for Tcl. > > The TCL_* variables are set in the used tclConfig.sh. Which > tclConfig.sh are you using? > is it a "private" one or the Debian one? > > My suspicion is that some distros do not like the search-flags and > clear it... > > -g > > Am 05.03.15 um 16:01 schrieb David Osborne: >> Hi again, >> >> I've been struggling to get --enable-rpath to work in our build >> (on Debian Wheezy). Up to now I'd always been patching >> Makefile.global.in <http://Makefile.global.in> during the Debian >> build to add -Wl,-rpath manually. >> >> Looking at --enable-rpath. It seems to trigger the substitution >> of -Wl,-rpath into CC_SEARCH_FLAGS and LD_SEARCH_FLAGS by >> m4/tcl.m4, but they weren't being pulled into the configure step. >> >> But I noticed configure.ac <http://configure.ac> references >> $TCL_CC_SEARCH_FLAGS & $TCL_LD_SEARCH_FLAGS when setting LDRFLAGS >> & CCRFLAGS, but I couldn't see where they were being set. >> >> Could the following diff be what is intended? >> Seems to make it work for me... >> >> $ hg diff >> diff -r 20530df80f68 configure.ac <http://configure.ac> >> --- a/configure.ac <http://configure.ac> Tue Mar 03 09:07:48 >> 2015 +0000 >> +++ b/configure.ac <http://configure.ac> Thu Mar 05 14:55:42 >> 2015 +0000 >> @@ -133,8 +133,8 @@ >> LDSO="\$(LDLIB)" >> CCRPATHS="\$(CCRPATH)" >> LDRPATHS="\$(LDRPATH)" >> - CCRFLAG=$TCL_CC_SEARCH_FLAGS >> - LDRFLAG=$TCL_LD_SEARCH_FLAGS >> + CCRFLAG=$CC_SEARCH_FLAGS >> + LDRFLAG=$LD_SEARCH_FLAGS >> if test "$CCRFLAG" = "" ; then >> CCRPATH= >> fi >> > > |
|
From: David O. <da...@qc...> - 2015-03-06 12:57:26
|
Thanks - that was very helpful Gustaf. I'm using the Debian tclConfig.sh which does indeed clear those variables. # Flags to pass to ld, such as "-R /usr/local/tcl/lib", that tell the # run-time dynamic linker where to look for shared libraries such as # libtcl.so. Used when linking applications. Only works if there # is a variable "LIB_RUNTIME_DIR" defined in the Makefile. TCL_CC_SEARCH_FLAGS='' TCL_LD_SEARCH_FLAGS='' Debian does discourage the use of rpath in general except in the following case which I think applies in this instance: https://wiki.debian.org/RpathIssue "Currently, the only generally accepted use of this feature in Debian is to add non-standard library path (like /usr/lib/<package>) to libraries that are only intended to be used by the executables or other libraries within the same source package." So I can understand why Tcl8.5 doesn't have rpath's set in tclConfig.sh on Debian. Which would be the best way to include an rpath to the private naviserver libraries (libnsdb.so, libnsd.so, libnsthread.so etc.) during the Naviserver build so the nsd binary can find them? It seems strange that I would need to change the TCL_*_SEARCH_FLAGS to achieve this. On 6 March 2015 at 10:12, Gustaf Neumann <ne...@wu...> wrote: > Hi David, > > When i add the following two lines > > echo "---TCL_CC_SEARCH_FLAGS=$TCL_CC_SEARCH_FLAGS > CC_SEARCH_FLAGS=$CC_SEARCH_FLAGS" > echo "---TCL_LD_SEARCH_FLAGS=$TCL_LD_SEARCH_FLAGS > LD_SEARCH_FLAGS=$LD_SEARCH_FLAGS" > > before the setting of CCRFLAG and LDRFLAG on ubuntu (12.04.5 LTS), i see > on the console > > ---TCL_CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > ---TCL_LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR} > > i.e., CC_SEARCH_FLAGS is the same as TCL_CC_SEARCH_FLAGS, etc. > i would assume that this is on your system different. It looks to me as if > the TCL_* variants should be used, since these are tailored for Tcl. > > The TCL_* variables are set in the used tclConfig.sh. Which tclConfig.sh > are you using? > is it a "private" one or the Debian one? > > My suspicion is that some distros do not like the search-flags and clear > it... > > -g > > Am 05.03.15 um 16:01 schrieb David Osborne: > > Hi again, > > I've been struggling to get --enable-rpath to work in our build (on > Debian Wheezy). Up to now I'd always been patching Makefile.global.in > during the Debian build to add -Wl,-rpath manually. > > Looking at --enable-rpath. It seems to trigger the substitution of > -Wl,-rpath into CC_SEARCH_FLAGS and LD_SEARCH_FLAGS by m4/tcl.m4, but they > weren't being pulled into the configure step. > > But I noticed configure.ac references $TCL_CC_SEARCH_FLAGS > & $TCL_LD_SEARCH_FLAGS when setting LDRFLAGS & CCRFLAGS, but I couldn't see > where they were being set. > > Could the following diff be what is intended? > Seems to make it work for me... > > $ hg diff > diff -r 20530df80f68 configure.ac > --- a/configure.ac Tue Mar 03 09:07:48 2015 +0000 > +++ b/configure.ac Thu Mar 05 14:55:42 2015 +0000 > @@ -133,8 +133,8 @@ > LDSO="\$(LDLIB)" > CCRPATHS="\$(CCRPATH)" > LDRPATHS="\$(LDRPATH)" > - CCRFLAG=$TCL_CC_SEARCH_FLAGS > - LDRFLAG=$TCL_LD_SEARCH_FLAGS > + CCRFLAG=$CC_SEARCH_FLAGS > + LDRFLAG=$LD_SEARCH_FLAGS > if test "$CCRFLAG" = "" ; then > CCRPATH= > fi > > > > > ------------------------------------------------------------------------------ > 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > -- David Osborne Qcode Software Limited http://www.qcode.co.uk T: +44 (0)1463 896484 |
|
From: Gustaf N. <ne...@wu...> - 2015-03-06 10:12:40
|
Hi David,
When i add the following two lines
echo "---TCL_CC_SEARCH_FLAGS=$TCL_CC_SEARCH_FLAGS
CC_SEARCH_FLAGS=$CC_SEARCH_FLAGS"
echo "---TCL_LD_SEARCH_FLAGS=$TCL_LD_SEARCH_FLAGS
LD_SEARCH_FLAGS=$LD_SEARCH_FLAGS"
before the setting of CCRFLAG and LDRFLAG on ubuntu (12.04.5 LTS), i see
on the console
---TCL_CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}
CC_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}
---TCL_LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}
LD_SEARCH_FLAGS=-Wl,-rpath,${LIB_RUNTIME_DIR}
i.e., CC_SEARCH_FLAGS is the same as TCL_CC_SEARCH_FLAGS, etc.
i would assume that this is on your system different. It looks to me as if
the TCL_* variants should be used, since these are tailored for Tcl.
The TCL_* variables are set in the used tclConfig.sh. Which tclConfig.sh
are you using?
is it a "private" one or the Debian one?
My suspicion is that some distros do not like the search-flags and clear
it...
-g
Am 05.03.15 um 16:01 schrieb David Osborne:
> Hi again,
>
> I've been struggling to get --enable-rpath to work in our build (on
> Debian Wheezy). Up to now I'd always been patching Makefile.global.in
> <http://Makefile.global.in> during the Debian build to add -Wl,-rpath
> manually.
>
> Looking at --enable-rpath. It seems to trigger the substitution of
> -Wl,-rpath into CC_SEARCH_FLAGS and LD_SEARCH_FLAGS by m4/tcl.m4, but
> they weren't being pulled into the configure step.
>
> But I noticed configure.ac <http://configure.ac> references
> $TCL_CC_SEARCH_FLAGS & $TCL_LD_SEARCH_FLAGS when setting LDRFLAGS &
> CCRFLAGS, but I couldn't see where they were being set.
>
> Could the following diff be what is intended?
> Seems to make it work for me...
>
> $ hg diff
> diff -r 20530df80f68 configure.ac <http://configure.ac>
> --- a/configure.ac <http://configure.ac> Tue Mar 03 09:07:48 2015
> +0000
> +++ b/configure.ac <http://configure.ac> Thu Mar 05 14:55:42 2015
> +0000
> @@ -133,8 +133,8 @@
> LDSO="\$(LDLIB)"
> CCRPATHS="\$(CCRPATH)"
> LDRPATHS="\$(LDRPATH)"
> - CCRFLAG=$TCL_CC_SEARCH_FLAGS
> - LDRFLAG=$TCL_LD_SEARCH_FLAGS
> + CCRFLAG=$CC_SEARCH_FLAGS
> + LDRFLAG=$LD_SEARCH_FLAGS
> if test "$CCRFLAG" = "" ; then
> CCRPATH=
> fi
>
|
|
From: David O. <da...@qc...> - 2015-03-05 15:09:33
|
Hi again,
I've been struggling to get --enable-rpath to work in our build (on Debian
Wheezy). Up to now I'd always been patching Makefile.global.in during the
Debian build to add -Wl,-rpath manually.
Looking at --enable-rpath. It seems to trigger the substitution of
-Wl,-rpath into CC_SEARCH_FLAGS and LD_SEARCH_FLAGS by m4/tcl.m4, but they
weren't being pulled into the configure step.
But I noticed configure.ac references $TCL_CC_SEARCH_FLAGS
& $TCL_LD_SEARCH_FLAGS when setting LDRFLAGS & CCRFLAGS, but I couldn't see
where they were being set.
Could the following diff be what is intended?
Seems to make it work for me...
$ hg diff
diff -r 20530df80f68 configure.ac
--- a/configure.ac Tue Mar 03 09:07:48 2015 +0000
+++ b/configure.ac Thu Mar 05 14:55:42 2015 +0000
@@ -133,8 +133,8 @@
LDSO="\$(LDLIB)"
CCRPATHS="\$(CCRPATH)"
LDRPATHS="\$(LDRPATH)"
- CCRFLAG=$TCL_CC_SEARCH_FLAGS
- LDRFLAG=$TCL_LD_SEARCH_FLAGS
+ CCRFLAG=$CC_SEARCH_FLAGS
+ LDRFLAG=$LD_SEARCH_FLAGS
if test "$CCRFLAG" = "" ; then
CCRPATH=
fi
--
David Osborne
Qcode Software Limited
http://www.qcode.co.uk
|
|
From: Gustaf N. <ne...@wu...> - 2015-03-04 03:12:05
|
Dear all,
This problem is now fixed on bitbucket. the problem occurred,
when one thread frees a nsv-array, but an internal representation
of an Tcl_Obj for this array in another thread still contained a
pointer to the (freed) array. It seems that whole nsv-arrays
are not to often freed in applications.
The bug was introduced many years ago, when starting to use
TclSetOpaqueObj() for Array structures. This did not hurt very
long time, since the arrays were never freed - causing
a memory leak. The problem became virulent by a change of me
fixing this memory leak of unset nsv-array structures in Nov 2014.
After the change we use now a less aggressive caching by
just storing the bucket pointer in the internal representation of
the Tcl_Obj. In order to get a full caching of the array as before,
the best thing would probably be the introduction of a new
tcl-obj type which uses an epoch on the bucket for the
validation of the array structure.
For the time being it is more important to get a robust version out.
There are two more fixes already committed on bitbucket, where
were flagged by the testing of Wolfgang Winkler (many thanks!),
so i think we should treat 4.99.7 as a pre-release of 4.99.8,
which we could release next week or so.
all the best
-gustaf neumann
Am 02.03.15 um 14:06 schrieb David Osborne:
> Thanks Gustaf.
>
> I've over written the original core dump I sent to you, but this the
> equivalent info from a new core (this was a seg fault this time but
> appears to be at exactly the same location). The arrayObj is
> 0x2b45a40084e0 in this case.
>
> Does any of this help further?
>
> PS. this does not happen every time. It's intermittent. Maybe 50% of
> the times I run "make test"
>
> (gdb) bt
> #0 Ns_MutexLock (mutex=0x2b4500001004) at mutex.c:239
> #1 0x00002b45989bf9ed in LockArrayObj
> (interp=interp@entry=0x2b45a4030ea0, arrayObj=0x2b45a40084e0,
> create=create@entry=0) at tclvar.c:1265
> #2 0x00002b45989bef7e in NsTclNsvArrayObjCmd
> (UNUSED_clientData=<optimized out>, interp=0x2b45a4030ea0, objc=3,
> objv=0x2b45a40571b8) at tclvar.c:669
> #3 0x00002b4599288e59 in TclEvalObjvInternal () from
> /usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
> #4 0x00002b45992cf95e in TclExecuteByteCode () from
> /usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
> #5 0x00002b4599312ce9 in TclObjInterpProcCore () from
> /usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
> #6 0x00002b4599288e59 in TclEvalObjvInternal () from
> /usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
> #7 0x00002b4599289b29 in TclEvalEx () from
> /usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
> #8 0x00002b4599289473 in Tcl_EvalEx () from
> /usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
> #9 0x00002b45989ac1cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
> server=<optimized out>,
> script=script@entry=0x2b459c382d74 "\n # If necessary due
> to running this code in a different environment, you\n # can
> have the newly spawned worker thread first source this file here.\n
> tst_cond_worker\n ") at tclinit.c:334
> #10 0x00002b45989bd073 in NsTclThread (arg=0x2b459c382d60) at
> tclthread.c:834
> #11 0x00002b459905184c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> #12 0x00002b4599052839 in ThreadMain (arg=<optimized out>) at
> pthread.c:809
> #13 0x00002b459a04f0a4 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #14 0x00002b4599b7fccd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> (gdb) frame 1
> #1 0x00002b45989bf9ed in LockArrayObj
> (interp=interp@entry=0x2b45a4030ea0, arrayObj=0x2b45a40084e0,
> create=create@entry=0) at tclvar.c:1265
> 1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock));
>
> (gdb) list
> 1260 assert(interp != NULL);
> 1261 assert(arrayObj != NULL);
> 1262
> 1263 if (likely(Ns_TclGetOpaqueFromObj(arrayObj, arrayType,
> (void **) &arrayPtr) == TCL_OK)
> 1264 && arrayPtr->bucketPtr != NULL) {
> 1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock));
> 1266 arrayPtr->locks++;
> 1267 } else {
> 1268 NsInterp *itPtr = NsGetInterpData(interp);
> 1269
>
> (gdb) print *arrayPtr
> $41 = {bucketPtr = 0x2b4500001004, entryPtr = 0x2b459c320010, vars =
> {buckets = 0x1, staticBuckets = {[0] = 0x0, [1] = 0x2b45a4023210, [2]
> = 0x3557e6,
> [3] = 0x2b459c2190f0}, numBuckets = -1674442720, numEntries =
> 11077, rebuildSize = -1725047104, downShift = 11077, mask = -1725047072,
> keyType = 11077, findProc = 0x2b459957f5c0 <tclVarHashKeyType>,
> createProc = 0, typePtr = 0x6c757365722d207d}, locks = 13545984096477300}
> (gdb) print arrayObj
> $42 = (Tcl_Obj *) 0x2b45a40084e0
>
> (gdb) print *arrayObj
> $43 = {refCount = 3, bytes = 0x2b459c392dd0 "ct1_work_queue", length =
> 14, typePtr = 0x2b4598bf5ac0, internalRep = {longValue = 47577913202687,
> doubleValue = 2.3506612414264323e-310, otherValuePtr =
> 0x2b45989d97ff, wideValue = 47577913202687, twoPtrValue = {ptr1 =
> 0x2b45989d97ff,
> ptr2 = 0x2b459c2190f0}, ptrAndLongRep = {ptr = 0x2b45989d97ff,
> value = 47577972183280}}}
>
> (gdb) x/s 0x2b45989d97ff
> 0x2b45989d97ff: "nsv:array"
>
> (gdb) print *arrayObj->typePtr
> $46 = {name = 0x2b45989d7f03 "ns:addr", freeIntRepProc = 0,
> dupIntRepProc = 0, updateStringProc = 0x2b45989b3930 <UpdateStringOfAddr>,
> setFromAnyProc = 0x2b45989b39c0 <SetAddrFromAny>}
>
>
>
>
>
>
>
> On 27 February 2015 at 20:48, Gustaf Neumann <ne...@wu...
> <mailto:ne...@wu...>> wrote:
>
> Hi David,
>
> this is certainly not as expected, but i can't reproduce it.
> Does this happen on every run?
>
> It would be interesting to see the content of
>
> arrayObj=0xa05a8b0
>
> in frame #1 where the bytes should be the name of the array in
> question,
> the type should be a "ns:addr", ptr1 should be "nsv:array" and ptr2
> the arrayPtr. It is also interesting to see the pontents of arrayPtr.
>
> i've built and tested the server on various unix systems, the closest
> was probably an ubunu 12.04.
>
> -g
>
>
> Am 27.02.15 um 17:52 schrieb David Osborne:
>> Hi,
>>
>> We're looking at doing a build of Naviserver tagged as 4.99.7.
>> But we seem to be hitting an intermittent seg fault or bus error
>> during the "make test".
>>
>> Sometimes the tests complete cleanly.
>> It's often while running ns_conn.test, usually it PASSED
>> ns_conn-1.2 then crashes.
>> This is on a Debian 7.8 server.
>>
>> Built by doing:
>> ./autogen.sh --with-tcl=/usr/lib/tcl8.5
>> ./configure --with-tcl=/usr/lib/tcl8.5 --prefix=/usr/local/ns
>> --enable-symbols --enable-threads
>> make
>> make test
>>
>> I have core dumps. There's a backtrace at the end of the bus
>> error (but gdb isn't my area so apologies if there's nothing
>> useful in there).
>>
>> Is this anything of concern?
>>
>> --
>> David
>> Qcode Software Limited
>> http://www.qcode.co.uk
>>
>>
>> Using host libthread_db library
>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `./nsd/nsd -u root -c -d -t
>> /root/naviserver/tests/test.nscfg /root/naviserver/t'.
>> Program terminated with signal 7, Bus error.
>> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
>> 239 mutexPtr = GETMUTEX(mutex);
>> (gdb) info threads
>> Id Target Id Frame
>> 18 Thread 0x2b8bd7b5f700 (LWP 7173) 0x00002b8bd685b5f2 in
>> Tcl_ExternalToUtfDString () from /usr/lib/libtcl8.5.so.0
>> 17 Thread 0x2b8bdc580700 (LWP 7192)
>> pthread_cond_timedwait@@GLIBC_2.3.2
>> <mailto:pthread_cond_timedwait@@GLIBC_2.3.2> ()
>> at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
>> 16 Thread 0x2b8bdc37f700 (LWP 7189) 0x00002b8bd7075d13 in
>> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
>> timeout=timeout@entry=30000) at
>> ../sysdeps/unix/sysv/linux/poll.c:87
>> 15 Thread 0x2b8bdc17e700 (LWP 7188) 0x00002b8bd7075d13 in
>> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
>> timeout=timeout@entry=30000) at
>> ../sysdeps/unix/sysv/linux/poll.c:87
>> 14 Thread 0x2b8bdbf7d700 (LWP 7187) 0x00002b8bd7075d13 in
>> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
>> timeout=timeout@entry=30000) at
>> ../sysdeps/unix/sysv/linux/poll.c:87
>> 13 Thread 0x2b8bdbd7c700 (LWP 7186) 0x00002b8bd7075d13 in
>> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
>> timeout=timeout@entry=30000) at
>> ../sysdeps/unix/sysv/linux/poll.c:87
>> 12 Thread 0x2b8bdbb7b700 (LWP 7185) 0x00002b8bd7075d13 in
>> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
>> timeout=timeout@entry=30000) at
>> ../sysdeps/unix/sysv/linux/poll.c:87
>> 11 Thread 0x2b8bdb97a700 (LWP 7184) 0x00002b8bd7075d13 in
>> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
>> timeout=timeout@entry=30000) at
>> ../sysdeps/unix/sysv/linux/poll.c:87
>> 10 Thread 0x2b8bdb779700 (LWP 7183) 0x00002b8bd7075d13 in
>> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
>> timeout=timeout@entry=10000) at
>> ../sysdeps/unix/sysv/linux/poll.c:87
>> 9 Thread 0x2b8bdb578700 (LWP 7182)
>> pthread_cond_timedwait@@GLIBC_2.3.2
>> <mailto:pthread_cond_timedwait@@GLIBC_2.3.2> ()
>> at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
>> 8 Thread 0x2b8bdb377700 (LWP 7181)
>> pthread_cond_timedwait@@GLIBC_2.3.2
>> <mailto:pthread_cond_timedwait@@GLIBC_2.3.2> ()
>> at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
>> 7 Thread 0x2b8bdb176700 (LWP 7180)
>> pthread_cond_timedwait@@GLIBC_2.3.2
>> <mailto:pthread_cond_timedwait@@GLIBC_2.3.2> ()
>> at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
>> 6 Thread 0x2b8bdaf75700 (LWP 7179)
>> pthread_cond_timedwait@@GLIBC_2.3.2
>> <mailto:pthread_cond_timedwait@@GLIBC_2.3.2> ()
>> at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
>> 5 Thread 0x2b8bdad74700 (LWP 7178)
>> pthread_cond_timedwait@@GLIBC_2.3.2
>> <mailto:pthread_cond_timedwait@@GLIBC_2.3.2> ()
>> at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
>> 4 Thread 0x2b8bda567700 (LWP 7177)
>> pthread_cond_timedwait@@GLIBC_2.3.2
>> <mailto:pthread_cond_timedwait@@GLIBC_2.3.2> ()
>> at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
>> 3 Thread 0x2b8bd7ed7700 (LWP 7174) 0x00002b8bd707a453 in
>> select () at ../sysdeps/unix/syscall-template.S:82
>> 2 Thread 0x2b8bd77522e0 (LWP 7172) do_sigwait
>> (set=0x7fff74ac2f50, sig=0x7fff74ac2f4c)
>> at
>> ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:65
>> * 1 Thread 0x2b8bdcba2700 (LWP 7196) Ns_MutexLock
>> (mutex=0x206c617665757274) at mutex.c:239
>> (gdb) bt
>> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
>> #1 0x00002b8bd5f569ed in LockArrayObj
>> (interp=interp@entry=0xa0022a0, arrayObj=0xa05a8b0,
>> create=create@entry=0) at tclvar.c:1265
>> #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd
>> (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3,
>> objv=0xa060c38)
>> at tclvar.c:669
>> #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
>> #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0
>> #5 0x00002b8bd68a427b in TclObjInterpProcCore () from
>> /usr/lib/libtcl8.5.so.0
>> #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
>> #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0
>> #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0
>> #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
>> server=<optimized out>,
>> script=script@entry=0x9fb2884 "\n # If necessary due
>> to running this code in a different environment, you\n #
>> can have the newly spawned worker thread first source this file
>> here.\n tst_cond_worker\n ") at tclinit.c:334
>> #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at
>> tclthread.c:834
>> #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at
>> thread.c:227
>> #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at
>> pthread.c:809
>> #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at
>> pthread_create.c:304
>> #14 0x00002b8bd708095d in clone () at
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
>> #15 0x0000000000000000 in ?? ()
>> (gdb) frame 15
>> #15 0x0000000000000000 in ?? ()
>> (gdb) frame 14
>> #14 0x00002b8bd708095d in clone () at
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
>> 112 in ../sysdeps/unix/sysv/linux/x86_64/clone.S
>> (gdb) frame 13
>> #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at
>> pthread_create.c:304
>> 304 pthread_create.c: No such file or directory.
>> (gdb) frame 12
>> #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at
>> pthread.c:809
>> 809 NsThreadMain(arg);
>> (gdb) frame 11
>> #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at
>> thread.c:227
>> 227 (*thrPtr->proc) (thrPtr->arg);
>> (gdb) frame 10
>> #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at
>> tclthread.c:834
>> 834 (void) Ns_TclEval(dsPtr, argPtr->server, argPtr->script);
>> (gdb) frame 9
>> #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
>> server=<optimized out>,
>> script=script@entry=0x9fb2884 "\n # If necessary due
>> to running this code in a different environment, you\n #
>> can have the newly spawned worker thread first source this file
>> here.\n tst_cond_worker\n ") at tclinit.c:334
>> 334 if (Tcl_EvalEx(interp, script, -1, 0) != TCL_OK) {
>> (gdb) frame 8
>> #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0
>> (gdb) frame 7
>> #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0
>> (gdb) frame 6
>> #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
>> (gdb) frame 5
>> #5 0x00002b8bd68a427b in TclObjInterpProcCore () from
>> /usr/lib/libtcl8.5.so.0
>> (gdb) frame 4
>> #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0
>> (gdb) frame 3
>> #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
>> (gdb) frame 2
>> #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd
>> (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3,
>> objv=0xa060c38)
>> at tclvar.c:669
>> 669 arrayPtr = LockArrayObj(interp, objv[2], 0);
>> (gdb) frame 1
>> #1 0x00002b8bd5f569ed in LockArrayObj
>> (interp=interp@entry=0xa0022a0, arrayObj=0xa05a8b0,
>> create=create@entry=0) at tclvar.c:1265
>> 1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock));
>> (gdb) frame 0
>> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
>> 239 mutexPtr = GETMUTEX(mutex);
>> (gdb) list
>> 234 Ns_GetTime(&startTime);
>> 235 #endif
>> 236
>> 237 assert(mutex != NULL);
>> 238
>> 239 mutexPtr = GETMUTEX(mutex);
>> 240 if (unlikely(!NsLockTry(mutexPtr->lock))) {
>> 241 NsLockSet(mutexPtr->lock);
>> 242 ++mutexPtr->nbusy;
>> 243
>> (gdb)
>>
>>
>>
|
|
From: David O. <da...@qc...> - 2015-03-02 13:34:44
|
Thanks Gustaf.
I've over written the original core dump I sent to you, but this the
equivalent info from a new core (this was a seg fault this time but
appears to be at exactly the same location). The arrayObj is 0x2b45a40084e0
in this case.
Does any of this help further?
PS. this does not happen every time. It's intermittent. Maybe 50% of the
times I run "make test"
(gdb) bt
#0 Ns_MutexLock (mutex=0x2b4500001004) at mutex.c:239
#1 0x00002b45989bf9ed in LockArrayObj (interp=interp@entry=0x2b45a4030ea0,
arrayObj=0x2b45a40084e0, create=create@entry=0) at tclvar.c:1265
#2 0x00002b45989bef7e in NsTclNsvArrayObjCmd (UNUSED_clientData=<optimized
out>, interp=0x2b45a4030ea0, objc=3, objv=0x2b45a40571b8) at tclvar.c:669
#3 0x00002b4599288e59 in TclEvalObjvInternal () from
/usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
#4 0x00002b45992cf95e in TclExecuteByteCode () from
/usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
#5 0x00002b4599312ce9 in TclObjInterpProcCore () from
/usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
#6 0x00002b4599288e59 in TclEvalObjvInternal () from
/usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
#7 0x00002b4599289b29 in TclEvalEx () from
/usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
#8 0x00002b4599289473 in Tcl_EvalEx () from
/usr/lib/x86_64-linux-gnu/libtcl8.5.so.0
#9 0x00002b45989ac1cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
server=<optimized out>,
script=script@entry=0x2b459c382d74 "\n # If necessary due to
running this code in a different environment, you\n # can have the
newly spawned worker thread first source this file here.\n
tst_cond_worker\n ") at tclinit.c:334
#10 0x00002b45989bd073 in NsTclThread (arg=0x2b459c382d60) at
tclthread.c:834
#11 0x00002b459905184c in NsThreadMain (arg=<optimized out>) at thread.c:227
#12 0x00002b4599052839 in ThreadMain (arg=<optimized out>) at pthread.c:809
#13 0x00002b459a04f0a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00002b4599b7fccd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) frame 1
#1 0x00002b45989bf9ed in LockArrayObj (interp=interp@entry=0x2b45a4030ea0,
arrayObj=0x2b45a40084e0, create=create@entry=0) at tclvar.c:1265
1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock));
(gdb) list
1260 assert(interp != NULL);
1261 assert(arrayObj != NULL);
1262
1263 if (likely(Ns_TclGetOpaqueFromObj(arrayObj, arrayType, (void
**) &arrayPtr) == TCL_OK)
1264 && arrayPtr->bucketPtr != NULL) {
1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock));
1266 arrayPtr->locks++;
1267 } else {
1268 NsInterp *itPtr = NsGetInterpData(interp);
1269
(gdb) print *arrayPtr
$41 = {bucketPtr = 0x2b4500001004, entryPtr = 0x2b459c320010, vars =
{buckets = 0x1, staticBuckets = {[0] = 0x0, [1] = 0x2b45a4023210, [2] =
0x3557e6,
[3] = 0x2b459c2190f0}, numBuckets = -1674442720, numEntries = 11077,
rebuildSize = -1725047104, downShift = 11077, mask = -1725047072,
keyType = 11077, findProc = 0x2b459957f5c0 <tclVarHashKeyType>,
createProc = 0, typePtr = 0x6c757365722d207d}, locks = 13545984096477300}
(gdb) print arrayObj
$42 = (Tcl_Obj *) 0x2b45a40084e0
(gdb) print *arrayObj
$43 = {refCount = 3, bytes = 0x2b459c392dd0 "ct1_work_queue", length = 14,
typePtr = 0x2b4598bf5ac0, internalRep = {longValue = 47577913202687,
doubleValue = 2.3506612414264323e-310, otherValuePtr = 0x2b45989d97ff,
wideValue = 47577913202687, twoPtrValue = {ptr1 = 0x2b45989d97ff,
ptr2 = 0x2b459c2190f0}, ptrAndLongRep = {ptr = 0x2b45989d97ff, value
= 47577972183280}}}
(gdb) x/s 0x2b45989d97ff
0x2b45989d97ff: "nsv:array"
(gdb) print *arrayObj->typePtr
$46 = {name = 0x2b45989d7f03 "ns:addr", freeIntRepProc = 0, dupIntRepProc =
0, updateStringProc = 0x2b45989b3930 <UpdateStringOfAddr>,
setFromAnyProc = 0x2b45989b39c0 <SetAddrFromAny>}
On 27 February 2015 at 20:48, Gustaf Neumann <ne...@wu...> wrote:
> Hi David,
>
> this is certainly not as expected, but i can't reproduce it.
> Does this happen on every run?
>
> It would be interesting to see the content of
>
> arrayObj=0xa05a8b0
>
> in frame #1 where the bytes should be the name of the array in question,
> the type should be a "ns:addr", ptr1 should be "nsv:array" and ptr2
> the arrayPtr. It is also interesting to see the pontents of arrayPtr.
>
> i've built and tested the server on various unix systems, the closest
> was probably an ubunu 12.04.
>
> -g
>
>
> Am 27.02.15 um 17:52 schrieb David Osborne:
>
> Hi,
>
> We're looking at doing a build of Naviserver tagged as 4.99.7. But we
> seem to be hitting an intermittent seg fault or bus error during the "make
> test".
>
> Sometimes the tests complete cleanly.
> It's often while running ns_conn.test, usually it PASSED ns_conn-1.2 then
> crashes.
> This is on a Debian 7.8 server.
>
> Built by doing:
> ./autogen.sh --with-tcl=/usr/lib/tcl8.5
> ./configure --with-tcl=/usr/lib/tcl8.5 --prefix=/usr/local/ns
> --enable-symbols --enable-threads
> make
> make test
>
> I have core dumps. There's a backtrace at the end of the bus error (but
> gdb isn't my area so apologies if there's nothing useful in there).
>
> Is this anything of concern?
>
> --
> David
> Qcode Software Limited
> http://www.qcode.co.uk
>
>
> Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `./nsd/nsd -u root -c -d -t
> /root/naviserver/tests/test.nscfg /root/naviserver/t'.
> Program terminated with signal 7, Bus error.
> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
> 239 mutexPtr = GETMUTEX(mutex);
> (gdb) info threads
> Id Target Id Frame
> 18 Thread 0x2b8bd7b5f700 (LWP 7173) 0x00002b8bd685b5f2 in
> Tcl_ExternalToUtfDString () from /usr/lib/libtcl8.5.so.0
> 17 Thread 0x2b8bdc580700 (LWP 7192)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 16 Thread 0x2b8bdc37f700 (LWP 7189) 0x00002b8bd7075d13 in *__GI___poll
> (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 15 Thread 0x2b8bdc17e700 (LWP 7188) 0x00002b8bd7075d13 in *__GI___poll
> (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 14 Thread 0x2b8bdbf7d700 (LWP 7187) 0x00002b8bd7075d13 in *__GI___poll
> (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 13 Thread 0x2b8bdbd7c700 (LWP 7186) 0x00002b8bd7075d13 in *__GI___poll
> (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 12 Thread 0x2b8bdbb7b700 (LWP 7185) 0x00002b8bd7075d13 in *__GI___poll
> (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 11 Thread 0x2b8bdb97a700 (LWP 7184) 0x00002b8bd7075d13 in *__GI___poll
> (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 10 Thread 0x2b8bdb779700 (LWP 7183) 0x00002b8bd7075d13 in *__GI___poll
> (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=10000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 9 Thread 0x2b8bdb578700 (LWP 7182)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 8 Thread 0x2b8bdb377700 (LWP 7181)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 7 Thread 0x2b8bdb176700 (LWP 7180)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 6 Thread 0x2b8bdaf75700 (LWP 7179)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 5 Thread 0x2b8bdad74700 (LWP 7178)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 4 Thread 0x2b8bda567700 (LWP 7177)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 3 Thread 0x2b8bd7ed7700 (LWP 7174) 0x00002b8bd707a453 in select () at
> ../sysdeps/unix/syscall-template.S:82
> 2 Thread 0x2b8bd77522e0 (LWP 7172) do_sigwait (set=0x7fff74ac2f50,
> sig=0x7fff74ac2f4c)
> at
> ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:65
> * 1 Thread 0x2b8bdcba2700 (LWP 7196) Ns_MutexLock
> (mutex=0x206c617665757274) at mutex.c:239
> (gdb) bt
> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
> #1 0x00002b8bd5f569ed in LockArrayObj (interp=interp@entry=0xa0022a0,
> arrayObj=0xa05a8b0, create=create@entry=0) at tclvar.c:1265
> #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd
> (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3,
> objv=0xa060c38)
> at tclvar.c:669
> #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0
> #5 0x00002b8bd68a427b in TclObjInterpProcCore () from
> /usr/lib/libtcl8.5.so.0
> #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0
> #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0
> #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
> server=<optimized out>,
> script=script@entry=0x9fb2884 "\n # If necessary due to
> running this code in a different environment, you\n # can have the
> newly spawned worker thread first source this file here.\n
> tst_cond_worker\n ") at tclinit.c:334
> #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at tclthread.c:834
> #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at pthread.c:809
> #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at
> pthread_create.c:304
> #14 0x00002b8bd708095d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #15 0x0000000000000000 in ?? ()
> (gdb) frame 15
> #15 0x0000000000000000 in ?? ()
> (gdb) frame 14
> #14 0x00002b8bd708095d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> 112 in ../sysdeps/unix/sysv/linux/x86_64/clone.S
> (gdb) frame 13
> #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at
> pthread_create.c:304
> 304 pthread_create.c: No such file or directory.
> (gdb) frame 12
> #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at pthread.c:809
> 809 NsThreadMain(arg);
> (gdb) frame 11
> #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> 227 (*thrPtr->proc) (thrPtr->arg);
> (gdb) frame 10
> #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at tclthread.c:834
> 834 (void) Ns_TclEval(dsPtr, argPtr->server, argPtr->script);
> (gdb) frame 9
> #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
> server=<optimized out>,
> script=script@entry=0x9fb2884 "\n # If necessary due to
> running this code in a different environment, you\n # can have the
> newly spawned worker thread first source this file here.\n
> tst_cond_worker\n ") at tclinit.c:334
> 334 if (Tcl_EvalEx(interp, script, -1, 0) != TCL_OK) {
> (gdb) frame 8
> #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 7
> #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 6
> #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 5
> #5 0x00002b8bd68a427b in TclObjInterpProcCore () from
> /usr/lib/libtcl8.5.so.0
> (gdb) frame 4
> #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 3
> #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 2
> #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd
> (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3,
> objv=0xa060c38)
> at tclvar.c:669
> 669 arrayPtr = LockArrayObj(interp, objv[2], 0);
> (gdb) frame 1
> #1 0x00002b8bd5f569ed in LockArrayObj (interp=interp@entry=0xa0022a0,
> arrayObj=0xa05a8b0, create=create@entry=0) at tclvar.c:1265
> 1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock));
> (gdb) frame 0
> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
> 239 mutexPtr = GETMUTEX(mutex);
> (gdb) list
> 234 Ns_GetTime(&startTime);
> 235 #endif
> 236
> 237 assert(mutex != NULL);
> 238
> 239 mutexPtr = GETMUTEX(mutex);
> 240 if (unlikely(!NsLockTry(mutexPtr->lock))) {
> 241 NsLockSet(mutexPtr->lock);
> 242 ++mutexPtr->nbusy;
> 243
> (gdb)
>
>
> ------------------------------------------------------------------------------
> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
>
> --
> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
--
David Osborne
Qcode Software Limited
http://www.qcode.co.uk
T: +44 (0)1463 896484
|
|
From: Gustaf N. <ne...@wu...> - 2015-02-27 20:48:50
|
Hi David,
this is certainly not as expected, but i can't reproduce it.
Does this happen on every run?
It would be interesting to see the content of
arrayObj=0xa05a8b0
in frame #1 where the bytes should be the name of the array in question,
the type should be a "ns:addr", ptr1 should be "nsv:array" and ptr2
the arrayPtr. It is also interesting to see the pontents of arrayPtr.
i've built and tested the server on various unix systems, the closest
was probably an ubunu 12.04.
-g
Am 27.02.15 um 17:52 schrieb David Osborne:
> Hi,
>
> We're looking at doing a build of Naviserver tagged as 4.99.7. But we
> seem to be hitting an intermittent seg fault or bus error during the
> "make test".
>
> Sometimes the tests complete cleanly.
> It's often while running ns_conn.test, usually it PASSED ns_conn-1.2
> then crashes.
> This is on a Debian 7.8 server.
>
> Built by doing:
> ./autogen.sh --with-tcl=/usr/lib/tcl8.5
> ./configure --with-tcl=/usr/lib/tcl8.5 --prefix=/usr/local/ns
> --enable-symbols --enable-threads
> make
> make test
>
> I have core dumps. There's a backtrace at the end of the bus error
> (but gdb isn't my area so apologies if there's nothing useful in there).
>
> Is this anything of concern?
>
> --
> David
> Qcode Software Limited
> http://www.qcode.co.uk
>
>
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `./nsd/nsd -u root -c -d -t
> /root/naviserver/tests/test.nscfg /root/naviserver/t'.
> Program terminated with signal 7, Bus error.
> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
> 239 mutexPtr = GETMUTEX(mutex);
> (gdb) info threads
> Id Target Id Frame
> 18 Thread 0x2b8bd7b5f700 (LWP 7173) 0x00002b8bd685b5f2 in
> Tcl_ExternalToUtfDString () from /usr/lib/libtcl8.5.so.0
> 17 Thread 0x2b8bdc580700 (LWP 7192)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 16 Thread 0x2b8bdc37f700 (LWP 7189) 0x00002b8bd7075d13 in
> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 15 Thread 0x2b8bdc17e700 (LWP 7188) 0x00002b8bd7075d13 in
> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 14 Thread 0x2b8bdbf7d700 (LWP 7187) 0x00002b8bd7075d13 in
> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 13 Thread 0x2b8bdbd7c700 (LWP 7186) 0x00002b8bd7075d13 in
> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 12 Thread 0x2b8bdbb7b700 (LWP 7185) 0x00002b8bd7075d13 in
> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 11 Thread 0x2b8bdb97a700 (LWP 7184) 0x00002b8bd7075d13 in
> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 10 Thread 0x2b8bdb779700 (LWP 7183) 0x00002b8bd7075d13 in
> *__GI___poll (fds=<optimized out>, nfds=<optimized out>,
> timeout=timeout@entry=10000) at ../sysdeps/unix/sysv/linux/poll.c:87
> 9 Thread 0x2b8bdb578700 (LWP 7182)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 8 Thread 0x2b8bdb377700 (LWP 7181)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 7 Thread 0x2b8bdb176700 (LWP 7180)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 6 Thread 0x2b8bdaf75700 (LWP 7179)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 5 Thread 0x2b8bdad74700 (LWP 7178)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 4 Thread 0x2b8bda567700 (LWP 7177)
> pthread_cond_timedwait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216
> 3 Thread 0x2b8bd7ed7700 (LWP 7174) 0x00002b8bd707a453 in select
> () at ../sysdeps/unix/syscall-template.S:82
> 2 Thread 0x2b8bd77522e0 (LWP 7172) do_sigwait
> (set=0x7fff74ac2f50, sig=0x7fff74ac2f4c)
> at
> ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:65
> * 1 Thread 0x2b8bdcba2700 (LWP 7196) Ns_MutexLock
> (mutex=0x206c617665757274) at mutex.c:239
> (gdb) bt
> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
> #1 0x00002b8bd5f569ed in LockArrayObj (interp=interp@entry=0xa0022a0,
> arrayObj=0xa05a8b0, create=create@entry=0) at tclvar.c:1265
> #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd
> (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3,
> objv=0xa060c38)
> at tclvar.c:669
> #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0
> #5 0x00002b8bd68a427b in TclObjInterpProcCore () from
> /usr/lib/libtcl8.5.so.0
> #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0
> #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0
> #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
> server=<optimized out>,
> script=script@entry=0x9fb2884 "\n # If necessary due to
> running this code in a different environment, you\n # can have
> the newly spawned worker thread first source this file here.\n
> tst_cond_worker\n ") at tclinit.c:334
> #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at tclthread.c:834
> #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at
> pthread.c:809
> #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at
> pthread_create.c:304
> #14 0x00002b8bd708095d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #15 0x0000000000000000 in ?? ()
> (gdb) frame 15
> #15 0x0000000000000000 in ?? ()
> (gdb) frame 14
> #14 0x00002b8bd708095d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> 112 in ../sysdeps/unix/sysv/linux/x86_64/clone.S
> (gdb) frame 13
> #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at
> pthread_create.c:304
> 304 pthread_create.c: No such file or directory.
> (gdb) frame 12
> #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at
> pthread.c:809
> 809 NsThreadMain(arg);
> (gdb) frame 11
> #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at
> thread.c:227
> 227 (*thrPtr->proc) (thrPtr->arg);
> (gdb) frame 10
> #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at tclthread.c:834
> 834 (void) Ns_TclEval(dsPtr, argPtr->server, argPtr->script);
> (gdb) frame 9
> #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0,
> server=<optimized out>,
> script=script@entry=0x9fb2884 "\n # If necessary due to
> running this code in a different environment, you\n # can have
> the newly spawned worker thread first source this file here.\n
> tst_cond_worker\n ") at tclinit.c:334
> 334 if (Tcl_EvalEx(interp, script, -1, 0) != TCL_OK) {
> (gdb) frame 8
> #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 7
> #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 6
> #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 5
> #5 0x00002b8bd68a427b in TclObjInterpProcCore () from
> /usr/lib/libtcl8.5.so.0
> (gdb) frame 4
> #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 3
> #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) frame 2
> #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd
> (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3,
> objv=0xa060c38)
> at tclvar.c:669
> 669 arrayPtr = LockArrayObj(interp, objv[2], 0);
> (gdb) frame 1
> #1 0x00002b8bd5f569ed in LockArrayObj (interp=interp@entry=0xa0022a0,
> arrayObj=0xa05a8b0, create=create@entry=0) at tclvar.c:1265
> 1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock));
> (gdb) frame 0
> #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239
> 239 mutexPtr = GETMUTEX(mutex);
> (gdb) list
> 234 Ns_GetTime(&startTime);
> 235 #endif
> 236
> 237 assert(mutex != NULL);
> 238
> 239 mutexPtr = GETMUTEX(mutex);
> 240 if (unlikely(!NsLockTry(mutexPtr->lock))) {
> 241 NsLockSet(mutexPtr->lock);
> 242 ++mutexPtr->nbusy;
> 243
> (gdb)
>
>
> ------------------------------------------------------------------------------
> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria
|
|
From: David O. <da...@qc...> - 2015-02-27 16:52:34
|
Hi, We're looking at doing a build of Naviserver tagged as 4.99.7. But we seem to be hitting an intermittent seg fault or bus error during the "make test". Sometimes the tests complete cleanly. It's often while running ns_conn.test, usually it PASSED ns_conn-1.2 then crashes. This is on a Debian 7.8 server. Built by doing: ./autogen.sh --with-tcl=/usr/lib/tcl8.5 ./configure --with-tcl=/usr/lib/tcl8.5 --prefix=/usr/local/ns --enable-symbols --enable-threads make make test I have core dumps. There's a backtrace at the end of the bus error (but gdb isn't my area so apologies if there's nothing useful in there). Is this anything of concern? -- David Qcode Software Limited http://www.qcode.co.uk Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `./nsd/nsd -u root -c -d -t /root/naviserver/tests/test.nscfg /root/naviserver/t'. Program terminated with signal 7, Bus error. #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239 239 mutexPtr = GETMUTEX(mutex); (gdb) info threads Id Target Id Frame 18 Thread 0x2b8bd7b5f700 (LWP 7173) 0x00002b8bd685b5f2 in Tcl_ExternalToUtfDString () from /usr/lib/libtcl8.5.so.0 17 Thread 0x2b8bdc580700 (LWP 7192) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 16 Thread 0x2b8bdc37f700 (LWP 7189) 0x00002b8bd7075d13 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87 15 Thread 0x2b8bdc17e700 (LWP 7188) 0x00002b8bd7075d13 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87 14 Thread 0x2b8bdbf7d700 (LWP 7187) 0x00002b8bd7075d13 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87 13 Thread 0x2b8bdbd7c700 (LWP 7186) 0x00002b8bd7075d13 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87 12 Thread 0x2b8bdbb7b700 (LWP 7185) 0x00002b8bd7075d13 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87 11 Thread 0x2b8bdb97a700 (LWP 7184) 0x00002b8bd7075d13 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=30000) at ../sysdeps/unix/sysv/linux/poll.c:87 10 Thread 0x2b8bdb779700 (LWP 7183) 0x00002b8bd7075d13 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=10000) at ../sysdeps/unix/sysv/linux/poll.c:87 9 Thread 0x2b8bdb578700 (LWP 7182) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 8 Thread 0x2b8bdb377700 (LWP 7181) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 7 Thread 0x2b8bdb176700 (LWP 7180) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 6 Thread 0x2b8bdaf75700 (LWP 7179) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 5 Thread 0x2b8bdad74700 (LWP 7178) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 4 Thread 0x2b8bda567700 (LWP 7177) pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:216 3 Thread 0x2b8bd7ed7700 (LWP 7174) 0x00002b8bd707a453 in select () at ../sysdeps/unix/syscall-template.S:82 2 Thread 0x2b8bd77522e0 (LWP 7172) do_sigwait (set=0x7fff74ac2f50, sig=0x7fff74ac2f4c) at ../nptl/sysdeps/unix/sysv/linux/../../../../../sysdeps/unix/sysv/linux/sigwait.c:65 * 1 Thread 0x2b8bdcba2700 (LWP 7196) Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239 (gdb) bt #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239 #1 0x00002b8bd5f569ed in LockArrayObj (interp=interp@entry=0xa0022a0, arrayObj=0xa05a8b0, create=create@entry=0) at tclvar.c:1265 #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3, objv=0xa060c38) at tclvar.c:669 #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0 #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0 #5 0x00002b8bd68a427b in TclObjInterpProcCore () from /usr/lib/libtcl8.5.so.0 #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0 #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0 #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0 #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0, server=<optimized out>, script=script@entry=0x9fb2884 "\n # If necessary due to running this code in a different environment, you\n # can have the newly spawned worker thread first source this file here.\n tst_cond_worker\n ") at tclinit.c:334 #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at tclthread.c:834 #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at thread.c:227 #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at pthread.c:809 #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #14 0x00002b8bd708095d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #15 0x0000000000000000 in ?? () (gdb) frame 15 #15 0x0000000000000000 in ?? () (gdb) frame 14 #14 0x00002b8bd708095d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 112 in ../sysdeps/unix/sysv/linux/x86_64/clone.S (gdb) frame 13 #13 0x00002b8bd753bb50 in start_thread (arg=<optimized out>) at pthread_create.c:304 304 pthread_create.c: No such file or directory. (gdb) frame 12 #12 0x00002b8bd65e9839 in ThreadMain (arg=<optimized out>) at pthread.c:809 809 NsThreadMain(arg); (gdb) frame 11 #11 0x00002b8bd65e884c in NsThreadMain (arg=<optimized out>) at thread.c:227 227 (*thrPtr->proc) (thrPtr->arg); (gdb) frame 10 #10 0x00002b8bd5f54073 in NsTclThread (arg=0x9fb2870) at tclthread.c:834 834 (void) Ns_TclEval(dsPtr, argPtr->server, argPtr->script); (gdb) frame 9 #9 0x00002b8bd5f431cb in Ns_TclEval (dsPtr=dsPtr@entry=0x0, server=<optimized out>, script=script@entry=0x9fb2884 "\n # If necessary due to running this code in a different environment, you\n # can have the newly spawned worker thread first source this file here.\n tst_cond_worker\n ") at tclinit.c:334 334 if (Tcl_EvalEx(interp, script, -1, 0) != TCL_OK) { (gdb) frame 8 #8 0x00002b8bd6820546 in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0 (gdb) frame 7 #7 0x00002b8bd68209f5 in ?? () from /usr/lib/libtcl8.5.so.0 (gdb) frame 6 #6 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0 (gdb) frame 5 #5 0x00002b8bd68a427b in TclObjInterpProcCore () from /usr/lib/libtcl8.5.so.0 (gdb) frame 4 #4 0x00002b8bd68624be in ?? () from /usr/lib/libtcl8.5.so.0 (gdb) frame 3 #3 0x00002b8bd681fdbe in ?? () from /usr/lib/libtcl8.5.so.0 (gdb) frame 2 #2 0x00002b8bd5f55f7e in NsTclNsvArrayObjCmd (UNUSED_clientData=<optimized out>, interp=0xa0022a0, objc=3, objv=0xa060c38) at tclvar.c:669 669 arrayPtr = LockArrayObj(interp, objv[2], 0); (gdb) frame 1 #1 0x00002b8bd5f569ed in LockArrayObj (interp=interp@entry=0xa0022a0, arrayObj=0xa05a8b0, create=create@entry=0) at tclvar.c:1265 1265 Ns_MutexLock(&(arrayPtr->bucketPtr->lock)); (gdb) frame 0 #0 Ns_MutexLock (mutex=0x206c617665757274) at mutex.c:239 239 mutexPtr = GETMUTEX(mutex); (gdb) list 234 Ns_GetTime(&startTime); 235 #endif 236 237 assert(mutex != NULL); 238 239 mutexPtr = GETMUTEX(mutex); 240 if (unlikely(!NsLockTry(mutexPtr->lock))) { 241 NsLockSet(mutexPtr->lock); 242 ++mutexPtr->nbusy; 243 (gdb) |
|
From: Gustaf N. <ne...@wu...> - 2015-02-23 20:10:16
|
Dear all, There is as well a new NaviServer (Tcl only) module for WebSockets available. This new module implements a WebSocket interface based on the new ns_connchan interface and supports both ws:// (WebSocket over http) and wss:// (WebSocket over https, requires the nsssl module). The module contains a simple API and two sample WebSocket applications (chat and a logfile watcher for e.g error.log and access.log). These sample applications can be activated/instantiated/configured via the configuration file (see below [2] for a screen shot). For details and configuration, see the README file of the module at [1] all the best -gn [1] https://bitbucket.org/naviserver/websocket [2] http://openacs.org/xowiki/download/file/websocket-log-viewer.png |
|
From: Gustaf N. <ne...@wu...> - 2015-02-23 19:51:05
|
Dear all, There is as well a new NaviServer (Tcl only) module for WebSockets available. This new module implements a WebSocket interface based on the new ns_connchan interface and supports both ws:// (WebSocket over http) and wss:// (WebSocket over https, requires the nsssl module). The module contains a simple API and two sample WebSocket applications (chat and a logfile watcher for e.g error.log and access.log). These sample applications can be activated/instantiated/configured via the configuration file (see below for a screen shot). For details and configuration, see the README file of the module at https://bitbucket.org/naviserver/websocket all the best -gn |
14 messages has been excluded from this view by a project administrator.
