On Mon, Jun 01, 2020 at 11:08:48AM -0400, Andrew Piskorski wrote:
> ## Last test that runs on Windows, it locks up forever:
>
> http_persistent.test
> ns_sockioctl failed: no such file or directory
> while executing
> "ns_socknread $s"
> (procedure "client_readable" line 2)
For now I simply moved the entire http_persistent.test file out of the
way, so the server skips those tests. With that, test server got
further, but eventually crashed with what looks like a null pointer
dereference, here:
[03/Jun/2020:14:25:28][4844.2b10][-conn:test:default:1:229-] Notice: inside
the filter 3.4
ns_serverpath.test
ns_set.test
ns_sha1.test
ns_sls.test
ns_striphtml.test
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!
Prior to that crash, various other interesting test failures cropped
up, including both "ns_listencallback-1.0" and "ns_schedule-2.1" below.
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.
==== ns_listencallback-1.0 register FAILED
==== Contents of test case:
set localhost [expr {[ns_info ipv6] ? "::1" : "127.0.0.1"}]
ns_log notice "open sockent on $localhost 7227"
set fds [ns_sockopen $localhost 7227]
lassign $fds rfd wfd
set size 0
if {[gets $rfd line] == -1} {
ns_log error "got no data"
} else {
incr size [string length $line]
puts $wfd "How are you?"
flush $wfd
gets $rfd line
incr size [string length $line]
}
return [list size $size]
---- Result was:
size 0
---- Result should have been (exact matching):
size 46
==== ns_listencallback-1.0 FAILED
==== ns_schedule-2.1 schedule proc: interval FAILED
==== Contents of test case:
set id [ns_schedule_proc 1s {nsv_lappend . . ns_schedule-2.1}]
ns_sleep 2.5s
ns_unschedule_proc $id
nsv_get . .
---- Result was:
ns_schedule-2.1
---- Result should have been (glob matching):
ns_schedule-2.1 ns_schedule-2.1*
==== ns_schedule-2.1 FAILED
--
Andrew Piskorski <a...@piskorski.com>
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
