[solved] RSOD Troubleshooting steps beyond the obvious (for javascript error)?

#1

**UPDATE: @btheado found the specific culprit, and others illuminated additional factors. I’ve rebuilt a 5.2.7 version, leaving behind the problematic wordcount viewtemplate addition, plus old plugins and other stuff that might have been cruft. **

Dear all,

I’ve recently discovered a reliably-reproducible RSOD javascript error in my most essential site.

It happens when I click on one of several plugins within the control panel, even if those plugins are disabled. (Oddly, they can be expanded “inline” within control panel; I get the error only upon clicking to open).

To my dismay, this little grenade is present in all reasonably-recent backups, and since it appears on backups from 2+ weeks ago (but not on a 6-week-old backup), I can no longer reconstruct details of which edits might be at fault. (Obviously, it’s an obscure trigger, not yet affecting daily work. But I don’t want to continue relying on a wiki with this glitch in it!)

What’s baffling is that the following three steps (on a troubleshooting clone) are not helping:

(1) disabling every plugin (leaving only the core)
(2) taking all non-shadow cascade and stylesheet tiddlers offline
(3) booting in safe mode with the above changes already saved

The developer tools console recommended by @EricShulman shows that about once per second I’m getting something like this (with pages-worth of further details after the second Uncaught RangeError: Maximum call stack size…):

boot.js:216 Uncaught RangeError: Maximum call stack size exceeded
$tw.utils.error @ boot.js:216
window.onerror @ boot.js:243
strings.js:2 Uncaught RangeError: Maximum call stack size exceeded
    at eval (strings.js:2:2673)
    at eval (wiki.js:2:5129)

I have already also tried upgrading the whole wiki (from 5.2.5) to 5.2.7. (Actually, it was only after that upgrade today that I discovered the problem, and traced its origins back to somewhere in the murky >100-edits-ago past.)

Obviously, there’s some customization that is going wrong, or something that’s simply corrupt. But after disabling plugins, removing overridden shadows, and booting in safe mode, what next steps would you take?

DEMO: In case anyone is interested, I’ll share a link to the clone – from which I’ve been attempting to remove all potential fangs, with no luck: My TiddlyWiki — a non-linear personal web notebook

How to reproduce RSOD: In Control panel (plugins tab), click to open Refnotes or Shiraz or Tiddler Commander.

(The fact that the problem happens even when these plugins (and all plugins) are disabled has convinced me that the problem has nothing to do with @Mohammad! – although there must be something these happen to have in common that brings the problem to surface.)

:face_with_monocle:

#2

Hmmm… “once per second” makes me wonder if it’s related to any of my TiddlyTools Time add-on features. Have you installed any TiddlyTools/Time/* tiddlers?

In particular check to see if TiddlyTools/Time/action-timeout.js and TiddlyTools/Time/Ticker are installed, which are used to update the $:/temp/time/ticker timestamp value once a second. Note that TiddlyTools/Time/Ticker is tagged with $:/tags/StartupAction/Browser, and can be disabled for testing purposes by removing that tag, which prevents it from being invoked upon startup, thereby disabling the once-per-second “ticker” update.

Also, since the problem doesn’t seem to be present in the 6-week-old backup, perhaps you can start with a copy of that backup, and progressively add more recent changes (in date modified order) until the error begins to occur. That should hopefully help narrow down exactly which changes introduced the problem.

#3

Eric,

I am indeed doing something like that.

Alas, my urgency to solve the problem will mean that I’ll be less than painstaking about reconstructing exactly what the culprit was. I’m clawing my way back with a reconstruction effort right now…

I had indeed installed TiddlyTools/Time/action-timeout.js and related stuff at one point (so that I could have visitors see a refresh page-control appear only once 5 minutes had passed). But I’m pretty sure I had removed all such things tagged $:/tags/StartupAction/Browser in the process of troubleshooting…

Thanks for the idea. After I crawl out of this particular challenge, at some point I’ll go back and see whether I can isolate the conflict.

(Update: I did just invoke [search:title[TiddlyTools]] in the advanced search filter tab of the demo clone site, and just nuked everything there. Did not prevent the RSOD trigger when I saved and reloaded on the increasingly bare-bones clone.)

-Springer

#4

Did you minify the core?

#5

It was an external-core wiki

#6

I wanted to know, if you used the uglifier by flibbles?

#7

I don’t think I used uglifier — certainly not recently, and I don’t recall seeing any signs of it while scanning everything for a selective import of old tiddlers.

[But pmario’s intuition was spot on – uglifier did play a role in the plugins I was clicking on…, see below]

#8

I would actually delete the three plugins by Mohammad. You can do that by using buttons like this:

<$button>
<$action-deletetiddler $tiddler="shiraz"/>
Delete "$:/plugins/kookma/shiraz"
</$button>

(the other two buttons are left up to you :wink: )

Save, and reload.

I suspect that the way the plugins are packed has a subtle defect. Unfortunately I can’t test this premise because the HTML5 saver is being defeated by the tiddlyhost saver. (see other post).

#9

What I actually did was to re-import hundreds of content tiddlers (manually selected!) via the 5.2.7 upgrader, leaving out plugins and other config / stylesheet stuff, then gradually adding key config and stylesheet stuff back in.

Then I just did fresh installations of each desired plugin including the three that had been crashing on click… slowly reconfiguring to match needs. No sign of the trouble on my live 5.2.7 version, now revamped from the ground up and just a bit rough around the edges.

Not sure what the problem was, but now I need to get back to my actual tasks…

So grateful for your responsive help, @pmario @Mark_S @EricShulman and @Mohammad !

#10

Looks to me like the issue is with this ViewTemplate: My TiddlyWiki — a non-linear personal web notebook

image
image604×501 42.4 KB

In spite of the “SAFE” in the title, it is still tagged with $:/tags/ViewTemplate. When the Shiraz plugin tiddler is navigated to, the wikify call in the above view template is causing the RSOD. After I removed the ViewTemplate tag, I am able to navigate to the Shiraz plugin tiddler without the RSOD.

A plugin tiddler is not meant to be wikified. But hopefully there is a way to improve the code such that it doesn’t give an RSOD. It will require more troubleshooting to find the root cause of the issue.

#11

Thanks for tracking it down, @btheado!

Removing all custom ViewTemplates ought to have been part of my trouble-shooting, but I think my brain just ran out of juice after trying so many other things!

This custom subtitle included a word-count of the text field (something that was quick-and-handy for handling student work that always had a word count limit). I’ll be more cautious about using that subtitle customization in the future. There was actually already a note of caution about it in this thread… but it had seemed to be playing nicely for months, and apparently I lost track of it as a possible place for mischief to happen.

#12

@Springer has some kookma plugins (e.g. Shiraz, Utility, Refnotes, Commander) which are minified using @Flibbles Uglify. The packaged plugins from kookma library all are minified using Uglify.

BUT all of them are tested with TW5.2.7 and work fine (as single or with together)

#13

Hi @btheado

Great job, well done! It is always difficult to debug!

One question: In the test wiki, when clicking on other plugins, TW open them without problem and the mentioned view template works fine! Only when opening a kookma plugin in the test wiki the RSOD is appeared!
I think the difference is those kookma plugins are minified using @Flibbles Uglify. So, don’t you think $wikify cannot work with minified tiddler?

#14

Further tests:
@btheado, @Flibbles

I just created a temporary wiki on Tiddlyhost: Basic Edition — temporary to track issue (tiddlyhost.com)

  1. started with empty-5.2.7.html
  2. added kookma plugin library.
  3. installed few minified plugins
  4. saved and reloaded
  5. overwrote the $:/core/ui/ViewTemplate/Subtitle from @Springer test wiki (mentioned by @btheado)
  6. Saved and reload
  7. Open any plugins inclding Shiraz/Utility/Commander
  8. Everything works fine! Word count works fine.

My conclusion: The minified plugins work fine. The view template works with minified plugin tiddlers.

#15

I could replicate the problem clicking on any plugin tiddler with Edge. With FF it needed more time, but at the end the error did come up there too. …

So I think it’s not necessarily a problem of the minified wikitext. Minified wikitext basically is the same thing, that \whitespace trim does. So there should be no problem to wikify it.

I think the main problem with the wiki is the amount of 3rd party plugins used. There are some plugins from tobibeer, which are super old, not maintained or even tested and where developed with TW beta versions. Most of the functionality Tobias implemented can be done now with the TW core if the docs would be read.

I’m pretty sure that not all of the 42 plugin added to the wiki are really used.

1 Like
#16

LOL. Of course that’s true — see my mention of “cruft” in ;tldr above. (The ground-up rebuild has 16 beyond the core, and is 99% indistinguishable, functionally.) The trick was finding the time to be methodical in weeding out things I wasn’t actively depending on anymore. (In my defense, quite a few had been in disabled state for a long time, while I passively tested for whether I’d have regrets in removing them altogether.)

While I was busy not finding the time to keep things trim, the RSODs emerged, and were not easy to troubleshoot. So, as it were, the time found me. :wink:

I did not know this. I’ll be cautious about retaining them in this and other projects.

-Springer

#17

Tobias had some great ideas and a talent to create well looking UI elements. But some implementations had side-effects or the filter syntax did not meet the core requirements. Several contributions have not been merged to the core. …

So he did make plugins … Most of them are great and may still work as intended. … But you have to be careful. They have not been maintained since 2017 or even earlier. … So if they contain any javascript, you really have to check if they do not overwrite core functions. …

Many of Tobias’s ideas have been implemented in a slightly different way, into the core like <$vars, which is now superseded by <$let. or decode-, encodebase64, contains, count, filter, split …

Just wanted to let you know.

1 Like
#18

Trying to follow here. So the problem is that wikifying a minified tiddler can cause problems? Or is it the attempt to count the results of the wikified, minified text?

#19

Hi Mark,
No the wikify widget has no problem, and the minified plugins are also work as expected…
See #14 above.

#20

Post #14 is speculative. Maybe an old plugin caused the problem. But in post #9 we’re told that the error is caused by a template. The template doesn’t seem to be invoking anything other than standard wikitext. And the errors only occurred when opening the minified plugins. So for one of the other plugins to be causing problems, it would have to be overwriting the core.

I guess I would like to know what old plugins actually cause problems with the core, so that that fact can be noted in links.tiddlywiki.com.