naviserver-devel — Developer discussion

Re: [naviserver-devel] Windows Service startup fails

[Andrew P. <at...@pi...>]

On Tue, Oct 21, 2014 at 03:22:59PM -0400, Andrew Piskorski wrote:

>     return Ns_Main(argc, argv, ServerInit); 
> 
> But where does that ServerInit thing come from?  And why is it NULL
> when running as a Windows Service, but ok when Naviserver is started
> interactively?

Ah, I see:  ServiceMain() explicitly passes in a NULL initProc:

  Ns_Main((int)argc, argv, NULL);

So, is it supposed to be passing in something else, or is it ok for
that to be NULL and the assertion is inappropriate in this case?
Where are these initProc pointers supposed to come from?  Are we
missing a call to NsRegisterServerInit() somewhere?

Is there a document somewhere explaining the design of Naviserver's
virtual servers, what they're for and how the code underneath sets
them up?  Maybe in an older email?

So far I found this thread, which gives some hints but not a full
explanation:

  http://www.mail-archive.com/naviserver-devel%40lists.sourceforge.net/msg01707.html
  Re: [naviserver-devel] Explanation of last changes
  Vlad Seryakov Thu, 07 Sep 2006 12:38:46 -0700

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Windows Service startup fails

[Andrew P. <at...@pi...>]

On Mon, Oct 20, 2014 at 10:12:47PM -0400, Andrew Piskorski wrote:

>   Fatal: nsmain: no such server 'w7-1-prod'
> 
> But, that is the correct server name from my config file, and it works
> fine when I'm not running as a Windows Service!  I'm confused, what
> could cause it to fail ONLY when running as a Windows Service?

Ok, after further debugging, that particular problem was my fault, but
there are others.

In my config file, I decide whether to set up the "dev" or "prod"
server based on a regexp of the full path of the config file (from
"ns_info config").  And that path now has backslashes, not the
forward slashes expected by my regexp (which worked in the past).

So likely I installed this Naviserver service with a command line
using backslashes, while for AOLserver I used forward slashes.
Whatever, clearly that was a bug in my config file, it needs to be
robust to that sort of thing.

Now with that fixed, the service startup gets farther, and instead
fails in NsInitServer with:

  Assertion failed!
  File: server.c
  Line: 220
  Expression:  initProc != NULL

That confuses me.  because NsInitServer is only called from two
places, both of them right next to each other in Ns_Main.  So that
assertion must mean that the initProc being passed into Ns_Main is
NULL, which is only called from main, like so:

    return Ns_Main(argc, argv, ServerInit); 

But where does that ServerInit thing come from?  And why is it NULL
when running as a Windows Service, but ok when Naviserver is started
interactively?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Windows Service startup fails

[Andrew P. <at...@pi...>]

On Mon, Oct 20, 2014 at 04:07:09PM -0400, Andrew Piskorski wrote:

> Nothing at all gets written to the log file, so I'm not sure how to
> debug this.  But presumably that means something is dying very early,
> perhaps in NsConnectService()?

Briefly, I managed to the nsd Windows Service to start under the
WinDbg debugger.  There, it clearly emits a few ns_log lines I have in
my config file, and then says:

  Fatal: nsmain: no such server 'w7-1-prod'

But, that is the correct server name from my config file, and it works
fine when I'm not running as a Windows Service!  I'm confused, what
could cause it to fail ONLY when running as a Windows Service?

Additional gory detail:

After much googling, I found and followed the (rather tedious)
instructions in both of these pages:

  http://support.microsoft.com/kb/824344
  http://ww2.ntrglobal.com/support/why-do-i-get-error-message-regarding-interactive-services

That let me attach the WinDbg debugger to the Service.  The key bits
to set that up were:

- Run "C:\Program Files\Debugging Tools for Windows (x64)\gflags.exe",
  configure "nsd.exe" to use this debugger:
  "C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe" 

- Run regedit, and increase the millisecond counter for
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout
  to an hour or so.

- In Services, for my NaviServer service, under Log On, Local System
  account, TURN ON the "Allow service to interact with desktop" check box.

- Reboot Windows.

- Manually start up the "Interactive Service Detection" service BEFORE
  trying to start the NaviServer service.

With that, when I start the service an icon starts blinking on the
bottom Windows tool bar.  Clicking on it pops up a special dialog box,
"Interactive Services Detection", and clicking "View the Message" then
takes me to a weird separate Windows desktop (under a different user,
but no icons or start menu).

There the nsd.exe service is running under WinDbg, and this is the
only place I ever see the "Fatal: nsmain: no such server" message.

After the "no such server" message prints out, it seems nsd.exe has
already exited, because the backtrace in WinDbg says I am in function:
  wow64cpu!TurboDispatchJumpAddressEnd
Which ultimately was called by:
  ntdll!LdrInitializeThunk 

If I set a breakpoint on Ns_Fatal or Ns_SetFind, I can get it to stop
with actual Naviserver code on the stack.  WinDbg's "~" (threads) and
"|" (process) commands show 5 threads, only the first one of which
seems to be doing much of anything.

Oddly, the Ns_Main function does NOT appear on the stack trace, only
main, which can't be correct because the only thing main does is call
Ns_Main.  I can't seem to get WinDbg to examine most of the
interesting Ns_Main or NsConnectService code.  Possibly because:

  "Stack unwind information not available. Following frames may be wrong."

That I don't understand, because I compiled with /Zi "complete
debugging information", and have all the *.pdb files in my lib
directory, d which I put onto WinDbg's symbol path and told it to
"reload".

Odlly, WinDbg knows the correct line number for "nsd!main" in
nsd/main.c, but claims it does not have any symbol info for
Ns_SetFind.  I can get it to stop at a Ns_SetFind breakpoint, but
can't seem to see anything of use.

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] Windows Service startup fails

[Andrew P. <at...@pi...>]

Is anyone running Naviserver as a Windows service?

That always worked fine for me with AOLserver.  With Naviserver,
installing the service works fine.  (Just make sure your Command
Prompt has Administrator privileges when you do the service install
with -I).  But when I actually start the service, it IMMEDIATELY fails
with:

  Error 1053: The service did not respond to the start or control
  request in timely fashion.

  A timeout was reached (30000 milliseconds) while waiting for the
  NaviServer service to connect.

Note, it does NOT try for 30 seconds first.  When I click "Start", I
id immediately gives me the "Error 1053" pop-up box, and posts the
"timeout was reached" error to the Windows Event Log.

Nothing at all gets written to the log file, so I'm not sure how to
debug this.  But presumably that means something is dying very early,
perhaps in NsConnectService()?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] ns_cond vs Tcl event loop?

[Zoran V. <zv...@ar...>]

Hi!

Actually, this is what Tcl Thread extension is
doing by parking the thread onto event loop and
responding to messages (scriptlets) being posted
there. This is far easier to understand for most
users who never programmed the “hard” way with
condvar/mutex.

Cheers,
Zoran

On 20 Oct 2014, at 18:49, Andrew Piskorski <at...@pi...> wrote:

> Although the C version of ns_cond is used in various places in
> Naviserver itself, clearly very few people actually use the Tcl
> ns_cond command.  I have ns_cond working nicely for my needs and so
> don't plan to change anytime soon, but I do wonder:
> 
> Is there a higher-level, more Tcl'ish way to accomplish the same thing
> (waking up another thread) as ns_cond these days?  Perhaps something
> with the Tcl event loop?  Or some other form of message passing?
> 
> I expect that ns_cond will be more efficient, since it a thin layer over
> the POSIX C API, but it is tricky enough to use correctly that a more
> user-friendly alternative could be nice when doing general-purpose
> multi-threaded programming in Tcl.
> 
> Of course, part of the beauty of Naviserver and AOLserver is that you
> rarely need to DO general-purpose multi-threaded programming, because
> they're already set up for the typical concurrency needs of a web
> server.  But it is very nice that they (and the Tcl Threads Extension)
> have the tools available when you need to do something different.
> 
> -- 
> Andrew Piskorski <at...@pi...>
> 
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] sometimes crashes on shutdown

[Andrew P. <at...@pi...>]

On Sat, Oct 18, 2014 at 01:54:22PM +0200, Gustaf Neumann wrote:

> My understanding is that it happens due to varying deletion orders
> during shutdown, probably influenced by the traversal order in hash
> tables. Hard to debug, but for practical applications without much
> value.

Good to know.  Also, I've read that Tcl 8.6 has simplified its process
exit code, so with luck this will get easier to debug in the future.

Btw, is anybody running Naviserver with Tcl 8.6 yet?

I was going to try it (on Windows), but noticed that unlike the
earlier versions, ActiveTcl 8.6 ships with almost no add-on packages,
not even tcllib.

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] ns_cond vs Tcl event loop?

[Andrew P. <at...@pi...>]

Although the C version of ns_cond is used in various places in
Naviserver itself, clearly very few people actually use the Tcl
ns_cond command.  I have ns_cond working nicely for my needs and so
don't plan to change anytime soon, but I do wonder:

Is there a higher-level, more Tcl'ish way to accomplish the same thing
(waking up another thread) as ns_cond these days?  Perhaps something
with the Tcl event loop?  Or some other form of message passing?

I expect that ns_cond will be more efficient, since it a thin layer over
the POSIX C API, but it is tricky enough to use correctly that a more
user-friendly alternative could be nice when doing general-purpose
multi-threaded programming in Tcl.

Of course, part of the beauty of Naviserver and AOLserver is that you
rarely need to DO general-purpose multi-threaded programming, because
they're already set up for the typical concurrency needs of a web
server.  But it is very nice that they (and the Tcl Threads Extension)
have the tools available when you need to do something different.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] ns_cond is broken on Naviserver

[Andrew P. <at...@pi...>]

On Sat, Oct 18, 2014 at 01:56:10PM +0200, Gustaf Neumann wrote:

> Dear Andrew, i have fixed the problem in the head branch. Your test is 
> working for me, at least under Mac OS X and Linux.

Excellent, thank you, Gustaf!  I confirm that ns_cond now works on
both Linux and Windows.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] ns_cond is broken on Naviserver

[Gustaf N. <ne...@wu...>]

Am 18.10.14 11:34, schrieb Andrew Piskorski:
> I tried to bisect, but getting old versions of Naviserver to actually
> build and run tests is extraordinarily frustrating.  I gave up.
Dear Andrew, i have fixed the problem in the head branch. Your test is 
working for
me, at least under Mac OS X and Linux.

-g

Re: [naviserver-devel] sometimes crashes on shutdown

[Gustaf N. <ne...@wu...>]

Am 18.10.14 11:45, schrieb Andrew Piskorski:
> Btw, simply running all the tests with "make test" sometimes crashes
> Naviserver while it is shutting down; see below.
Dear Andrew,

this is a known problem (see e.g. [1]) which is not nice but not 
serious, since it happens
very late in the shutdown. My understanding is that it happens due to 
varying deletion orders
during shutdown, probably influenced by the traversal order in hash 
tables. Hard to debug,
but for practical applications without much value.

-g

https://www.mail-archive.com/nav...@li.../msg02948.html

[naviserver-devel] sometimes crashes on shutdown

[Andrew P. <at...@pi...>]

Btw, simply running all the tests with "make test" sometimes crashes
Naviserver while it is shutting down; see below.

Or just running this one test (which is fast) several times works
pretty well for triggering a crash.  Other tests do it too though, not
just this one:

  make test TCLTESTARGS='-file ns_nsv.test'


[18/Oct/2014:05:27:59][18593.2ac57b648240][-main-] Notice: nsmain: NaviServer/4.99.6 stopping
[18/Oct/2014:05:27:59][18593.2ac57b648240][-main-] Notice: [driver:nssock]: stopping
[18/Oct/2014:05:27:59][18593.2ac57b648240][-main-] Notice: server [test]: stopping
[18/Oct/2014:05:27:59][18593.2ac57b648240][-main-] Notice: server [testvhost]: stopping
[18/Oct/2014:05:27:59][18593.2ac57b648240][-main-] Notice: server [testvhost2]: stopping
[18/Oct/2014:05:27:59][18593.2ac5a4200700][-driver:nssock-] Notice: exiting
[18/Oct/2014:05:27:59][18593.2ac588c10700][-conn:test:1] Notice: exiting: shutdown pending
[18/Oct/2014:05:27:59][18593.2ac588e11700][-conn:testvhost:0] Notice: exiting: shutdown pending
[18/Oct/2014:05:27:59][18593.2ac589012700][-conn:testvhost2:0] Notice: exiting: shutdown pending
[18/Oct/2014:05:27:59][18593.2ac588a0f700][-conn:test:0] Notice: exiting: shutdown pending
[18/Oct/2014:05:27:59][18593.2ac58880e700][-conn:test:emergency:0] Notice: exiting: shutdown pending
called Tcl_FindHashEntry on deleted table
Aborted (core dumped)
make: *** [test] Error 134


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 /usr/local/web/ns-fork/nv-tcl85-linux/tests/test.nsc'.
Program terminated with signal 6, Aborted.
(gdb) bt
#0  0x00002ac57a22d425 in __GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00002ac57a230b8b in __GI_abort () at abort.c:91
#2  0x00002ac57acb634e in Tcl_PanicVA () from /usr/lib/libtcl8.5.so.0
#3  0x00002ac57acb640c in Tcl_Panic () from /usr/lib/libtcl8.5.so.0
#4  0x00002ac57ac8e079 in ?? () from /usr/lib/libtcl8.5.so.0
#5  0x00002ac57acd12fa in ?? () from /usr/lib/libtcl8.5.so.0
#6  0x00002ac57accff5e in Tcl_GetThreadData () from /usr/lib/libtcl8.5.so.0
#7  0x00002ac57acb3cfa in TclFreeObj () from /usr/lib/libtcl8.5.so.0
#8  0x00002ac57acb5d45 in ?? () from /usr/lib/libtcl8.5.so.0
#9  0x00002ac57ac8db82 in Tcl_DeleteHashTable () from /usr/lib/libtcl8.5.so.0
#10 0x00002ac57ac730b8 in ?? () from /usr/lib/libtcl8.5.so.0
#11 0x00002ac57acb3d59 in TclFreeObj () from /usr/lib/libtcl8.5.so.0
#12 0x00002ac57acb222d in ?? () from /usr/lib/libtcl8.5.so.0
#13 0x00002ac57ac3b995 in Tcl_DeleteCommandFromToken ()
   from /usr/lib/libtcl8.5.so.0
#14 0x00002ac57acac0dc in TclTeardownNamespace () from /usr/lib/libtcl8.5.so.0
#15 0x00002ac57ac3a3dc in ?? () from /usr/lib/libtcl8.5.so.0
#16 0x00002ac579f9062e in DeleteInterps (arg=0x20be470) at tclinit.c:1861
#17 0x00002ac57aa0c814 in NsCleanupTls (slots=0x31ac220) at tls.c:186
#18 0x00002ac57aa0d16a in CleanupTls (arg=<optimized out>) at pthread.c:816
#19 0x00002ac57b135c83 in __nptl_deallocate_tsd () at pthread_create.c:156
#20 0x00002ac57b135ea8 in start_thread (arg=0x2ac58880e700)
    at pthread_create.c:315
#21 0x00002ac57a2eb3fd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#22 0x0000000000000000 in ?? ()
(gdb) 

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] ns_cond is broken on Naviserver

[Andrew P. <at...@pi...>]

I tried to bisect, but getting old versions of Naviserver to actually
build and run tests is extraordinarily frustrating.  I gave up.

I see various places where Naviserver itself uses the Ns_Cond* C
functions, which makes me think they likely work.  Also, the Unix and
Windows C implementations are in two different files.  Since the
problems I see with Tcl ns_cond are the same on Linux and Windows,
perhaps the problem is in nsd/tclthread.c, which is cross-platform.

Most of NsTclCondObjCmd() dates from 2005-10-21, when Stephen Deasey
pretty much completely rewrote it.  Maybe that's a likely place for
bugs?  I wasn't able to build or test the code from around then
though, so it's just an arbitrary guess on my part.

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] ns_cond is broken on Naviserver

[Andrew P. <at...@pi...>]

I added a test of correct ns_cond behavior here:
  https://bitbucket.org/apiskors/naviserver/commits/2ed58b6a9c0567fe7cbee1080e30274b2aba64be

Which adds these two new files:
  tests/ns_cond.test
  tests/testserver/modules/ns_cond.tcl 

To run the test on Linux, just do:
  make test TCLTESTARGS='-file ns_cond.test' 

As you can see from the log output below, ns_cond works fine on
AOLserver, but not on Naviserver.  On Naviserver, once the worker
thread calls "ns_cond wait" the first time, it just never wakes up.
It's as if the cond signal just never makes it here.  This was run on
Linux; behavior on Windows is the same.


# BUG on Naviserver, the worker never wakes up:
ns_cond.test
[18/Oct/2014:02:34:50][23566.2aadb6049700][-command-] Notice: tst_cond_master: New thread '' started for running tst_cond_worker.
[18/Oct/2014:02:34:50][23566.2aae0c401700][-thread:2aae0c401700-] Notice: tst_cond_worker: 2 work items:  0 1
[18/Oct/2014:02:34:54][23566.2aadb6049700][-command-] Notice: tst_cond_master: 2 work items done:  0 1
[18/Oct/2014:02:34:54][23566.2aadb6049700][-command-] Notice: tst_cond_master: 3 work items NOT done:  2 3 4
==== ns_cond-1.1 Master uses ns_cond to wake up a worker thread. FAILED

# Correct behavior on AOLserver 4.0.10:
[18/Oct/2014:02:32:38][16918.18446744071699884032][-conn:outpost-dev::0] Notice: tst_cond_master: New thread '' started for running tst_cond_worker.
[18/Oct/2014:02:32:38][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: 2 work items:  0 1
[18/Oct/2014:02:32:39][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: Event 'eid0x7fb97ca16600' - got it.
[18/Oct/2014:02:32:39][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: 1 work items:  2
[18/Oct/2014:02:32:40][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: Event 'eid0x7fb97ca16600' - got it.
[18/Oct/2014:02:32:40][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: 1 work items:  3
[18/Oct/2014:02:32:41][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: Event 'eid0x7fb97ca16600' - got it.
[18/Oct/2014:02:32:41][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: 1 work items:  4
[18/Oct/2014:02:32:42][16918.18446744071699884032][-conn:outpost-dev::0] Notice: tst_cond_master: 5 work items done:  0 1 2 3 4
[18/Oct/2014:02:32:42][16918.18446744071699884032][-conn:outpost-dev::0] Notice: tst_cond_master: 0 work items NOT done:  
[18/Oct/2014:02:32:42][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: Event 'eid0x7fb97ca16600' - got it.
[18/Oct/2014:02:32:42][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: 0 work items:  
[18/Oct/2014:02:32:42][16918.18446744071622727680][-thread-2086823936-] Notice: tst_cond_worker: No more work for me today.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Andrew P. <at...@pi...>]

On Thu, Oct 16, 2014 at 08:14:09AM +0200, Gustaf Neumann wrote:

> i can look into the issue, but i am right now quite busy. For what purpose
> do you need nsthreadtest? is out of curiosity, do you want to check, if
> "everything works", or is there an application need?

I only care about nsthreadtest in order to debug the Naviserver code.
Now nsthreadtest is working on all the combinations of platform and
versionf of Tcl I tried, great.

Unfortunately, nsd itself has some problems.

In my very limited testing, nsd linked with Tcl 8.5 appears to run
mostly ok on both Linux and Windows.  However, at least on Windows, it
has buggy behavior - ns_cond silently does nothing.  I have no idea
why.  I haven't tested yet whether Linux has the same problem.

Linked with Tcl 8.4, nsd immediately crashes on startup, on both Linux
(backtrace below) and Windows.  This surprises me...  Any ideas?  Does
this suggest some sort of incorrect linking in my build, or a bug
somewhere in the Naviserver code?

Has anybody actually been using Tcl 8.4 with Naviserver lately?
Staring it up with "nsd -c" threw a whole bunch Tcl errors because the
"namespace ensemble" command only exists in Tcl 8.5, not 8.4.  I fixed
that here:

  https://bitbucket.org/apiskors/naviserver/history-node/bfbb7d1dcfa5/tcl/nstrace.tcl


warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/nsd-t84-atp-1/bin/nsd -f -t /usr/local/nsd-t84-atp-1/conf/nsd-config'.
Program terminated with signal 6, Aborted.
#0  0x00007fc8e754f425 in __GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fc8e754f425 in __GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fc8e7552b8b in __GI_abort () at abort.c:91
#2  0x00007fc8e791c4d9 in Panic (fmt=<optimized out>) at log.c:616
#3  0x00007fc8e6c7129d in Tcl_PanicVA () from /usr/lib/libtcl8.4.so.0
#4  0x00007fc8e6c71409 in Tcl_Panic () from /usr/lib/libtcl8.4.so.0
#5  <signal handler called>
#6  0x00007fc8e6c54b89 in Tcl_CreateHashEntry () from /usr/lib/libtcl8.4.so.0
#7  0x00007fc8e7934382 in Ns_TclDestroyInterp (interp=0x1453730)
    at tclinit.c:521
#8  0x00007fc8e790b3ac in NsConfigEval (
    config=0x146b160 "#set", ' ' <repeats 13 times>, "home", ' ' <repeats 16 times>, "/usr/local/ns\nset", ' ' <repeats 13 times>, "home", ' ' <repeats 16 times>, "[file dirname [file dirname [info nameofexecutable]]]\n\nns_section     \"ns/server/default/modules\"\nns_param       "..., argc=4, 
    argv=<optimized out>, optind=4) at config.c:717
#9  0x00007fc8e791e8ac in Ns_Main (argc=4, argv=0x7fff4d205348, 
    initProc=0x400750 <ServerInit>) at nsmain.c:449
#10 0x00007fc8e753a76d in __libc_start_main (main=0x400660 <main>, argc=4, 
    ubp_av=0x7fff4d205348, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fff4d205338) at libc-start.c:226
#11 0x0000000000400695 in _start ()
(gdb) 

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Andrew P. <at...@pi...>]

On Thu, Oct 16, 2014 at 09:53:15AM +0200, Gustaf Neumann wrote:
> Am 16.10.14 08:14, schrieb Gustaf Neumann:
> > i can look into the issue, ...
> nevermind, fixed on tip. The problem was missing tcl initialization 
> (required in Tcl 8.5)

So it just needed a call to Tcl_FindExecutable()!  The Tcl docs aren't
very clear on that, but the comments in the Tcl source code are very
clear that you must call it.  Good to know.

Gustaf, I just merged in all your fixes, and now nsthreadtest runs to
completion for me on both Linux and Windows, and with Tcl 8.4 and 8.5.
So nsthreadtest looks good now.


https://bitbucket.org/naviserver/naviserver/commits/72b9fbac08d60479328ded73afd668faa993da70

http://tcl.activestate.com/man/tcl8.5/TclLib/FindExec.htm
 
tcl-core-8-5-branch/win/tclWin32Dll.c 

* The three NULL function pointers will only be set when 
* Tcl_FindExecutable is called. If you don't ever call that function, the 
* application will crash whenever WinTcl tries to call functions through 
* these null pointers. That is not a bug in Tcl - Tcl_FindExecutable is 
* mandatory in recent Tcl releases. 

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Gustaf N. <ne...@wu...>]

Am 16.10.14 08:14, schrieb Gustaf Neumann:
> i can look into the issue, ...
nevermind, fixed on tip. The problem was missing tcl initialization 
(required in Tcl 8.5)

-g

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Gustaf N. <ne...@wu...>]

Am 16.10.14 04:06, schrieb Andrew Piskorski:
> Good idea.  The automatic bisect didn't give me the answer, but it did
> get me started down a useful path.  The culprit with nsthreadtest
> seems to be, Tcl 8.5!
That's would have been my first guess, since (a) nsthreadtest is not in 
regular use,
and (b) there are some internal differences in Tcl concerning the 
initialization between
8.4 and 8.5.

i can look into the issue, but i am right now quite busy. For what purpose
do you need nsthreadtest? is out of curiosity, do you want to check, if
"everything works", or is there an application need?
-g

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Andrew P. <at...@pi...>]

On Wed, Oct 15, 2014 at 10:06:48PM -0400, Andrew Piskorski wrote:

> All that seems to matter, is that nsthreadtest ALWAYS fails when I
> configured with this:
>   --with-tcl=/usr/lib/tcl8.5
> And if I instead use Tcl 8.4 like this it works fine:
>   --with-tcl=/usr/lib/tcl8.4

I Compared the config.log files from those two cases.  There are a
bunch of differences in th egiant TCL_DEFS string.

But for the C-level build stuff, the only non-obvious looking
difference are these:

TCL_VERSION='8.4' 
TCL_EXTRA_CFLAGS='-g -O2 -fno-unit-at-a-time -pipe ' 
TCL_LD_FLAGS='-Wl,-Bsymbolic-functions -Wl,--export-dynamic' 
 
TCL_VERSION='8.5' 
TCL_EXTRA_CFLAGS='-g -O2 -fno-unit-at-a-time -pipe -D_FORTIFY_SOURCE=2' 
TCL_LD_FLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--export-dynamic ' 

So 8.5 adds two options not present with 8.4, but I'm not sure if
either of these actually get used by Naviserver:

  -D_FORTIFY_SOURCE=2

  -Wl,-z,relro : Create an ELF "PT_GNU_RELRO" segment header in the object.

Both use -O2, and I suspect they both may be effectively getting
-D_FORTIFY_SOURCE=2 as well, because 'man gcc' says it's the default
when using -O2:

  NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2 is set by
  default, and is activated when -O is set to 2 or higher.  This enables
  additional compile-time and run-time checks for several libc functions.
  To disable, specify either -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0.

  $ gcc --version
  gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

The relro linker option is also for robustness/security:

  https://wiki.ubuntu.com/Security/Features#relro

  Built with RELRO

  Hardens ELF programs against loader memory area overwrites by having
  the loader mark any areas of the relocation table as read-only for any
  symbols resolved at load-time ("read-only relocations"). This reduces
  the area of possible GOT-overwrite-style memory corruption attacks.

I don't think the relro flag from Tcl actually gets used anywhere in Naviserver.

Just in case, I rebuilt with Tcl 8.5 and -D_FORTIFY_SOURCE= 1 and 0,
but nsthreadtest still crashed in both cases.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Andrew P. <at...@pi...>]

On Wed, Oct 15, 2014 at 10:24:19PM +0100, Stephen wrote:

> You have a known good revision: aolserver-4.0.10, a known bad: tip,
> and an automated test to distinguish between the two states:
> nsthreadtest. Try 'hg bisect ...' to figure out where the error was
> introduced.

Good idea.  The automatic bisect didn't give me the answer, but it did
get me started down a useful path.  The culprit with nsthreadtest
seems to be, Tcl 8.5!

I typically generate and run the configure script like this:

   AUTOCONF=autoconf2.50 ./autogen.sh --prefix=$inst_dir --enable-symbols --enable-rpath --with-tcl=/usr/lib/tcl8.5 --with-zlib=/usr/lib 

Turns out, it doesn't matter what version of the C code I use, and it
doesn't matter if I run autoconf from the tip or use the ancient
configure script from 2005 (which was deleted on 2005-10-09 in rev
1345:f6af29cbe4fb).

All that seems to matter, is that nsthreadtest ALWAYS fails when I
configured with this:
  --with-tcl=/usr/lib/tcl8.5
And if I instead use Tcl 8.4 like this it works fine:
  --with-tcl=/usr/lib/tcl8.4

I can imagine several possible causes for this:

- A bug in Tcl 8.5.
- A bug in how Naviserver uses Tcl 8.5.
- Some side effect of the configure process.
- A broken Tcl 8.5 on my machine(s).

Note that I see the very same sort of nsthreadtest failures on Windows 7.

I never run configure or autoconf on Windows.  Unfortunately there is
some crosstalk with Linux, because the Windows build uses some subset
of the stuff (via NFS) generated by Linux configure.  (That is
horribly ugly, but hasn't seemed to break anything so far and I
haven't gone back and tried to fix it yet.)

On Linux I am using the stock Tcl 8.4 and 8.5 included with Ubuntu
10.04.4 LTS.  On Windows 7 I am using ActiveTcl 8.4 and 8.5 (32-bit),
both installed into the same C:\P\tcl-32\ directory tree.

So, what could possibly be wrong here that shows itself by
nsthreadtest passing with Tcl 8.4, but crashing with 8.5?

Next, I rebuilt my 32-bit Naviserver on Windows with ActiveTcl 8.4,
and its nsthreadtest now passes too!  So Linux and Windows are
consistent, 8.4 nsthreadtest works, 8.5 fails.


Unfortunately, Linux and Windows are consistent in another way - on
both platforms, my new Tcl 8.4 Naviserver build fails in at least two
ways:

One, running Naviserver with the sample conf/nsd-config.tcl file dumps
core.  On Linux that happens while running in NsConfigEval(); the
backtrace is below.

Two, running "nsd -c" throws a Tcl backtrace:

  bad option "ensemble": must be children, code, current, delete, eval, exists, export, forget, import, inscope, origin, parent, qualifiers, tail, or which 
      while executing 
  "namespace ensemble exists $cmd" 

     invoked from within 
  "nstrace::statescript" 

I will try to debug these new 8.4 failures more tomorrow.


# Linux, Tcl 8.4, nsthreadtest passes but Naviserver fails like this:
warning: Can't read pathname for load map: Input/output error. 
[Thread debugging using libthread_db enabled] 
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 
Core was generated by `/usr/local/nsd-t84-atp-1/bin/nsd -f -t /usr/local/nsd-t84-atp-1/conf/nsd-config'. 
Program terminated with signal 6, Aborted. 
#0  0x00007fb77715d425 in __GI_raise (sig=<optimized out>) 
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. 
(gdb) bt 
#0  0x00007fb77715d425 in __GI_raise (sig=<optimized out>) 
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 
#1  0x00007fb777160b8b in __GI_abort () at abort.c:91 
#2  0x00007fb77752a4d9 in Panic (fmt=<optimized out>) at log.c:616 
#3  0x00007fb77687f29d in Tcl_PanicVA () from /usr/lib/libtcl8.4.so.0 
#4  0x00007fb77687f409 in Tcl_Panic () from /usr/lib/libtcl8.4.so.0 
#5  <signal handler called> 
#6  0x00007fb776862b89 in Tcl_CreateHashEntry () from /usr/lib/libtcl8.4.so.0 
#7  0x00007fb777542382 in Ns_TclDestroyInterp (interp=0x1497730) 
    at tclinit.c:521 
#8  0x00007fb7775193ac in NsConfigEval ( 
    config=0x14af160 "#set", ' ' <repeats 13 times>, "home", ' ' <repeats 16 times>, "/usr/local/ns\nset", ' ' <repeats 13 times>, "home", ' ' <repeats 16 times>, "[file dirname [file dirname [info nameofexec\
utable]]]\n\nns_section     \"ns/server/default/modules\"\nns_param       "..., argc=4,  
    argv=<optimized out>, optind=4) at config.c:717 
#9  0x00007fb77752c8ac in Ns_Main (argc=4, argv=0x7fff38339a18,  
    initProc=0x400750 <ServerInit>) at nsmain.c:449 
#10 0x00007fb77714876d in __libc_start_main (main=0x400660 <main>, argc=4,  
    ubp_av=0x7fff38339a18, init=<optimized out>, fini=<optimized out>,  
    rtld_fini=<optimized out>, stack_end=0x7fff38339a08) at libc-start.c:226 
#11 0x0000000000400695 in _start () 
(gdb)  

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Stephen <yo...@gr...>]

On Wed, Oct 15, 2014 at 8:24 PM, Andrew Piskorski <at...@pi...> wrote:
>
> On Wed, Oct 15, 2014 at 03:45:59AM -0400, Andrew Piskorski wrote:
>
> > In my own application on Windows, my connection thread tells a worker
> > thread to do something using nsv, mutexes, and a condition variable.
> >
> > This is old code that works fine on AOLserver 4.0.x (on a different
> > older Windows XP box), but now with Naviserver on Windows 7, the
> > worker thread seems to never wake up, and never do anything at all.
>
> There is definitely a real problem.  For debugging purposes in my
> application, I replaced that one use of ns_cond (there are others)
> with a simpler sleep-and-poll arrangement.  That works - the submit
> thread wakes up after sleeping, sees the data waiting for it in its
> nsv queue, and does its job.
>
> So I don't know what exactly, but something is seriously broken with
> ns_cond and/or ns_mutex in Naviserver, at least on Windows, possibly
> on Linux as well.
>
> Btw, for those who haven't used ns_cond before, it is a low-level
> wrapper around standard POSIX condition variable semantics.  By design
> it MUST be used in conjunction with ns_mutex.
>
> Thus I'm extra interested in the way nsthreadtest crashes, which I
> don't understand.  But failing feedback on that, next I'll probably
> try and write some simpler stand-alone Tcl code to reproduce the "My
> thread waiting on ns_cond never wakes up" behavior I'm seeing with
> Naviserver.

You have a known good revision: aolserver-4.0.10, a known bad: tip,
and an automated test to distinguish between the two states:
nsthreadtest. Try 'hg bisect ...' to figure out where the error was
introduced.

Re: [naviserver-devel] nsthreadtest fails on both Linux and Windows

[Andrew P. <at...@pi...>]

On Wed, Oct 15, 2014 at 03:45:59AM -0400, Andrew Piskorski wrote:

> In my own application on Windows, my connection thread tells a worker
> thread to do something using nsv, mutexes, and a condition variable.
> 
> This is old code that works fine on AOLserver 4.0.x (on a different
> older Windows XP box), but now with Naviserver on Windows 7, the
> worker thread seems to never wake up, and never do anything at all.

There is definitely a real problem.  For debugging purposes in my
application, I replaced that one use of ns_cond (there are others)
with a simpler sleep-and-poll arrangement.  That works - the submit
thread wakes up after sleeping, sees the data waiting for it in its
nsv queue, and does its job.

So I don't know what exactly, but something is seriously broken with
ns_cond and/or ns_mutex in Naviserver, at least on Windows, possibly
on Linux as well.

Btw, for those who haven't used ns_cond before, it is a low-level
wrapper around standard POSIX condition variable semantics.  By design
it MUST be used in conjunction with ns_mutex.

Thus I'm extra interested in the way nsthreadtest crashes, which I
don't understand.  But failing feedback on that, next I'll probably
try and write some simpler stand-alone Tcl code to reproduce the "My
thread waiting on ns_cond never wakes up" behavior I'm seeing with
Naviserver.

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] nsthreadtest fails on both Linux and Windows

[Andrew P. <at...@pi...>]

Is the stand-alone nsthreadtest program supposed to work?
It dumps core for me on both Windows and Linux.

In my own application on Windows, my connection thread tells a worker
thread to do something using nsv, mutexes, and a condition variable.

This is old code that works fine on AOLserver 4.0.x (on a different
older Windows XP box), but now with Naviserver on Windows 7, the
worker thread seems to never wake up, and never do anything at all.
I'm still in the middle of tracking down exactly what's going on
there, but it made me suspicious...

So I ran nsthreadtest, which crashed.  Output and stack traces are
below.  The output from the Linux and Windows runs is slightly
different, but they both appear to during (or after) "tls cleanup 1",
after calling Tcl_FinalizeThread().

Any ideas?

Btw, I tested two recent points in the commit history.  The current
head of my clone right after merging in all of Gustaf's latest
commits, here:

  https://bitbucket.org/apiskors/naviserver/commits/28b8eb8e7b126313e32e95fb9ba17d77a789d68a
  https://bitbucket.org/apiskors/naviserver/commits/all

And earlier today, my clone prior to merging in the last three days or
so of Gustaf's changes.  Unsurprisingly, they both failed exactly the
same way.


Windows 7 64-bit, Naviserver compiled 32-bit, run under WinDbg:
------------------------------------------------------------
[-main-][Wed Oct 15 01:40:19 2014]: sema initialized to 3
[-main-][Wed Oct 15 01:40:19 2014]: pid = 3332
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 0
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 1
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 2
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 3
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 4
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 5
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 6
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 7
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 8
[-main-][Wed Oct 15 01:40:19 2014]: starting work thread 9
[-work:0-][Wed Oct 15 01:40:19 2014]: rwlock read aquired
[-work:1-][Wed Oct 15 01:40:19 2014]: rwlock read aquired
[-main-][Wed Oct 15 01:40:20 2014]: sema post 10
[-work:1-][Wed Oct 15 01:40:20 2014]: enter critical section once
[-work:1-][Wed Oct 15 01:40:20 2014]: enter critical section twice
[-work:1-][Wed Oct 15 01:40:20 2014]: got semaphore posted from main
[-work:1-][Wed Oct 15 01:40:20 2014]: rwlock unlocked
[-work:1-][Wed Oct 15 01:40:20 2014]: exiting
[-work:1-][Wed Oct 15 01:40:20 2014]: tls cleanup 1

ChildEBP RetAddr  
WARNING: Frame IP not in any known module. Following frames may be wrong.
029cfaec 10086f57 0x0
029cfb10 10086efb tcl85!Tcl_GetMemoryInfo+0x747
029cfb18 1008601a tcl85!Tcl_GetMemoryInfo+0x6eb
029cfb20 10041abb tcl85!Tcl_GetThreadData+0x5a
029cfb2c 63d336e9 tcl85!Tcl_FinalizeThread+0xb
029cfb50 63d33d11 nsthread!NsCleanupTls+0xe9 [z:\web\ns-fork\naviserver\nsthread\tls.c @ 191]
029cfb68 63d3a7da nsthread!DllMain+0x101 [z:\web\ns-fork\naviserver\nsthread\winthread.c @ 183]
029cfbb4 63d3a701 nsthread!__DllMainCRTStartup+0xca [f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c @ 330]
029cfbc8 77c899a0 nsthread!_DllMainCRTStartup+0x21 [f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c @ 293]
029cfbe8 77ca7e5f ntdll32!LdrpCallInitRoutine+0x14
029cfc8c 77ca8046 ntdll32!LdrShutdownThread+0xe6
029cfc9c 63d3819a ntdll32!RtlExitUserThread+0x2a
029cfcac 63d344ec nsthread!_endthreadex+0x2a [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 367]
029cfcb8 00a414d9 nsthread!Ns_ThreadExit+0xc [z:\web\ns-fork\naviserver\nsthread\winthread.c @ 735]
029cfd2c 63d32dd6 nsthreadtest!WorkThread+0x2a9 [z:\web\ns-fork\naviserver\nsthread\nsthreadtest.c @ 209]
029cfd98 63d346fc nsthread!NsThreadMain+0x86 [z:\web\ns-fork\naviserver\nsthread\thread.c @ 219]
029cfdb0 63d38113 nsthread!ThreadMain+0x5c [z:\web\ns-fork\naviserver\nsthread\winthread.c @ 872]
029cfdec 63d380b4 nsthread!_callthreadstartex+0x53 [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 314]
029cfdf8 7746338a nsthread!_threadstartex+0x84 [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 297]
029cfe04 77c89f72 kernel32!BaseThreadInitThunk+0xe
029cfe44 77c89f45 ntdll32!__RtlUserThreadStart+0x70
029cfe5c 00000000 ntdll32!_RtlUserThreadStart+0x1b


Ubuntu 12.04.3 LTS, 64-bit, run normally, gdb on core file:
------------------------------------------------------------
$ /usr/local/nsd-4.99.6-dtk-2/bin/nsthreadtest
[-main-][Wed Oct 15 02:31:46 2014]: sema initialized to 3
[-main-][Wed Oct 15 02:31:46 2014]: pid = 15263
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 0
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 1
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 2
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 3
[-work:0-][Wed Oct 15 02:31:46 2014]: rwlock read aquired
[-work:1-][Wed Oct 15 02:31:46 2014]: rwlock read aquired
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 4
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 5
[-work:3-][Wed Oct 15 02:31:46 2014]: rwlock read aquired
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 6
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 7
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 8
[-main-][Wed Oct 15 02:31:46 2014]: starting work thread 9
	-work:9- -main- 7f06b0339700 0 1413354706 0x4022f0 0x9 15274
	-work:8- -main- 7f06b034d700 0 1413354706 0x4022f0 0x8 15273
	-work:7- -main- 7f06b0361700 0 1413354706 0x4022f0 0x7 15272
	-work:6- -main- 7f06b0375700 0 1413354706 0x4022f0 0x6 15271
	-work:5- -main- 7f06b0389700 0 1413354706 0x4022f0 0x5 15270
	-work:4- -main- 7f06b039d700 0 1413354706 0x4022f0 0x4 15269
	-work:3- -main- 7f06b03b1700 0 1413354706 0x4022f0 0x3 15268
	-work:2- -main- 7f06b03c5700 0 1413354706 0x4022f0 0x2 15267
	-work:1- -main- 7f06b03d9700 0 1413354706 0x4022f0 0x1 15266
	-work:0- -main- 7f06b03ff700 0 1413354706 0x4022f0 (nil) 15265
	-dumper- -main- 7f06af1e2700 0 1413354706 0x4028e0 (nil) 15264
	-main- {} 7f06b03db700 1 1413354706 (nil) (nil) 15263
	ns:rw:0 {} 6 10 0 0.000000 0.000000 0.000001
	ns:sm:0 {} 5 0 0 0.000000 0.000000 0.000000
	busylock {} 4 1 0 0.000000 0.000000 0.000000
	msglock {} 3 16 2 0.000089 0.000047 0.000428
	dumplock {} 2 1 0 0.000000 0.000000 0.000000
	startlock {} 1 0 0 0.000000 0.000000 0.000000
	ns:cs:0 {} 0 145 7 0.000049 0.000034 0.000183
	thread0x7f06b0339700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 15 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b034d700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 15 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b0361700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 15 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b0375700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 15 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b0389700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 15 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b039d700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 15 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b03b1700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 1 1 0 480 0 0} {1024 14 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b03c5700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 15 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b03ff700 {32 0 0 0 0 0 0} {64 14 2 0 80 0 0} {128 6 2 0 96 0 0} {256 3 1 0 176 0 0} {512 1 1 0 480 0 0} {1024 11 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b03d9700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 1 1 0 480 0 0} {1024 14 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06af1e2700 {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 7 1 0 48 0 0} {256 0 0 0 0 0 0} {512 2 1 1 0 0 0} {1024 13 3 2 800 0 0} {2048 8 2 2 0 0 0} {4096 3 1 0 3366 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	thread0x7f06b03db700 {32 0 0 0 0 0 0} {64 248 8 0 296 0 0} {128 0 2 0 96 0 0} {256 45 18 0 3456 0 0} {512 1 1 0 480 0 0} {1024 14 1 0 800 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
	shared {32 0 0 0 0 0 0} {64 0 0 0 0 0 0} {128 0 0 0 0 0 0} {256 0 0 0 0 0 0} {512 0 0 0 0 0 0} {1024 0 0 0 0 0 0} {2048 0 0 0 0 0 0} {4096 0 0 0 0 0 0} {8192 0 0 0 0 0 0} {16384 0 0 0 0 0 0}
[-work:0-][Wed Oct 15 02:31:47 2014]: enter critical section once
[-work:0-][Wed Oct 15 02:31:47 2014]: enter critical section twice
[-work:0-][Wed Oct 15 02:31:47 2014]: got semaphore posted from main
[-work:1-][Wed Oct 15 02:31:47 2014]: enter critical section once
[-work:1-][Wed Oct 15 02:31:47 2014]: enter critical section twice
[-work:1-][Wed Oct 15 02:31:47 2014]: got semaphore posted from main
[-work:0-][Wed Oct 15 02:31:47 2014]: rwlock unlocked
[-work:0-][Wed Oct 15 02:31:47 2014]: exiting
[-work:1-][Wed Oct 15 02:31:47 2014]: rwlock unlocked
[-work:1-][Wed Oct 15 02:31:47 2014]: exiting
[-work:3-][Wed Oct 15 02:31:47 2014]: enter critical section once
[-work:3-][Wed Oct 15 02:31:47 2014]: enter critical section twice
[-work:3-][Wed Oct 15 02:31:47 2014]: got semaphore posted from main
[-work:3-][Wed Oct 15 02:31:47 2014]: rwlock unlocked
[-work:3-][Wed Oct 15 02:31:47 2014]: exiting
[-work:2-][Wed Oct 15 02:31:47 2014]: rwlock write aquired
[-work:0-][Wed Oct 15 02:31:47 2014]: tls cleanup 0
[-work:1-][Wed Oct 15 02:31:47 2014]: tls cleanup 1
Segmentation fault (core dumped)

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/nsd-4.99.6-dtk-2/bin/nsthreadtest'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f06afb641e3 in ?? () from /usr/lib/libtcl8.5.so.0
#2  0x00007f06afb642f1 in ?? () from /usr/lib/libtcl8.5.so.0
#3  0x00007f06afb102f2 in Tcl_FinalizeThread () from /usr/lib/libtcl8.5.so.0
#4  0x00007f06afdc114a in CleanupTls (arg=<optimized out>) at pthread.c:816
#5  0x00007f06affcbc83 in __nptl_deallocate_tsd () at pthread_create.c:156
#6  0x00007f06affcbea8 in start_thread (arg=0x7f06b03ff700)
    at pthread_create.c:315
#7  0x00007f06af7d73fd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x0000000000000000 in ?? ()
(gdb) 

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] 32-bit Naviserver fails on Windows

[Andrew P. <at...@pi...>]

On Sun, Oct 12, 2014 at 03:00:16PM -0400, Andrew Piskorski wrote:

> My new 32-bit Naviserver can't even run "nsd -h"!  It dies immediately
> with:
> 
>   The application was unable to start correctly (0xc000007b).
>   Click OK to close the application.

False alarm.  I rebooted Windows, and now my 32-bit nsd seems to run
just fine!

-- 
Andrew Piskorski <at...@pi...>

[naviserver-devel] 32-bit Naviserver fails on Windows

[Andrew P. <at...@pi...>]

Well, I belatedly realized that I need to build a 32-bit Naviserver on
my 64-bit Windows 7 box.

(The old proprietary library I currently need to link against is only
available in 32-bit.  I hope to port to a newer library, but first I
need to get my old code actually working with Naviserver on this box.)

So I configured my command prompt build with "/x86" rather than "/x64",
like so:

  "%ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Debug /x86 /win7
  nmake -f Makefile.win32 all-core

My branch includes better build support for 32-bit (although still not
yet good enough):

  https://bitbucket.org/apiskors/naviserver/commits/all

My new 32-bit Naviserver can't even run "nsd -h"!  It dies immediately
with:

  The application was unable to start correctly (0xc000007b).
  Click OK to close the application.

Looks like it dies before invoke any Naviserver or Tcl code at all, so
I think either I've linked Naviserver wrong, or something is broken on
my Windows box.

I verified that all my compiled Naviserver code is indeed 32-bit with
this:

  dumpbin /headers *.exe *.dll | findstr machine

Oddly, Dependency Walker thinks that ALL of the external DLLs nsd.exe
is using are 64-bit!  That would be very bad, but I'm not sure if it's
actually true.  Reports on the web say that Dependency Walker can
incorrectly report such problems because it doesn't ignore 64-bit
libraries the sam way Windows itself does.

  http://www.dependencywalker.com/

Naviserver's include/Makefile.win32 links against these Windows
libraries:

  kernel32.lib advapi32.lib ws2_32.lib user32.lib

Do I need to do something special to find the 32-bit versions of
those?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] commit/naviserver: gustafn: - switch to the notation of Tcl_ObjCmdProc and Tcl_CmdProc as defined in tcl.h in Tcl 8.5.*

[Zoran V. <zv...@ar...>]

On 11 Oct 2014, at 17:30, Gustaf Neumann <ne...@wu...> wrote:

> no, tcl 8.4 has exactly the same definitions.

Great! Thanks!
Zoran