This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kevinwatters
Recipients kevinwatters
Date 2008-11-21.17:20:04
SpamBayes Score 0.00091395754
Marked as misclassified No
Message-id <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
In-reply-to
Content
After releasing a Py_DEBUG build to some users who were experiencing 
problems, I noticed a pattern in some of the crash reports I got back:

msvcr90d!_wassert+0xb64
python25_d!FILE_TIME_to_time_t_nsec+0xac
python25_d!attribute_data_to_stat+0x67
python25_d!win32_wstat+0x6f
python25_d!posix_do_stat+0x51
python25_d!posix_stat+0x24
python25_d!PyCFunction_Call+0x65
python25_d!call_function+0x34f
python25_d!PyEval_EvalFrameEx+0x4741

The only way I can see _wassert being hit in FILE_TIME_to_time_t_nsec is 
in the Py_SAFE_DOWNCAST used to downcast an __int64 to int. 
Py_SAFE_DOWNCAST checks that there is equality between the casted and 
non-casted values with Py_DEBUG enabled--maybe in this function we 
should remove Py_SAFE_DOWNCAST?

I can't find a way to see the actual value for "in" before the assert is 
hit--I'm unfamiliar with picking through minidumps with WinDbg, which 
for some reason will show me the stack for these dumps when Visual 
Studio won't. But if I need to investigate more about them I can.
History
Date User Action Args
2008-11-21 17:20:07kevinwatterssetrecipients: + kevinwatters
2008-11-21 17:20:06kevinwatterssetmessageid: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
2008-11-21 17:20:05kevinwatterslinkissue4379 messages
2008-11-21 17:20:04kevinwatterscreate