[issue14613] time.time can return NaN
matham added the comment:
Hi guys,
I'm running into this issue on windows 7 using python 2.7.8 (x86) from the
python website.
The following exception occurs while cython code calls a python function which
emits a log. When replaying the same code it happens consistently:
Traceback (most recent call last):
File "g:\python\dev2\kivy\kivy\core\image\img_ffpyplayer.py", line 28, in
_log_callback
logger_func[level]('ImageLoaderFFPy: {}'.format(message))
File "E:\Python27\lib\logging\__init__.py", line 1186, in error
self._log(ERROR, msg, args, **kwargs)
File "E:\Python27\lib\logging\__init__.py", line 1278, in _log
record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info,
func, extra)
File "E:\Python27\lib\logging\__init__.py", line 1252, in makeRecord
rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
File "E:\Python27\lib\logging\__init__.py", line 287, in __init__
self.msecs = (ct - long(ct)) * 1000
ValueError: cannot convert float NaN to integer
Even weirder, if I add a line like `print time.time()` right before `ct =
time.time()` in logging\__init__.py no error occurs. But if I duplicate the
print line twice, it crashes right there instead of raising an exception.
--
nosy: +matham
___
Python tracker
<http://bugs.python.org/issue14613>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14613] time.time can return NaN
matham added the comment: Ok, first, I was able to make it happen outside of kivy using only my code. However, I'm not sure it's of much help because it's using my ffmpeg based code (https://github.com/matham/ffpyplayer) which is not a simple script :) The issue happens when ffmpeg emits logs through a c(cython) callback which calls the python logging code. But it only happened when I played a specific video. That's why i doubt I'd be able to make it happen in a sterile environment with a simple script. Also, I'm pretty sure that the log calling code is executed from ffmpeg's internal secondary threads (which I protect it with a mutex). Anyway, I decided to upgrade my ffmpeg libraries to the most recent ffmpeg version and the problem went away. So was this maybe some bug in older ffmpeg which corrupted python? If you're interested in replicating it with the older ffmpeg, I can post some code using my ffpyplayer library. -- ___ Python tracker <http://bugs.python.org/issue14613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Changes by matham : -- nosy: +matham ___ Python tracker <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod
New submission from matham:
I have encountered a situation where python crashes when python exits if one
imports a c compiled extension followed by a cpp compiled extension (but not if
imported in the reverse order). This is on windows with mingw (current using
mingw-get install gcc g++ msys-make) and py2.7.9.
This is basically the issue reported at
https://mail.python.org/pipermail/python-win32/2013-April/012798.html a while
back by someone else, but I'm filing it in bug form so it can't be ignored :D
Here's how to replicate it:
cplayground.c:
#include
static PyObject*
say_hello(PyObject* self, PyObject* args)
{
Py_RETURN_NONE;
}
static PyMethodDef HelloMethods[] =
{
{"say_hello", say_hello, METH_VARARGS, "Greet somebody."},
{NULL, NULL, 0, NULL}
};
PyMODINIT_FUNC
initcplayground(void)
{
(void) Py_InitModule("cplayground", HelloMethods);
}
cplayground.cpp:
#include
static PyObject*
say_hello(PyObject* self, PyObject* args)
{
Py_RETURN_NONE;
}
static PyMethodDef HelloMethods[] =
{
{"say_hello", say_hello, METH_VARARGS, "Greet somebody."},
{NULL, NULL, 0, NULL}
};
PyMODINIT_FUNC
initcppplayground(void)
{
(void) Py_InitModule("cppplayground", HelloMethods);
}
setup.py:
from distutils.core import setup
from distutils.extension import Extension
import Cython.Compiler.Options
from Cython.Distutils import build_ext
from os.path import join, sep, dirname, abspath
def get_extensions_from_sources():
ext_modules = []
ext_modules.append(Extension('src.cplayground',
sources=['src/cplayground.c']))
ext_modules.append(Extension('src.cppplayground',
sources=['src/cplayground.cpp']))
return ext_modules
setup(
name='Playground',
version='.1',
author='Matthew Einhorn',
ext_modules=get_extensions_from_sources(),
cmdclass={'build_ext': build_ext},
packages=['src']
)
Here's a demonstration of the issue:
G:\Python\libs\Playground\src>python
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cplayground
>>> import cppplayground
>>> exit()
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
G:\Python\libs\Playground\src>python
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppplayground
>>> import cplayground
>>> exit()
Here's my config:
G:\Python\libs\Playground\src>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)
G:\Python\libs\Playground\src>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)
--
components: Extension Modules, Windows
messages: 238981
nosy: matham, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
[issue23743] Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod
matham added the comment: Well, we won't have to wait until interested solves it. After hours of debugging including compiling Python with VS2013 and looking at windows dump files, it seems that hard work pays off - sorry, I mean asking someone who knows the answer pays off :P. I asked on #mingw and it was suggested that I use mingw compiled with the SJLJ exception model. And indeed, using sjlj fixed this so that it does not crash anymore. It seems that mingw from mingw.org compiles with `"--disable-sjlj-exceptions`, so one has to use mingw-w64's distribution which offers a sjlj build (for x86 and SEH for x64). I am wondering whether this information should be somewhere on the python website so that other people do not run into this issue. I'm not sure what the proper resolution is here so I'll live it open. Or maybe it should be open until the docs is updated to warn about this issue. Anyway, here's the pertinent parts of my #mingw chat: matham: I suggest going for SJLJ on 32bit SEH on 64bit avoid dw2 exception like the plague ok, the one I got from mingw-get says "--disable-sjlj-exceptions --with-dwarf2" I'll try with sjlj from mingw-w64 jon_y, \o/\o/\o/\o/\o/\o/\o/ omg I'm so happy :D it looks like using sjlj fixed it matham: I mean --disable-sjlj-exceptions that is the C++ exception part dwarf2 as debug is fine --with-dwarf2 specifies the debug data format yeah, dw2 (when --disable-sjlj-exceptions is used) has lots of issues with python so the problem is when sjlj is disabled? I thought it was either/or with sjlj vs dw2 dw2 doesn't quite work right for windows it requires ALL dll code use the same shared libgcc dll failure to do so leads to random crashes, especially during program termination so why does mingw-get automatically do --disable-sjlj-exceptions? mingw.org only provides toolchain that uses dw2 exceptions this has been so ever since the 4.2.1 days (that was the first widely used Windows gcc 4.x version) matham: Cygwin had the same problem with python and their dw2 gcc recently but had some local patches done in to fix it -- ___ Python tracker <http://bugs.python.org/issue23743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
