Rhino crashing while trying to open a 3dm file on idle event

[piac (Giulio Piacentino)]

Continuing the discussion from Multithreading with rhinocommon:

@Matteoz991

[…] another question… i’m having some bug report from costumers about rhino crashing while tring to open a 3dm file on idle event of rhino and doing some work on rhino geometries right after RhinoDoc.ReadFile() function.
The call stack that i get is always going to say:
Exception has been thrown by the target of an invocation. —> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Making me wonder that some c++ ptr has been changed while i’m performing a loop in rhino objects right after loading the file… the code on idle event is like this:

public void RhinoAppIdle(object sender, EventArgs e)
{
RhinoApp.Idle -= RhinoAppIdle;

    RhinoDoc.ReadFile(fullPathFileToLoad, fileReadOptions);
    //SettingTolleranceOnRhinoDoc
    //SettingDefaultLayerOnRhinoDoc
    //ReadingOffsetsFromAXml
    Transform translation = Transform.Translation(offsetX, offsetY, offsetZ);
    int layerIndexDefault = RhinoDoc.ActiveDoc.Layers.FindByFullPath("DEFAULT_LAYER", true);
    var rhinoObjects = RhinoDoc.ActiveDoc.Objects.FindByLayer(RhinoDoc.ActiveDoc.Layers[layerIndexDefault]);
    List<GeometryBase> listGeometryBases = new List<GeometryBase>();

    if (rhinoObjects == null || rhinoObjects.Length <= 0)
        return;

    foreach (var rhinoObject in rhinoObjects)
    {
        GeometryBase geometryBase = rhinoObject.Geometry;
        if (geometryBase == null)
            continue;

        GeometryBase duplicatedGeometryBase = geometryBase.Duplicate();
        if (translation != Transform.Identity)
            duplicatedGeometryBase.Transform(translation);
        listGeometryBases.Add(duplicatedGeometryBase);
    }
    //then add geometries to RhinoDoc from listGeometryBases
}

The main problem is that i cant repeat the error in my computer… just to test it i’ve notice that if i put only the read file function in the Invoke of the rhino main window i have to put a RhinoApp.Wait(); to see the objects loaded using FindByLayer… but if i put inside the Invoke call all the code in the idle event i dont need to call to Wait()… so more questions comes in my head… do i have to put a RhinoApp.Wait() always to let rhino end his jobs? Is there anything that need to be done after reading a file?

[piac (Giulio Piacentino)]

This question is particularly environment-related. Are you just trying to Open the file?

If not, are you using Batch, Insert or New modes?

If yes, are you using Rhino 5 on Windows or on Mac or Rhino WIP? In WIP, we suggest to use RhinoDoc.Open(), which works differently on Win and on the Mac (Mac Rhino is multi-object). That is also the best method to call if you have access to it. Otherwise, I would suggest OpenFile(). Can you have a look at this? You can also just script the Open command.

[Matteoz991]

Using Rhino5 on Windows. with this declaration for read options
var fileReadOptions = new Rhino.FileIO.FileReadOptions();
fileReadOptions.ScaleGeometry = false;
fileReadOptions.BatchMode = true;
fileReadOptions.NewMode = true;
I can’t use RhinoDoc.Open() since it is in Rhino6 and we dont use it yet… and yes i know about OpenFile and scripting but the problem remain… it works on my computer… but sometimes crash on customers computers… I really dont know how to force the error to come out… but after putting all the code that the idle event is running in the Invoke of the rhino main form the functions break on Add() or Duplicate() functions… never more in the readfile… but who knows… maybe tomorrow i’ll get an email (i get an email on bugs that force the application to close) with the call stack of some customer with a crash on it since is not happening that often…
I was wondering if some of you looking at the code in read file function could find out something… and Why if i run the code in the idle event and i put the readfile function in the invoke of the rhino mainform after it, using RhinoApp.Wait() before getting rhinoObjects from the ActiveDoc change the behavior?

[piac (Giulio Piacentino)]

I don’t know, but thanks for the detailed explanation. Let’s see if @stevebaer knows or encountered this.

[Matteoz991]

you mean @stevebaer ?

[Matteoz991]

meanwhile, as i suspected, i got an email with a crash
at UnsafeNativeMethods.RHC_RhinoReadFile(String _path, IntPtr pOptions)
at Rhino.RhinoDoc.ReadFile(String path, FileReadOptions options)
called inside the invoke from the rhino main window… during the idle event…

[piac (Giulio Piacentino)]

I’d like Steve’s opinion on this, but my first guess is that the Idle event should call a command. That is because any RhinoDoc operation is thought to happen inside a command, usually.

Only from the command, then, you would call the ReadFile method.

[Matteoz991]

However i’ve see in the environment call stack that the idle event is invoked by the Rhino main window so the invoke isn’t required… and about beeing inside a command my plugin don’t even implement a run function. It create a new class on load event wich wait a udp call to show a wpf docked above Rhino… so i cant even use the Rhino doc from it…

[piac (Giulio Piacentino)]

Whatever you are up to, to do anything to the document you need to be in a command. Rhino uses the command information to store Undo information (and more) – that is why you usually need to do that. In the idle event, you should call a command with the RhinoApp.RunScript("_MyCommand", false) method. Then, your command’s RunCommand method will be run. There, but nowhere else, you can safely do stuff to the document.

Alternatively, your UI can invoke the command directly, always with the method above. This is the usual way for all our standard toolbars.

Peraltro, se sei italiano possiamo anche scrivere in italiano.

[Matteoz991]

I have read about those problems working with RhinoDoc.ActiveDoc… will try to move the code to some commands. Thanks for your feedback.

Si sono italiano ma preferisco l’inglese così se qualcun altro ha lo stesso problema può leggere (anche se il mio inglese non è un gran che).

[piac (Giulio Piacentino)]

@Matteoz991

Si sono italiano ma preferisco l’inglese così se qualcun altro ha lo stesso problema può leggere (anche se il mio inglese non è un gran che).

Grazie Matteo!

[Matteoz991]

I may ended up resolving the crashes. Moving the code to scripts and refactoring a bit of that legacy code made me found some functions that was closing the views from C# code. After moving the code closing and leaving a single top view in a script it’s been more than 3 weeks that i dont have a crash from customers.

So lesson learn: Dont close views from C# and immediatly after open a rhino file and vice versa, instead close them from a script and wait it to end.

Hope it will help someone else.

Matteo.

[piac (Giulio Piacentino)]

Interesting. Thanks for the heads up.
I think a crucial point here is having moved logic to an independent command.