* Plugin Runs in Debugger - Crashes in Live

[quarlton]

Hi

Can anyone suggest why a plugin, that I have written, runs perfectly well when run from the editing window, but fatally crashes FH - 'Family Historian has stopped working' - when run from the Plugin List?

FH 6.2
Windows 10
Plugin reports data only, no changes.

Many thanks

[tatewise]

Family Historian has stopped working is just a warning from Windows that FH has not had a dialogue with Windows for some time, rather than a fatal crash.

I suspect the Plugin is performing some long-winded search loop or may not be completing a loop, and is not having any dialogue with Windows. If you wait long enough it may eventually complete OK. Is the Project database very large?

Does it actually run to completion in Plugin Editor/Debug window?

The way to keep Windows happy is to insert an fhSleep(100,100) function within long loops, but only once say every 1000 loops, or use the plugins:code_snippets:progress_bar|> Progress Bar (code snippet).

Does the Plugin run OK on the Family Historian Sample Project?

If the Plugin is not too large, then ATTACH it to this thread and I will have a look at it.

[quarlton]

Hi Mike

Yes, exactly the same issue using the Sample Project.

Plugin runs to completion in Editor/Debug window.

Run time on Sample Project is approx 2 seconds and returns 152 rows.

Once get the FH has stopped working message, it displays a modal message box saying Windows will close the program.

• Basically, the plugin steps through every INDI record
  • Then through every child item for that INDI
    • If child is a FACT looks for an associated SOUR entry
      • If found, looks to see if valid 'Date Source Recorded' date
        • If not, stores data in table

Source is only 3k (71 lines), so copy attached.

Many thanks for taking the time to help.

[tatewise]

Well that is reeeeeally strange!!
Initially, after installing your Plugin, it crashed FH everytime as you say.
Then, after a few diagnostic adjustments in a copy of the Plugin, I got it running OK.
But then the original ran OK too!!!!

So I tried Logoff and Login - no change.
Then tried Restart and Login - and your original Plugin crashed, my variant ran OK, and that made yours run OK.

The changes I made were to scrap the pi4:MoveTo(pi) and pi:MoveTo(pi4) and use pi4 instead of pi as the Fact pointer - as you were already planning.
Also deleted the fhCallBuiltInFunction("RecordId", pi) and used table.insert(tblRecID, fhGetRecordId(pi) ) instead.

It seems as if some FH/Lua library code is not invoked correctly by your Plugin, but once a similar Plugin gets it invoked correctly, everything runs OK, and only a Reboot/Restart gets the error back.

I will investigate a bit further to see if I can unearth what is going on.

[quarlton]

Thanks Mike.

A very strange one indeed.

I'll make the changes to my copy and then I might trim it back and see if I can come up with anything to point in the right direction.

As usual, thanks for your help.

[quarlton]

Hi Mike

I've just done some testing and I think I might have found where, but not why, it's failing.

If I comment out the results display then it runs the rest of the code fine.

So then I looked at some other examples and found that I hadn't got a fhOutputResultSetTitles() command.

I didn't think that it was obligatory, but after adding it, everything works!

A bit bizarre?

[UPDATE] - Not 100% perfect.
Ran it 10 times and had a crash. Reloaded and next 20 runs OK, so there is still something slightly amiss.

[tatewise]

Yes, I was heading in a similar direction, but nothing firm.
You are perfectly correct about fhOutputResultSetTitles().
I now cannot get the original Plugin to fail at all.

[quarlton]

Yes, strange.

In case you are wondering why I wrote this particular plugin:

1. I wanted to get some more experience with Lua in FH
2. Wanted the challenge
3. It meets a need


There are mixed opinions on the use of 'Entry Date' for sources.
For our convenience we choose to use it as the date we added the source citation the the event.

In our early days of using FH we didn't use it, so now we have a number of entries with no date.
The plan was to find out how big the problem is and then add a default date where there isn't one, so that we know that from this moment on if we find a missing date then it is a recent issue and can address it.

So next step is to work out how to add a date record to an existing source

Thanks again for your help

[tatewise]

You are correct about the various ways Entry Date is used, but it is not intended to be the date the Source Citation was added, because from a genealogical point of view that date is not relevant.

The question is, if you are going to record that Source Citation added date, then why not the date you added each Individual record, or added each Fact, or added each Multimedia record?

Such dates are of no possible interest to anyone who might inherit your database.

[quarlton]

Yes, I think we are going to have agree to disagree on this point

The way I see it is that the database needs to suit the user's needs as well as the genealogical needs.

Ideally I would love creation dates for all records as opposed to just mod dates for INDI and OBJE records etc.
Too many years having to show audit trails for data creation and modification (including what was there before) I'm afraid.


Time for bed....

[tatewise]

I am beginning to wonder if the problem is due the changes made in FH V6 to help speed up the listing of Plugin Result Sets, which were extremely slow, especially when particularly large.

So if we both try to capture the error message and post a screenshot here, I will notify Calico Pie.
Remember to expand any More Details... options in the error message to show as much details as possible.

If you need help writing the Plugin script to set the Entry Date then let me know.

[quarlton]

I tried it again this morning after making a couple of tweaks and it went back to crashing every time when run 'Live'.

Again, it was a mod to the tables. I added an extra table, insert, and display.

Deleting the mod made no difference.

When I reverted to last night's saved copy it all worked again.

When it crashes I simply get the Windows message - see below

Thanks for the offer of help with the insert date, I'll have a go this morning and see how I get on.

[tatewise]

Interesting. When it failed on my Vista PC that message was supplemented with another more detailed report as shown below, and I have captured those Temp files, but the 3rd one is a memory dump too large to attach here.

EDIT: I have also discovered the following problem signature:
Problem signature
Problem Event Name: BEX
Application Name: Fh.exe
Application Version: 6.2.0.2
Application Timestamp: 56fd32bb
Fault Module Name: MSVCR100.dll
Fault Module Version: 10.0.40219.325
Fault Module Timestamp: 4df2be1e
Exception Offset: 0008af3e
Exception Code: c0000417
Exception Data: 00000000
OS Version: 6.0.6002.2.2.0.768.3
Locale ID: 2057
Additional Information 1: c7c4
Additional Information 2: abaacd74736ba5c3e29282bf4dc45a5b
Additional Information 3: acdb
Additional Information 4: 4f9cc3553aa05b8151462d43153a280c

[tatewise]

I reported this to Calico Pie as [#447616] Plugin Result Set Crash but they cannot reproduce the crash, and therefore cannot diagnose the problem. I have sent more details and suggestions, but no further developments as yet.