src/sbbs3 js_global.c 1.388 1.389
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv5097

Modified Files:
js_global.c
Log Message:
Make the load()/require() search path of last resort the CWD. This makes the error message if failure to find the file to load less confusing.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.389 1.390
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv9152

Modified Files:
js_global.c
Log Message:
New global methods:
utf8_encode(): to convert a CP437 string or a single Unicode codepoint (number)
to UTF-8 encoded string
utf8_decode(): to convert a UTF-8 encoded string to a CP437 string

Move the require() enumeration to just below load() so it's documented closer to its dad in jsdocs.html


--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.390 1.391
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20669

Modified Files:
js_global.c
Log Message:
New global function: utf8_width()
- returns the fixed printed-width of the specified UTF-8 encoded string


--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.391 1.392
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv25850

Modified Files:
js_global.c
Log Message:
Search the current scope for the js object to locate the current scope in,
not the global scope. This appears to be a systemic issue, and could even
be the root cause of the background log problem...



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.392 1.393
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv8511

Modified Files:
js_global.c
Log Message:
Search for the js and log objects in the current scope, not in the global object.



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.393 1.394
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv17159

Modified Files:
js_global.c
Log Message:
Check the object scope after checking the current scope when looking for
the "js" object.



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.394 1.395
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv17443

Modified Files:
js_global.c
Log Message:
Also check the object scope for the log function.



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.395 1.396
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv3811

Modified Files:
js_global.c
Log Message:
Don't leave a pending exception on exit from js_global_resolve().



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.396 1.397
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv10351

Modified Files:
js_global.c
Log Message:
Renaned utf8_width() to utf8_get_width()
New global functions:
- str_is_utf8()
- str_is_ascii()
- str_has_ctrl()

Return a more sensible value when 'null' is passed to the utf8_* functions. Updated some JSDOCS strings in regards to "extended-ASCII" and what that
means (in some cases, specifically CP437, in others, any non-ASCII chars).


--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.397 1.398
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1603

Modified Files:
js_global.c
Log Message:
New global JS function: str_is_utf16(), returns true if the passed string contains one or more UTF-16 encoded characters.

utf8_encode() can now accept a UTF-16 encoded string (e.g. "\u0f00") and will return the UTF-8 encoded version.


--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.398 1.399
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv3090

Modified Files:
js_global.c
Log Message:
Add an additional for of socket_select() that is passed multiple arrays.
It will return an object with properties corresponding to the passed
arrays, and the write parameter will be ignored. This allows usage very
much like the select() syscall, and allows a traditional non-blocking
server to be written.



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.399 1.400
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv489

Modified Files:
js_global.c
Log Message:
Fix single-array socket_select broken in previous commit.
This should fix the crash in ircd.



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.400 1.401
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv29158

Modified Files:
js_global.c
Log Message:
Do not re-create the result arrays for each socket that's read (derp).
This only impacts the new socket_select() method with multiple arrays.



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.401 1.402
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv28762

Modified Files:
js_global.c
Log Message:
Fix resource leak from background-load()'s:
The created message queue for each background-load()ed script was never detached-from by the child thread, so the linked-lists (and their semaphores) were never freed. Calling msgQueueDetach() before ending the background_thread fixes that leak.


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Sep 18 23:52:20, you wrote to CVS commit:

src/sbbs3 js_global.c 1.401 1.402
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv28762

Modified Files:
js_global.c
Log Message:
Fix resource leak from background-load()'s:
The created message queue for each background-load()ed script was never detached-from by the child thread, so the linked-lists (and their semaphores) were never freed. Calling msgQueueDetach() before ending the background_thread fixes that leak.

so did my questioning about the background loading of dnshelper.js assist in finding this problem?? if so, YAY!

the main thing that triggered my thoughts on it, which i think i also asked about, was about using load vs require... i was thinking about other recent changes that switched from load to require to prevent multiple loadings of the same code which was also leading to problems of some sort...

in any case, this looks like it was a deep dig to root out... GoodJob!<tm> :)

)\/(ark

Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.
... People who pun deserve to be drawn and quoted.
---
* Origin: (1:3634/12.73)

Re: src/sbbs3/js_global.c
By: mark lewis to rswindell on Fri Sep 20 2019 09:19 pm

so did my questioning about the background loading of dnshelper.js assist

in

finding this problem?? if so, YAY!

I don't recall that being discussed. It just a shot in the dark that lead to some clues.

digital man

Synchronet/BBS Terminology Definition #31:
FTP = File Transfer Protocol
Norco, CA WX: 63.0øF, 86.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/js_global.c
By: Digital Man to mark lewis on Sat Sep 21 2019 02:02:14

so did my questioning about the background loading of dnshelper.js

assist in finding this problem?? if so, YAY!

I don't recall that being discussed. It just a shot in the dark that lead

to some clues.

yeah, sorry, that was with my other account, wkitty42, on IRC on the 15th...

double spaced to try to prevent word wrapping from making dog's breakfast out of it... time stamps are UTC-0400...

----- snip -----

Sep 15 10:04:20 <wkitty42> why is dnshelper.js loaded by ircd.js multiple times? should it be "required" so it is loaded once and used for all? could this be one of the leaks being seen?

Sep 15 10:04:21 <wkitty42> Routing: from sestar.synchro.net: Received SQUIT *.synchro.net from wkitty42[wkitty42@sestar.synchro.net] (wkitty42)

Sep 15 10:04:21 <wkitty42> Routing: from sestar.synchro.net: Closing Link: cvs.synchro.net (wkitty42)

Sep 15 10:04:21 <wkitty42> Routing: Auto-connecting to *.synchro.net

Sep 15 10:04:21 <wkitty42> Routing: Connected! Sending info...

Sep 15 10:04:21 <wkitty42> 0006 Accepted new connection: 71.95.196.34 port 6667

Sep 15 10:04:21 <wkitty42> JavaScript Background Load: /sbbs/exec/load/dnshelper.js

Sep 15 10:04:21 <wkitty42> Routing: Auto-connecting to *.synchro.net

Sep 15 10:04:21 <wkitty42> Routing: Connected! Sending info...

Sep 15 10:04:21 <wkitty42> 0008 Accepted new connection: 71.95.196.36 port 6667

Sep 15 10:04:21 <wkitty42> JavaScript Background Load: /sbbs/exec/load/dnshelper.js

[...]

Sep 15 10:21:09 <wkitty42> yeah, that's why i asked my question ;) i've seen vert having problems lately with such... not sure if that's because it is being run from services or not, though... i run mine from jsexec specifically to prevent it from bouncing all the time when i'm working on the board...

Sep 15 10:22:19 <wkitty42> so maybe that's why i don't see the problem that vert sees? does anyone else see the problem on their system? do they run from services or via jsexec?

----- snip -----


)\/(ark

---
þ Synchronet þ The SouthEast Star Mail HUB - SESTAR
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/js_global.c
By: Rampage to Digital Man on Sat Sep 21 2019 11:38 am

Re: src/sbbs3/js_global.c
By: Digital Man to mark lewis on Sat Sep 21 2019 02:02:14

so did my questioning about the background loading of dnshelper.js assist in finding this problem?? if so, YAY!

I don't recall that being discussed. It just a shot in the dark that

lead

to some clues.

yeah, sorry, that was with my other account, wkitty42, on IRC on the

15th...

double spaced to try to prevent word wrapping from making dog's breakfast out of it... time stamps are UTC-0400...

----- snip -----

Sep 15 10:04:20 <wkitty42> why is dnshelper.js loaded by ircd.js multiple times? should it be "required" so it is loaded once and used for all? could this be one of the leaks being seen?

I don't recall seeing that. No, require() would not be of use there. Yes, the bg-load was the issue (not specific to dnshelper.js).


digital man

Synchronet "Real Fact" #43:
Synchronet added Baja/PCMS support with v2.00a (1994).
Norco, CA WX: 82.1øF, 45.0% humidity, 0 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.402 1.403
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv24674

Modified Files:
js_global.c
Log Message:
Fix bug introduced in previous commit (rev 1.402) of this file:
The js_finalize_queue() is eventually called when garbage is collected and js_finalize_queue() calls msgQueueDetach(), so bg-load()s did not "leak" semaphores and this "fix" actually introduced a problem where the queue was detached too many times, leaving the ref count 0 while there was actually
a lingering reference (in the parent), leading to a crash as reported by echto (thanks, echto!).

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.403 1.404
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv32349

Modified Files:
js_global.c
Log Message:
Resolve MSVC warnings:
src\sbbs3\js_global.c(3703): warning C4018: '<': signed/unsigned mismatch src\sbbs3\js_global.c(3761): warning C4018: '<': signed/unsigned mismatch src\sbbs3\js_global.c(3779): warning C4018: '<': signed/unsigned mismatch

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.404 1.405
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20519

Modified Files:
js_global.c
Log Message:
Document that mkpath() returns true if the path already exists.

ie: Does not return if the path was made or not.


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.405 1.406
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20353

Modified Files:
js_global.c
Log Message:
When a server does a background load, this line would be logged to the terminal
server (uck). Needs an lputs() callback or similar.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.406 1.407
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv8881

Modified Files:
js_global.c
Log Message:
Add global socket_errno_str property for cross-platform description of last socket-related error.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 js_global.c 1.408 1.409
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
js_global.c
Log Message:
Bug-fix: global socket_errno_str property returned numeric value (not string).


--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/7c12761d51ebc0a33482d62f
Modified Files:
src/sbbs3/js_global.c
Log Message:
Add global methods: strerror() and socket_strerror()If you have a stored errno value (or Socket.error), these are how you convertthat number to an error description.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d083d463917d83c4e0e3fd02
Modified Files:
src/sbbs3/js_global.c
Log Message:
Don't log an error when JS resolve_ip() failse.g. don't log the error "term !ERROR resolve_ip example.com failed with error -2", just let the script deal with the failure and log an error if it wishes.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/292c4acccd7805e22af91d7e
Modified Files:
src/sbbs3/js_global.c
Log Message:
String processing functions return null (instead of "null") when passed nullThis was initially just done for lfexpand(), but then I realized there were alot of these string processing functions that just checked for VOID(undefined) argumnet value, but not null.
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/cba62a81a5b159b0589012a4
Modified Files:
src/sbbs3/js_global.c
Log Message:
Properly handle CSI m in html_encode()Used by gcc in warnings.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/c67c16bb3b401d214b837f17
Modified Files:
src/sbbs3/js_global.c
Log Message:
Add support for conditional new-line Ctrl-A code (/) in html_encode()
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/322471e4d3364c7a9979c0e9
Modified Files:
src/sbbs3/js_global.c
Log Message:
netaddr_type() now returns NET_NONE when passed null or undefined... instead of undefined, to match what the documentation already stated.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8229b90607aa8e76e11ff2db
Modified Files:
src/sbbs3/js_global.c
Log Message:
Add new global JS function: rmfiles() (remove files)number rmfiles(directory, spec=*, keep=0)Removes files and sub-directories, recursively. Use with caution!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8fbd052ef6f5d608011651c2
Modified Files:
src/sbbs3/js_global.c
Log Message:
Fix GCC warning regarding incompatible pointer type
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/1ea093ded702fc1c800b54fb
Modified Files:
src/sbbs3/js_global.c
Log Message:
Add new global method: strip_ctrl_a() - remove Ctrl-A sequences from stringUnlike strip_ctrl(), does not remove any other control characters from string.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/947f1a785d06f1ce6ebce9e4
Modified Files:
src/sbbs3/js_global.c
Log Message:
Update JSDOCS for resolve_ip and resolve_host: returns null on failure
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/9544742b6578711d4fdb15b9
Modified Files:
src/sbbs3/js_global.c
Log Message:
Elaborate in JSDOC string for html_decode()

Add comment/question about the use of JS_SetReservedSlot(), for Deuce
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/bcf5220dc1dbd5b504ac68a0
Modified Files:
src/sbbs3/js_global.c
Log Message:
Clarify JSDOC kibibytes versus kilobytes
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/2aa805d5e8f34dbc0caeadcc
Modified Files:
src/sbbs3/js_global.c
Log Message:
Log the problem codepoint when reporting error in utf8_encode()
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e7738fa44ef19b502e9e0cf4
Modified Files:
src/sbbs3/js_global.c
Log Message:
Fix commit 78dc9470 - wasn't complete

For some reason, I committed test code that commented-out the actual call
to js_IsTerminated() which avoided the unnecessary error log message. I guess
I was testing to confirm the change actually worked. <shrug>
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)