Node tiddlywiki crashes when accessing through http

#1

Hello, everyone!

I went for holidays, and after coming back, I cannot connect to my local (nodejs) tiddlywiki instance.

Error is consistent and is a variation of the following:

sudo /usr/bin/tiddlywiki /home/apinto/paogarden --listen host=127.0.0.1 port=81 debug-level=debug
syncer-server-filesystem: Dispatching 'save' task: $:/StoryList
Serving on http://127.0.0.1:81
(press ctrl-C to exit)
Request path: {"protocol":null,"slashes":null,"auth":null,"host":null,"port":null,"hostname":null,"hash":null,"search":null,"query":null,"pathname":"/","path":"/","href":"/"}
Request headers: {"host":"localhost:81","user-agent":"Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8","accept-language":"en-US,en;q=0.5","accept-encoding":"gzip, deflate, br","dnt":"1","connection":"keep-alive","cookie":"username-localhost-8888=\"2|1:0|10:1712494711|23:username-localhost-8888|192:eyJ1c2VybmFtZSI6ICIxNzRhZGQxNzVmN2U0MzIzYmIxNWM1ZTM1MzUxZTg4MSIsICJuYW1lIjogIkFub255bW91cyBDYXJwbyIsICJkaXNwbGF5X25hbWUiOiAiQW5vbnltb3VzIENhcnBvIiwgImluaXRpYWxzIjogIkFDIiwgImNvbG9yIjogbnVsbH0=|981058c50c8dc2d9be1d34c72724faf46ba9c6078eef63fb528f1199038f3a92\"; _xsrf=2|98e08dd5|b2ff98d88fee2d40da1d4dd1fc315576|1712494711; username-localhost-8889=\"2|1:0|10:1712759949|23:username-localhost-8889|204:eyJ1c2VybmFtZSI6ICIxNGU5OTQ5NzUwNTM0YTNjOWNkYzdlM2RiYzQzNmExMiIsICJuYW1lIjogIkFub255bW91cyBIYXJwYWx5a2UiLCAiZGlzcGxheV9uYW1lIjogIkFub255bW91cyBIYXJwYWx5a2UiLCAiaW5pdGlhbHMiOiAiQUgiLCAiY29sb3IiOiBudWxsfQ==|f74afd9c65ce1cb7587495942846d40f20d75362e1f64ef997f8379f4ede4347\"; Cookie=sid=17452bd4e74353cef8ce6763b96330ed29382f7a654cb02b8a5be29d8512cea4:Language:portuguese:id=1; 1289-SessionId=3928ee99382556bb3a293f125255b4f448424aeb3cdcf2c6d4cd39a641c374f6; CSRF-Token-WXXYX=KpMyR2eeU7uaH7AnuS4phNQjcKLbYLxa; CSRF-Token-ITCLG=KbYh26rH6sUWdTL6wzQEC6rpbnTb54hV; CSRF-Token-T6XDY=EWeTt9feY9u3TeHv9yGnQgczu6nnkh3w; 8080-SessionId=37c2811ab9e84973b3c3900a29b45b5fbe9711240c5b008bffdbfd44db2cf27e","upgrade-insecure-requests":"1","sec-fetch-dest":"document","sec-fetch-mode":"navigate","sec-fetch-site":"cross-site"}
authenticatedUsername: undefined
$:/core/modules/utils/fakedom.js:278
			return b.join("");
			        ^

RangeError: Invalid string length
    at Array.join (<anonymous>)
    at TW_Element.get ($:/core/modules/utils/fakedom.js:278:13)
    at $:/core/modules/utils/fakedom.js:276:17
    at $tw.utils.each ($:/boot/boot.js:146:12)
    at TW_Element.get ($:/core/modules/utils/fakedom.js:275:14)
    at exports.renderTiddler ($:/core/modules/wiki.js:1233:144)
    at exports.handler ($:/core/modules/server/routes/get-index.js:20:24)
    at Server.requestHandler ($:/core/modules/server/server.js:298:9)
    at Server.emit (node:events:519:28)
    at parserOnIncoming (node:_http_server:1136:12)

If it helps, my instance usually deletes the field for ‘username for signing changes to tiddlers’ — it’s always blank after a tiddlywiki reboot.

I am running TW 5.3.3.

Thanks for any help!

EDIT: my wiki is version controlled with git; reverting to a previous commit doesn’t help. I can, however, make it run on a new wiki…

#2

I’m still trying to fix this!

As my nodejs tiddlywiki runs in a service, it restarts on every fail and I can see there are some modified files whenever I try to connect via http.

They are StoryList tiddlers; I tried deleting them, and changing the contents of tiddlers these were modifying to see if anything could happen (assuming something like this could be happening).

I also had a newly created tiddlers that were handled via a script. I moved those elsewhere, to possibly avoid conflicts, and it seems this was a fix. I’m not sure what is triggering this and so I’m keeping this topic open (I might try to further debug later, as this is a fatal error that might be fixable).

#3

Hello!

Sorry for bumping the thread. This keeps happening at random. I have a few scripts that create tiddlers, and I’ve had a few cases of malfunction.

At first, a stray .json file went into the tiddlers folder, and this provoked the error above; recently, a 20mb .png also provoked the same error.

Yesterday evening, my wiki crashed again (no .json or overtly big .pngs around); still haven’t tracked down the issue, but I will come back with more information. Error is the same as in the OP; any help in further debugging the issue would be tremendously appreciated (I can easily reproduce the error).

#4

Is this connection accessed locally of from the internet?

I’m suspicious of the Request headers. TW should not use any cookies or session ids.
The request path seems to contain nothing useful. So it may be designed to cause problems.

1 Like
#5

Hi @paotsaq this error message suggests that the problem may be that the size of the wiki exceeds the maximum string length allowed by Node.js. How big is the wiki in question? Can you save it as a single file wiki and check whether that works?

That is not correct. We often see cookies and session ID headers inserted by proxy servers. I don’t see anything unusual in the example posted.

1 Like
#6

Hello, @jeremyruston!

In fact, it could be related to that. I am currently reproducing the problem by just putting a really big file in the tiddlers folder. And bingo!

<--- Last few GCs --->

[198612:0x558861cc8520]    13983 ms: Scavenge (reduce) 2037.4 (2051.8) -> 2037.4 (2048.8) MB, 0.72 / 0.00 ms  (average mu = 0.974, current mu = 0.979) allocation failure; 
[198612:0x558861cc8520]    14014 ms: Mark-Compact (reduce) 2055.0 (2066.4) -> 2054.9 (2066.2) MB, 13.53 / 0.00 ms  (+ 0.2 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 101 ms) (average mu = 0.960, current mu = 

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x55885e61eb4d  [node]
 2: 0x55885e9fd664 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0x55885e9fda5b v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x55885ec0976c  [node]
 5: 0x55885ec20e67 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 6: 0x55885ec22ad8 v8::internal::Heap::HandleGCRequest() [node]
 7: 0x55885eb92de4 v8::internal::StackGuard::HandleInterrupts(v8::internal::StackGuard::InterruptLevel) [node]
 8: 0x55885efb612d v8::internal::Runtime_StackGuardWithGap(int, unsigned long*, v8::internal::Isolate*) [node]
 9: 0x5587ff3a53f6

So I think we got a right diagnosis. Anything I could do other than compress my images? Externalising the image files does not seem to work too well with me, since my Tiddlywiki will try to source them from localhost (is this normal behaviour?).

Thank you!

#7

Hi @paotsaq it sounds like it would be worth getting external images working. The simplest approach is to put the image files in the files subfolder of the wiki folder as described here. Perhaps it would be best to start a new thread on the topic.

2 Likes
#8

thank you once more, @jeremyruston — I solved the issue for now with sufficient lee-way to focus on some other problems. But I’ll get back at this later, on another thread. All the best! (and thank you too, @pmario!)

1 Like