Topics

[users] `import uuid` raises `System.AccessViolationException`

Stéphane Lozier
 

Thanks for the report. I haven't been able to reproduce on my machine so it makes it hard to figure out where the issue might be. Have you tried a stripped down version of uuid (e.g. with only the code that would execute on import) to try and pinpoint the problem? Just going by the log you linked possible candidates would be:
ctypes.CDLL(ctypes.util.find_library("uuid"))
ctypes.CDLL(ctypes.util.find_library("c"))
ctypes.windll.rpcrt4


On Mon, Nov 12, 2018 at 9:04 PM <gtalarico@...> wrote:

I am using a project that ships embedded ironpython 2.7.7 and I have it deployed to a few dozen users.
Recently we started receiving reports of fatal exceptions on the parent application whenever it tried to execute ironpython code.

I narrowed the error down to a `import uuid` statement - I replaced `uuid` with `System.Guid.NewGuid` and the exception went away.

Is anyone aware of any issues related to the uuid module that could cause AccessViolationException?
The only thing I could find on uiud + AccessViolationException is this log from a few years ago, but it's referencing 2.7.2
I also didn't see any issues or bug reports related to 2.7.7

A detailed write up of the issue is here:
https://github.com/eirannejad/pyRevit/issues/413

Thanks!

IronPython 2.7.7 (IronPython 2.7.7 (2.7.7.0) on .NET 4.0.30319.42000 (64-bit)) 

Alex Earl
 

Is it only the import of uuid that is causing the issue, or are actual methods in uuid called? I noticed that there is a check for sys.platform == 'win32' in at least one place which will not work on IronPython. 




On Mon, Nov 12, 2018 at 9:01 PM Stéphane Lozier <stephane.lozier@...> wrote:
Thanks for the report. I haven't been able to reproduce on my machine so it makes it hard to figure out where the issue might be. Have you tried a stripped down version of uuid (e.g. with only the code that would execute on import) to try and pinpoint the problem? Just going by the log you linked possible candidates would be:
ctypes.CDLL(ctypes.util.find_library("uuid"))
ctypes.CDLL(ctypes.util.find_library("c"))
ctypes.windll.rpcrt4

On Mon, Nov 12, 2018 at 9:04 PM <gtalarico@...> wrote:

I am using a project that ships embedded ironpython 2.7.7 and I have it deployed to a few dozen users.
Recently we started receiving reports of fatal exceptions on the parent application whenever it tried to execute ironpython code.

I narrowed the error down to a `import uuid` statement - I replaced `uuid` with `System.Guid.NewGuid` and the exception went away.

Is anyone aware of any issues related to the uuid module that could cause AccessViolationException?
The only thing I could find on uiud + AccessViolationException is this log from a few years ago, but it's referencing 2.7.2
I also didn't see any issues or bug reports related to 2.7.7

A detailed write up of the issue is here:
https://github.com/eirannejad/pyRevit/issues/413

Thanks!

IronPython 2.7.7 (IronPython 2.7.7 (2.7.7.0) on .NET 4.0.30319.42000 (64-bit)) 

Alex Earl
 

Ok, this makes more sense now. IronPython 2.7.7 did not have good support for ctypes. So, if the module is using ctypes, I can definitely see it could be having issues. If you can, I would recommend upgrading to 2.7.9 which had a lot of work done on ctypes.


On Tue, Nov 13, 2018 at 4:45 AM <gtalarico@...> wrote:
The Exception is raised on the import statement, so it must be something at the module level code that's causing the error. (never gets method calls)

What's very strange to me, is that the code still runs fine in most of our machines with the same ironpython version installed but not others.
Could be a conflict with specific dotnet builds? 

https://github.com/IronLanguages/ironpython2/blob/master/Src/StdLib/Lib/uuid.py#L458

PS: forgot to include: all computers in question are running windows 10 x64

Alex Earl
 

I just downloaded the IronPython 2.7.7 release and I tried "import uuid" on a Windows 10 x64 machine and I didn't get the same issue. Perhaps there is something in the setup that is missing in your description.


On Tue, Nov 13, 2018 at 4:47 AM Alex Earl <slide.o.mix@...> wrote:
Ok, this makes more sense now. IronPython 2.7.7 did not have good support for ctypes. So, if the module is using ctypes, I can definitely see it could be having issues. If you can, I would recommend upgrading to 2.7.9 which had a lot of work done on ctypes.

On Tue, Nov 13, 2018 at 4:45 AM <gtalarico@...> wrote:
The Exception is raised on the import statement, so it must be something at the module level code that's causing the error. (never gets method calls)

What's very strange to me, is that the code still runs fine in most of our machines with the same ironpython version installed but not others.
Could be a conflict with specific dotnet builds? 

https://github.com/IronLanguages/ironpython2/blob/master/Src/StdLib/Lib/uuid.py#L458

PS: forgot to include: all computers in question are running windows 10 x64

Gui Talarico
 

Thanks for looking into this Alex.

I cannot reproduce this on my machine either, but I can in a few of my coworkers' laptops.
As I mentioned, this only happens in some computer but not others.
In some cases, they are the same hardware and same image, but users are allowed to install whatever they want.

Is it possible that the installed .NET version could cause this error to happen to some users only?
Could this be an edge that only happens in certain environments? As it was the case here

Alex Earl
 

If you can, open up uuid.py and add some logs to determine how far it is getting in there or where the failure is actually occurring? Also, if you can get a stack trace, that would be useful. 


On Tue, Nov 13, 2018 at 9:24 AM <gtalarico@...> wrote:

Thanks for looking into this Alex.

I cannot reproduce this on my machine either, but I can in a few of my coworkers' laptops.
As I mentioned, this only happens in some computer but not others.
In some cases, they are the same hardware and same image, but users are allowed to install whatever they want.

Is it possible that the installed .NET version could cause this error to happen to some users only?
Could this be an edge that only happens in certain environments? As it was the case here

Gui Talarico
 

The code is running and crashing inside an embedded ironpython engine, 
and the error causes the parent app to crash without any msgs or traceback info.

I was only able to see the error for the first time when I attached VS debugger's to the parent app, otherwise, it was a silent crash. This was all I got:

I will try to install 2.7.7 standalone release in one of the failing 
computers to see if I can reproduce it outside the embedded engine


On Tue, Nov 13, 2018 at 11:26 AM Alex Earl <slide.o.mix@...> wrote:
If you can, open up uuid.py and add some logs to determine how far it is getting in there or where the failure is actually occurring? Also, if you can get a stack trace, that would be useful. 

On Tue, Nov 13, 2018 at 9:24 AM <gtalarico@...> wrote:

Thanks for looking into this Alex.

I cannot reproduce this on my machine either, but I can in a few of my coworkers' laptops.
As I mentioned, this only happens in some computer but not others.
In some cases, they are the same hardware and same image, but users are allowed to install whatever they want.

Is it possible that the installed .NET version could cause this error to happen to some users only?
Could this be an edge that only happens in certain environments? As it was the case here

Alex Earl
 

Do you know if the people who are seeing the issue are running a different bitness of the .NET framework itself? You can still run a 32-bit framework on an x64 machine. 


On Tue, Nov 13, 2018 at 9:39 AM Gui Talarico <gtalarico@...> wrote:
The code is running and crashing inside an embedded ironpython engine, 
and the error causes the parent app to crash without any msgs or traceback info.

I was only able to see the error for the first time when I attached VS debugger's to the parent app, otherwise, it was a silent crash. This was all I got:

I will try to install 2.7.7 standalone release in one of the failing 
computers to see if I can reproduce it outside the embedded engine


On Tue, Nov 13, 2018 at 11:26 AM Alex Earl <slide.o.mix@...> wrote:
If you can, open up uuid.py and add some logs to determine how far it is getting in there or where the failure is actually occurring? Also, if you can get a stack trace, that would be useful. 

On Tue, Nov 13, 2018 at 9:24 AM <gtalarico@...> wrote:

Thanks for looking into this Alex.

I cannot reproduce this on my machine either, but I can in a few of my coworkers' laptops.
As I mentioned, this only happens in some computer but not others.
In some cases, they are the same hardware and same image, but users are allowed to install whatever they want.

Is it possible that the installed .NET version could cause this error to happen to some users only?
Could this be an edge that only happens in certain environments? As it was the case here

Stéphane Lozier
 

Have you looked at the Event Viewer application logs? They usually capture .NET stack traces when an application crashes.

On Tue, Nov 13, 2018 at 11:49 AM Alex Earl <slide.o.mix@...> wrote:
Do you know if the people who are seeing the issue are running a different bitness of the .NET framework itself? You can still run a 32-bit framework on an x64 machine. 

On Tue, Nov 13, 2018 at 9:39 AM Gui Talarico <gtalarico@...> wrote:
The code is running and crashing inside an embedded ironpython engine, 
and the error causes the parent app to crash without any msgs or traceback info.

I was only able to see the error for the first time when I attached VS debugger's to the parent app, otherwise, it was a silent crash. This was all I got:

I will try to install 2.7.7 standalone release in one of the failing 
computers to see if I can reproduce it outside the embedded engine


On Tue, Nov 13, 2018 at 11:26 AM Alex Earl <slide.o.mix@...> wrote:
If you can, open up uuid.py and add some logs to determine how far it is getting in there or where the failure is actually occurring? Also, if you can get a stack trace, that would be useful. 

On Tue, Nov 13, 2018 at 9:24 AM <gtalarico@...> wrote:

Thanks for looking into this Alex.

I cannot reproduce this on my machine either, but I can in a few of my coworkers' laptops.
As I mentioned, this only happens in some computer but not others.
In some cases, they are the same hardware and same image, but users are allowed to install whatever they want.

Is it possible that the installed .NET version could cause this error to happen to some users only?
Could this be an edge that only happens in certain environments? As it was the case here