On 03.06.20 21:13, Andrew Piskorski wrote:
ns_thread.test
[03/Jun/2020:14:25:28][4844.13bc][-tcl-nsthread:7-] Notice: update
interpreter to epoch 1, trace none, time 0.219973 secs
Assertion failed: (addr != ((void *)0)), file tclobj.c, line 325
[03/Jun/2020:14:25:32][4844.1dd8][-tcl-nsthread:8-] Notice: update
interpreter to epoch 1, trace none, time 3.902536 secs
The stack trace looked like this:
ucrtbased.dll!000007feedad41cf() Unknown
libnsd.dll!Ns_TclSetAddrObj(Tcl_Obj * objPtr, const char * type, void *
addr) Line 325 C
libnsd.dll!NsTclThreadObjCmd(void * clientData, Tcl_Interp * interp, int
objc, Tcl_Obj * const * objv) Line 239 C
[External Code]
libnsd.dll!CmdThread(void * arg) Line 1333 C
nsthread.dll!NsThreadMain(void * arg) Line 236 C
nsthread.dll!ThreadMain(void * arg) Line 874 C
So that was inside Ns_TclSetAddrObj(), probably in the
"NS_NONNULL_ASSERT(addr != NULL);" line. It was called from
NsTclThreadObjCmd(), in "case THandleIdx", line 238 in tclthread.c.
That presumably came from a Tcl "ns_thread handle" call, and there's
only one of those in the test suite, "test ns_thread-2.6" on line 70
of "ns_thread.test". But I don't understand why that would throw a
null pointer exception!
Probably "Ns_ThreadSelf(&tid);" does not work under windows (get the
id of the current thread). Ns_ThreadSelf() is defined in the OS specific
part (winthread.c). The exception is probably coming from
test thread-2.3, it looks to me as if the the thread (here the
thread running the tests) is not properly initiated under windows.
i have added one more assert, to make it easier to pinpoint the
problem.
==== ns_listencallback-1.0 register FAILED
==== Contents of test case:
This is again one of these low-level socket commands.
The ns_schedule-2.1 failure certainly sounds related to my original
problem of the scheduler thread getting stuck, but there's enough else
going on here that don't have any idea where the real source of the
problem might be.
This sounds indeed related with the original problem.
The test registers a repeating proc (interval 1s),
but within in the time-range of 2.5s, it is executed
only once.
On 03.06.20 23:41, Andrew Piskorski wrote:
Weirdly, that stacktrace seems like it must be missing some
intermediate function calls, because nsproxy's Ns_ModuleInit()
definitely never calls Ns_IncrTime() DIRECTLY. So I'm not sure what's
going on there either.
this is typical, when the code is compiled with an optimizer. Try to
deactivate the optimizer, this will improve the feedback.
maybe i get on the weekend some access to a win environent.
-gn
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
