`inspect.stack` throws IndexError when looking for `__main__` (we think) but only rarely

[py2exe]

`inspect.stack` throws IndexError when looking for `__main__` (we think) but only rarely

[albertosottile]

Thanks for reporting this. I gave a look at the original issue. I would say that without further analysis on the crashing system (e.g. attaching a debugger or inserting some debug printouts in your code or in cpython/inspect) debugging this would be borderline impossible... It looks to me that something is weird in either the passed frame or in the detected number of lines or in the detected source code but, without further inspections on site, I do not really know how to help you.

In any case, I do not see how py2exe could cause this only in certain cases: this seems either a feature that is always utterly broken (e.g. inspect does not work well with zipextimporter or any other critical component of py2exe) or it should always work.

Which brings me to the next question: are you sure that this inspecting system works well when embedded via py2exe? Your code looks quite complicated so I am not sure but, it might also be that something else is crashing in the system of your user and this is what basically happens when your logging infrastructure/frame inspection is triggered from the embedded executable...

I hope this helped a little. I am available for further assistance if you can provide any further information on the issue.

[Athanasius]

In any case, I do not see how py2exe could cause this only in certain cases: this seems either a feature that is always utterly broken (e.g. inspect does not work well with zipextimporter or any other critical component of py2exe) or it should always work.

My only thought on this is to wonder if it might be tickling some subtle difference depending on exact CPU, cache sizes, memory layout of the structures and the like.

Which brings me to the next question: are you sure that this inspecting system works well when embedded via py2exe? Your code looks quite complicated so I am not sure but, it might also be that something else is crashing in the system of your user and this is what basically happens when your logging infrastructure/frame inspection is triggered from the embedded executable...

Yes, we have 1000s of users every day utilising that exact .exe without problems. The program just doesn't even start fully when it breaks. We get some idea about the usage from data it sends to a Gateway/exploder for others to make use of that data ( See https://eddn.edcd.io/#software ).

I hope this helped a little. I am available for further assistance if you can provide any further information on the issue.

I'll see if I can get some further response from the reporter. The release we made today adds try/except around the troublesome call to see if it can then continue, or starts failing in even weirder ways.

[albertosottile]

Any news on this?

[Athanasius]

It's still only that one user that has had the issue. We implemented a workaround (try/except that bit of code and return dummy fields if it trips). I think you can go ahead and close this, we'll comment again if we get any further useful information.

I still suspect this has to be Anti-Virus or the like getting in the way.