Script randomly exits for seemingly no reason with strange traceback

[Andrew Berg]

It's a rare occurrence, but sometimes my script will terminate and I get
this:

Traceback (most recent call last):
File "C:\path\to\script\script.py", line 992, in <module>

That's it. And the line number is always the last line of the file
(which in my case is a blank line). I have not seen this on Linux (where
my script can run for days or weeks on a remote server), but only on
Windows where I do most of my testing (and it typically only runs for
minutes at a time). There may be bugs in my program, but I don't see how
Python should ever print a traceback like this.
--
CPython 3.2.2 | Windows NT 6.1.7601.17640

[Steven D'Aprano]

On Fri, 03 Feb 2012 14:14:57 -0600, Andrew Berg wrote:

> It's a rare occurrence, but sometimes my script will terminate and I get
> this:
>
> Traceback (most recent call last):
> File "C:\path\to\script\script.py", line 992, in <module>
>
> That's it. And the line number is always the last line of the file
> (which in my case is a blank line).

Is it reproducible? That is, can you demonstrate a script which will
*always* show this failure?

> I have not seen this on Linux (where
> my script can run for days or weeks on a remote server), but only on
> Windows where I do most of my testing (and it typically only runs for
> minutes at a time). There may be bugs in my program, but I don't see how
> Python should ever print a traceback like this.

Which version of Python, which version of Windows?

If you upgrade Python, does the problem go away?

If you perturb your script (add a few blank lines at the end, or a
comment), does it go away?


--
Steven

[inq1ltd]

Check your code in that module for open parenthesis something like below..
Most likely your code is looking for the closing parenthesis.
Start at the bottom and move up.

pink = str(self.RecordKey[2] <--missing ")"

jimonlinux

[Steven D'Aprano]

On Fri, 03 Feb 2012 19:15:30 -0500, inq1ltd wrote:

> Check your code in that module for open parenthesis something like
> below.. Most likely your code is looking for the closing parenthesis.
> Start at the bottom and move up.
>
> pink = str(self.RecordKey[2] <--missing ")"

If that were the case, the module wouldn't run at all, it would
consistently raise SyntaxError before running.



--
Steven

[Chris Angelico]

On Sat, Feb 4, 2012 at 7:14 AM, Andrew Berg <bahamut...@gmail.com> wrote:
> It's a rare occurrence, but sometimes my script will terminate and I get
> this:
>
> Traceback (most recent call last):
>  File "C:\path\to\script\script.py", line 992, in <module>

Do you call on potentially-buggy external modules? I'd be curious to
see if this can happen if a module somehow sets an "error state" in
the interpreter, without actually raising an error - or,
alternatively, if a module has some kind of cleanup code that returns
failure. Unfortunately I don't have facilities for testing that, at
the moment.

ChrisA

[Andrew Berg]

On 2/3/2012 5:25 PM, Steven D'Aprano wrote:
> Which version of Python, which version of Windows?

I keep that information in my signature for every post I make to this list.

CPython 3.2.2 | Windows NT 6.1.7601.17640

> If you upgrade Python, does the problem go away?

I use the most recent stable version. It would be hard to say if the
problem went away since it's rare and random AFAICT.

On 2/3/2012 9:15 PM, Chris Angelico wrote:
> Do you call on potentially-buggy external modules?

It imports one module that does little more than define a few simple
functions. There's certainly no (intentional) interpreter hackery at work.

[Steven D'Aprano]

On Sat, 04 Feb 2012 10:32:25 -0600, Andrew Berg wrote:

> On 2/3/2012 5:25 PM, Steven D'Aprano wrote:
>> Which version of Python, which version of Windows?
> I keep that information in my signature for every post I make to this
> list. CPython 3.2.2 | Windows NT 6.1.7601.17640

Why so you do. Did you expect that people would read it? As a rule, sigs
fade into the background -- my mail client colours it grey, my news
client colours it light blue, and I generally don't even notice it.

The Zen of Python applies here: explicit is better than implicit.

>> If you upgrade Python, does the problem go away?
> I use the most recent stable version. It would be hard to say if the
> problem went away since it's rare and random AFAICT.

I suggest you raise an issue on the bug tracker. If you can't reproduce
the bug, it's unlikely to be fixed, but you might get lucky.


--
Steven

[Andrew Berg]

On 2/4/2012 11:06 AM, Steven D'Aprano wrote:
> I suggest you raise an issue on the bug tracker. If you can't reproduce
> the bug, it's unlikely to be fixed, but you might get lucky.

Since I can't narrow it down to any specific circumstance or code, I'll
gather information from a build of the interpreter with debugging
enabled first.

--

[Chris Angelico]

On Sun, Feb 5, 2012 at 3:32 AM, Andrew Berg <bahamut...@gmail.com> wrote:
> On 2/3/2012 9:15 PM, Chris Angelico wrote:
>> Do you call on potentially-buggy external modules?
> It imports one module that does little more than define a few simple
> functions. There's certainly no (intentional) interpreter hackery at work.

If it's safe for you to do so (copyright/licence etc), it may be worth
posting the code along with your bug report, just in case. I had some
REALLY weird issues from embedding Python that derived, ultimately,
from buggy ref management - one such case came from forgetting to
incref None; it took me a long time to track it down, because the
problem didn't actually surface until the interpreter was shutting
down.

ChrisA

[John Nagle]

On 2/4/2012 12:43 PM, Chris Angelico wrote:
> On Sun, Feb 5, 2012 at 3:32 AM, Andrew Berg<bahamut...@gmail.com> wrote:
>> On 2/3/2012 9:15 PM, Chris Angelico wrote:
>>> Do you call on potentially-buggy external modules?
>> It imports one module that does little more than define a few simple
>> functions. There's certainly no (intentional) interpreter hackery at work.

Are you doing a conditional import, one that takes place after load
time? If you do an import within a function or class, it is executed
when the code around it executes. If you import a file with a
syntax error during execution, you could get the error message you're
getting.

John Nagle

[Andrew Berg]

On 2/15/2012 3:28 PM, John Nagle wrote:
> Are you doing a conditional import, one that takes place after load
> time? If you do an import within a function or class, it is executed
> when the code around it executes. If you import a file with a
> syntax error during execution, you could get the error message you're
> getting.

It does have conditional imports, but the tracebacks don't occur while
that function is running (it's executed once, and this happens well after).