[JS] InDesign Crashes Randomly

[_Daniel_Rodney_]

I have a script (which is fairly complex, calling shared script files, etc.) and I have a random crashing problem in CS2. CS3 never crashes, but CS2 randomly does. Since it is a random crash I am having a hard time figuring out how to solve the problem. I don't know if I am doing something InDesign doesn't like, if I am pushing InDesign to hard with the amount of stuff it is doing (should be). I usually get error messages when I have scripted something wrong, but not when it crashes. And sometimes the script finishes without errors or crashes and it's worked perfect. So if it can work sometimes I am having a hard time figuring out the source of the crash. Any ideas of how I can figure this out without error dialogs and without a set time that it crashes? I have random issues like this! (And remember that CS3 I have never seen crash on it, just CS2.)

I know this is a weird one and sorry I can't be more specific. Thanks for any help.
Dan

[Harbs.]

Hi Daniel,

That's a tough one!

One issue which might be worth looking into, is variable name conflicts.
I've had issues with crashes when certain global variables were
redefined. I doubt my specific issue is connected to yours, but try and
make sure that all your variables are local. You can alsotry to track
down were things go wrong by using alerts or script logs.


Harbs

[Guest]

Daniel,

I doubt you're pushing ID too hard. I've shoved ID so hard (CS2 and 3) that I'm amazed something didn't go massively wrong.

The first thing you have to figure out is exactly what call is causing the crash.

Alerts are a pain in the butt. I would recommend creating a log file.

I have a Log class that works pretty well that I've just updated on www.creativescripting.net. It'll be in BobsScriptLibrary.

Place a log call at the top of every function, and run it until it breaks. That'll give you the function causing the problem. From there, place log calls through out the function, crash it, and repeat until you find the offending line.

Once the offending line is known, the answer may be obvious to you or someone on this forum.

Good Luck!

Bob

[_Daniel_Rodney_]

Thanks, I'll check out your Log class Bob to see if that can track down the error.

Harbs mentioned about local variables. I always declare a variable like this:

myVariable = "something"

I never use the word var in front of a variable. I make sure I use unique names. To make the variables local do I have to put var in front of it? Would that really make a difference if I use unique names all the time? I have never seen any difference in putting var in front of variable names yet, so I have never bothered.

Thanks again.

[_Dave_Saunders_]

There are two situations (at least) where using local variables helps a lot:

1. When debugging with ESTK. The Data Browser shows only the local variables that are in scope when you are stepping through a function. This really cuts through the clutter and helps you see what's really going on in the function.

2. When using scripts to call and run each other. That's when I run into most global name clashes. It can really wreak havoc if you have the same global function names in two different scripts when one calls the other.

Dave

[_Daniel_Rodney_]

Hey Bob, I am trying your log class and while it creates the log file, nothing goes into it. Here's the code I am using. What am I doing wrong?

myBobLibScriptFile = new File( getScriptPath() + 'BobsScriptLibrary.jsx' )

app.doScript( myBobLibScriptFile, ScriptLanguage.javascript )



var log = new BobsLib.Log( getScriptPath() + "DanLogFile.txt", true );

log.writeln( "This is my first log entry" );

log.close();

Also, must I ask it what to write for each function/variable. My script is so complex it would take a long time for that. How is your log class supposed to work?

On another note, as much as I'd like to debug with ESTK, it never works for more complicated scripts that link to other scripts, write preference files, show dialogs, etc. So I don't know what I am doing wrong with it, but I really don't understand how to use the debug functions of ESTK. Sadly I have never seen any good documentation to learn it either. I am not a full blown programmer by background. I am a web developer and print designer, so while I am pretty good with JS, some things get a bit hard to figure out on my own and documentation for all this stuff is not that great or intuitive. If I am not debugging with ESTK (I am using error alerts instead) and al using unique variable and function names, then global variables sounds like they are fine. The weird thing about the script is that CS3 never crashes, and CS2 only crashes some times. It is not consistent, I can run it 5 times in a row, then sometimes 10, sometimes only 3 times and then it will crash. Truly weird in my opinion.

[Harbs.]

Hi Dan,

Using global variables is really very bad practice. Besides all the
other problems, it makes your code much harder to reuse. If you create
nuclear functions for all the basic stuff you do, you can reuse those
functions anywhere without worrying about name conflicts. I have a
function library which has close to 100 functions which I use regularly.
Keeping track of so many unique variable names would be cumbersome to
say the least! I also have a standardized naming system for variables
(which requires them to be local). This makes code much more reusable as
well.

A script which uses local variables is also (slightly) more efficient.
The scripting engine searches for a variable name locally before it
searches in the global namespace. Theoretically this would also reduce
the chances of problems...

Also, I don't know if you use the APID ToolAssistant from Rorohiko, but
if you do, using global variables with that opens up a whole new can of
worms!!! You are asking for serious trouble by doing that.

Harbs

[_Daniel_Rodney_]

I am not using the APID. I guess I never had a problem thinking up new unique names for variables, and for me it is clearer to use a unique descriptive name so when I return to the script months later I can figure out what I was trying to do. As for reusing code, the things I have reused didn't take long to change the name and often needed slight tweaking anyway so I rarely can completely reuse functions. Now if performance is better then of course I'd rather go local. But I have a feeling that most of my variables will need to be global because I am reusing the same calculated figures across numerous functions that all need those figures. So it might not be as bad as you think. I will check into it though.

[Guest]

Daniel,

The log has a property "debug" that defaults to false. That property allows you to turn logging on and off for the entire app with a single line of code.

So you can:

log.debug = true;

or log.setDebug( true );

or you can:

log.writeln( "First Entry", true );

In the last case, the "true" is forcing the write regardless of the debug state.

Also, you really do need to limit the use of global variables. You mentioned that you're not a programmer by background. I am a programmer by background. Programmers consider the use of globals only when there are no other options.

That said, if you need to use a lot of globals, place them in a "namespace".

myNamespace = {};
myNamespace.myGlobal = 12;
myNamespace.myOtherGlobal = 24.

In this case you would be creating a single global object "myNamespace", and it contains all the globals. This eliminates the chance of your global variable names stomping on something.
To get at the debugger in ESTK, you should run the script from the ESTK. In your code somewhere, place the following:

$.level = 1; // sets the debug level to level 1
debugger;

The script should stop with the "debugger" line highlighted. You can then step line by line through your code.

Bob

[_Daniel_Rodney_]

Bob, I did get it to write the "First Entry" but how is that supposed to help me? Am I supposed to tell it many things to write to that log file, such as my variables? I am just not seeing yet how this can help diagnose my crash.

I have also gone through and converted variables to local where possible, but no speed improvement and it still crashes occasioanally, so it's not a naming conflict. I was sure to choose good names. I will keep looking, but it is still perplexing me. It's random and unpredictable, the worst and hardest thing for troubleshooting!

As for the namespace, it seems silly to me to put variables inside another variable. That means another name I must remember, type properly, and more code in general. I just don't see the point when within that namespace you could have conflicts as well. Why not just name it myVariableSomethingOrOther? (Just make sure they are unique names). A namespace just seems like extra work and extra typing and doesn't help conflicts, with can still occur within the namespace. Of course if there is something I am missing please correct me.

[_Daniel_Rodney_]

As for debugging from ESTK, if you are stepping through lines, and then a dialog opens, how are you supposed to proceed? Clicking OK in the dialog seems to finish the script and I can't debug the rest. But I can't through the the dialog either. Thanks.

[_Dave_Saunders_]

Use a breakpoint immediately after the dialog. Or step through the script one-line at a time -- if you rely on the dialog to pause the script, then indeed, when you click OK it will proceed to the end unless you've set a breakpoint.

Dave

[Guest]

Daniel,

For the log to be helpful, you'll need to place log.writeln statements in just about every function. When it crashesy you'll see the function is was in when it did. Then you sprinkle statements in the function to find out what call is killing InDesign. Tedious, yes, but you have to identify what is causing ID to crash.

As for namespaces...

I typically don't write "scripts", I write products. One client's product has well over 40 script files, over 15,000 lines of code, and god knows how many functions and classes. Some sections were written by other team members. Namespaces are the best way to avoid conflicts. Yes, it's more typing, but typing's cheap.

In the process of developing that app, I think I was able to kill InDesign about 6 or 7 different ways. As I write code, any complex function I write has a log.writeln() statement as it's first line. If I need it, I turn debug "on" for the log, and I effectively get a trace of the log. When the function is proven bullet-proof, I remove the function call, or not. I also typically put in code that I use for profiling in every function as I write it.

You don't have to do it. It's just a better approach. I've been writing code professionally for about 30 years. All I am doing is trying to help you with best practices.

Bob

[_Daniel_Rodney_]

Bob, now I can see some advantages of using the namespace, especially if you are writing with other people, etc. Now I understand more of your workflow. My scripts haven't gotten as complex as yours yet and therefore are more simple. But I can see some of the scalability in approach. Thanks for explaining :)

I will have to dig in and log everything to see where the problem is. I have a feeling this will take a while.

Thanks Dave for the breakpoint suggestion, I don't know why I didn't think of that. I guess I was thinking that stepping through would go one step at a time. In ESTK, what's the difference between the bright red and dark red breakpoints?

Thanks all for the help. I really appreciate it. All of you make this forum a great resource and I've learned so much from all of you (in this post and in previous ones).

[_Dave_Saunders_]

The dark red ones are temporarily disabled -- not a feature I use much, except by accident.

Dave