* Plugin editor crashing FH

[DavidNewton]

I was just checking out what kind of error message I would get if I tried to use a reserved word as a variable name. So I wrote in a single line of code

Code: Select all

and='and'

clicked Go and as expected this produced an error message

Code: Select all

An error has occurred - plugin failed to complete
Line 1: unexpected symbol near 'and'
No changes have been made to data records.

So I put spaces either side of the = sign

Code: Select all

and = 'and'

clicked Go and FH stopped working. [Standard message: Family Historian has stopped working and windows is looking for a solution]
I repeated this three times with the same result each time.
As a next step I reversed the order in which I entered the code. That is, put the code with the spaces in first clicked Go and got the error message. I then removed the spaces , clicked Go and FH stopped working again.

I have a significant number of background processes running so perhaps this is interaction with another process. Can anybody confirm this behaviour?

Obviously the code is unlikely to occur naturally but it does raise the eyebrows.

David

[DavidNewton]

It occurred to me after posting that perhaps it was associated with my windows user account. So I logged off and logged in as (built-in) administrator and the problem did not occur. So this problem seems to be user specific.

David

[Jane]

I can't reproduce the error, out of interest you can re-assign some keywords, though quite why you would want to I am not too sure.

So for example you can do

Code: Select all

function messagebox(...)

fhMessageBox(table.concat(arg,'\n'))

end

print = messagebox
print('hello','world')

[DavidNewton]

I am guessing I have some background process running which is conflicting.

Just for the record I have no wish to use reserved words as variables. My interest is in examining the error messages produced by the plugin editor in various circumstances. I should explain, just in case you think I am insane, whenever I want to thoroughly understand something I prepare 'lecture notes' as if I were teaching it to a bunch of students and within them I try to predict the questions they (or in this case I) might want answered.

David

[tatewise]

I cannot reproduce the error either.
David, could you give more specific details about Windows OS, and whether anything else was in the Plugin script.

[DavidNewton]

I am running Windows 8.1 Pro fully updated. I was running FH v 5.0.10 but as that was my most recent installation I restored back a day so I am now running FH v5.0.9 and the problem is still there.

The only other recent installation I have is OpenOffice and I have uninstalled that.

I have conducted further experiments. First the error is independent of the script. Whether the script is totally blank or an existing error-free script the first click of Go is normal and the second crashes FH. I have again switched to the built-in administrator account but this time the problem is there also.

It is spreading, which suggests some sort of malware or virus activity. I am going to run a full malware scan of my machine so I may be AFK for some time.

David

[Jane]

If you save the script before you run it do you get the error? Just wondering if it's something up with your temp folder.

[DavidNewton]

I have run a full AV scan on my computer which found no problems.

In the end I did what I should have done in the beginning. Since the program was being closed by Windows there had to be an entry in the Windows Applications event log. It turns out that the problem was with a dll named msvcr100.dll which apparently is part of the Microsoft Visual C Runtime package. I do have a vague recollection of seeing an installation of Visual C Runtime in the midst of another recent install.

That was the easy bit. Finding a new copy of this dll on the internet was not too hard but replacing the existing dll within the windows\system32 folder was something else. In the end I logged in as the built-in administrator, renamed the old dll and put in a copy of the new one.

So far this seems to have done the trick and the problem has gone away but I am not counting my chickens just yet.

David

[tatewise]

I wonder if simply re-installing FH would have done the trick?

[DavidNewton]

Mike

You are probably right but neither method is hassle free and it is irritating to have to spend all this time and effort because an installer overwrote an existing installation of a redistributable package and, in addition, did it without a warning of the possible consequences for other software.

David

[mjashby]

David,

Don't want to butt in but you might want to make a note of the following as a reasonable source of some key dll's required to run certain programs - http://www.portablefreeware.com/resources.php

The other reasonably quick way for installed programs would have been to uninstall/reinstall the VC++ Runtime package. Probably easier than trying to replace/overwrite an installed dll if Windows doesn't want to let you.

The problem with most software, including Family Historian, is knowing what system software they install/update/change within their own installation processes. i.e. FH doesn't tell you that it requires/installs VC++ or FoxPro runtimes but they end up in your system if you don't already have them. And, what can be even worse is that those dependencies also remain in your system after program uninstallation, even when you don't want/need them anymore! The only real protection is to monitor all software installations to see what they do, but few users are that organised/interested.

Hope you've got everything working reliably again.

Mervyn

[tatewise]

This problem crops up intermittently, so I have added some advice to how_to:family_historian_installation_problems|> Family Historian Installation Problems which gives download links for Microsoft Visual C++ and is based on other member experiences.

[DavidNewton]

Mervyn

I see the problem. After your comment I did a quick search and discovered 19 copies of msvcr100.dll on my system with modification dates ranging from today back to March 2010. (Pity I didn't do that earlier I could have saved myself a download!). These were copies in program folders and hence in use by one piece of software. I think this demonstrates that the Windows ideal view of dynamic link libraries preventing the proliferation of duplicate code modules just does not work.

Mike

A good idea to include something about this in the Knowledge Base. Thanks.

David

[DavidNewton]

Well, as they say, 'This isn't over' It seems that I was too optimistic, not something that is usually a problem for me.

This afternoon I opened FH and tried to run a script and got the standard Windows closing down message, checked the event viewer and the same problem.

So this time I uninstalled and re-installed FH.

Tested the script again and the crash was so fast it didn't even register on the Windows Event log. From that point the crashes were unpredictable. Some projects seemsd to be OK others not. I uninstalled and re-installed on a different hard drive - no change. Then I found my 5.0.7 installer and used that instead of the recent 5.0.10 installer That seemed to do the trick (but for how long, and do I want to be running an old version?). In the interests of completeness I upgraded the 5.0.7 to 5.0.9b and again the problem came back. So at the moment I am running 5.0.7.

Since nobody else has this problem it has to be connected with my windows setup (or a hardware problem) I am going to keep searching for a solution and if I ever find one I will of course report it back here.

David

[jimlad68]

David, I can only suggest you do a System Restore to before you had the problems, and then keep going back until it seems OK. If that does not work an Image restore might be on the cards (ideally on a spare drive in case your image/program is duff).

I have occasionally had "system problems", especially after a spate of trying out a lot of alternative software. Not only has this always done the trick (especially the image restore), takes an hour or few, but it is very cathartic, makes you realise what rubbish builds up. It is usually easy to know what you have lost that needs reinstalling. Just take a note of settings etc you may have changed.

I have also found that since using http://www.liberkey.com/en/catalog-flat-list-view.html and http://portableapps.com/apps on my E: drive (none system) for any programs that can be run as portable apps, I have had much less system problems, and my C: System Drive image backup is much smaller (via Macrium Reflect http://www.macrium.com/), things like VLC, MPC, GIMP, LibreOffice are massive and use thousands of files, the portable apps also keeps the registry smaller.

Best of luck.

[DavidNewton]

JIm

Totally agree about portable software. I am a big fan. I will probably bite the bullet and roll back to factory installation (Windows 7!) and move it on from there. I have failed to keep up to date with Reflect images although I suspect I have a just-post installation image of Windows 8 with all my basic software installed - just have to find it!

Fortunately the portable software attached to my laptop keeps me going while I do this. The silver lining, as you say, is that it will give me a chance to get rid of some of the rubbish.

David

[mjashby]

David,

Not FH related, but you might want to check this report of a similar problem

"An improperly typed Lua script can crash Foldit" - http://fold.it/portal/node/996624

Reading that report suggests that there is a bug in Lua 5.1 that fails to trap certain typing errors - In the case reported substituting a lower case l (L) for a Capital I (i) produced an identical program crash to yours except in a different software app.

Perhaps the whole problem relates back to your "what happens if I do this?" testing.

Mervyn

[DavidNewton]

Mervyn

You are probably correct regarding the initial problem and maybe my initial test did find a bug in the Lua interpreter.

I have rolled back my system by 2 weeks to no effect and now I believe my Windows system in its interaction with FH is unstable (surprise ). The crash occurs at second run of every script I have tried, valid or otherwise, and is again showing no entry in the event log. Also from time to time it locks up Windows Explorer to the extent that I have to do a hard reset.

It is time to reinstall Windows and that is what I shall be doing today.

David

[tatewise]

David, have you tried the KB advice of un-installling C++ and then installing FH or the C++ package?

[mjashby]

David,

The very best of luck if you go the full Windows/Program reinstall route. Stay cheerful and look on the bright side: At least you'll have a clean system at the end of the process.

Mervyn

P.S. It makes me so grateful that I mainly use Virtualbox/Virtual Windows Systems! Just have to copy the system to an external drive prior to any significant change, and copy it back if anything goes seriously wrong.

[DavidNewton]

Mike & Mervyn

Thanks for the comments. I did try the uninstall/reinstall of VC++ and FH and it didn't help. In the end it seemed to be the least painful route to re-install windows (I have yet to find out if it is not painful, I am currently using my laptop while the desktop downloads 8.1.) If this does not solve the problem, trust me. I'll be back.

David

[DavidNewton]

Ok that was disappointing. I am now running a clean installation of Windows 8.1 Pro and FH is the only program installed. I ran FH, registered my key, installed no plugins, and opened and tested the sample project - no problem. Thinking all was well I copied in the projects from my backup drive, opened my current working project and the problem mentioned in the opening post is still there, except now there is no message from Windows - the program simply shuts down.

So I deleted all my projects (not the Sample) and then copied them in and tested them one-by-one. This problem only occurs with the one project.

I have no idea how the plugin editor can be affected by the project. In the interests of completeness I decided to test a known working plugin with this project to see what would happen.so I installed the Clone Any Record plugin. That seemed to work perfectly on this project.

So I am mystified and since the test script does not in any way do anything other than check for an error message I am going to ignore this 'problem' and only worry about it again if it affects a useful working script.

David

Added in Edit: I am very bad at giving up so as a final fling I checked the project folders for each of my projects and discovered that my working project folder did not have a Public sub-folder. So I copied one in from one of the other projects and that seems to have solved the problem! Can this really be all it was? And the answer to that question is No. The crashes went away briefly and then came back and now I am going to stop worrying about it.

[mjashby]

David,

Interesting.

It's certainly likely that, if your script referenced a non-existant location and required some action to be performed in relation to that location, then it would terminate the script with an error. If your script is operating as a FH plug-in rather than running independently it could then, presumably, freeze/crash the parent program as it wouldn't be able to complete the set action.

Perhaps one of the Lua plug-in 'specialists' will be able to verify if this is the likely outcome.

Mervyn

[DavidNewton]

At this point I am becoming totally befuddled as to why this problem does not affect all my projects.

I am currently writing a small plugin to pack out my (text) Id numbers with leading 0's so that they will sort numerically. It's a toggle, so testing means running it twice. On (a copy of) my working file the second run crashes the file. On some other files it does not crash the file. It does not appear to be related to file size. It works perfectly well on a file of twice the size which in fact contains my working file as a sub-tree and equally it works on one very small file I have just started.

The trigger for crashing seems to be running the same script more than once, sometimes it takes 3 times to crash but mostly 2.

I will freely confess that at this point I am starting to consider changing my main working to one of the other applications I have installed. Since the plugin facility is a major plus for FH, if it fails then it is no longer a plus. So far I am fairly sure that I have lost no data since once I realised there was a problem I refrained from entering new data, and of course all my existing data is backed up. But the Edit>Undo facility of FH, which provides a safety net for plugins which alter data. also means that using a plugin will require a save before using to ensure that a crash does not remove the work you have just been doing.

I realize that this problem is not solvable, unless someone else experiences it, because I am not prepared to pass over my project files. However, I do have a laptop running Windows 7 so I will move my files to that and see if the problem goes away.

David

[mjashby]

David,

I'm not really clear what you are trying to do with you plugin/script. It may be just the terminology of course, fuelled by your understandable frustration at all of the weird and apparently inconsistent crashes.

I'm not a programmer, but there seems to be a mix-up in your opening description of what it is you are trying to achieve, i.e. you can't sort text IDs numerically and if you pad the front of a text ID with 0's all you are doing is creating a longer text ID, not a numerical ID, so it is still not possible to sort them numerically.

The plugin feature of Family Historian is of course, in reality, just a link to the Lua programming language files that have been included with FH5 and it sounds as if you may be either trying to do something that Lua isn't capable of, or you may have some syntax problems which are causing your script to terminate (and crash FH) when certain conditions are/aren't met.

Perhaps if you could share your Lua script (not your data), some knowledgeable person may be able to either identify any obvious problems or, alternatively, confirm that the script should work as intended.

Mervyn