Does anyone have any idea why our wxpython program (that has no
relationship with Chrome) jams Chrome in 64bit Windows 7? This doesn't
happen on other operating systems. Also we are sure that it is somehow
related to wxpython.
No idea. Please make a runnable, small as possible, sample application that demonstrates the problem. MakingSampleApps - wxPyWiki
···
On 12/21/11 12:25 PM, mkorpela wrote:
Hi,
Does anyone have any idea why our wxpython program (that has no
relationship with Chrome) jams Chrome in 64bit Windows 7? This doesn't
happen on other operating systems. Also we are sure that it is somehow
related to wxpython.
That might be a problem as the application is a fairly big editor -
and the bug is very odd (seems to require some setting up .. and I
really did not believe it when the first report of the bug came(1)). I
also already tried to do this a while ago but it is not a trivial
task.
Still I'm convinced that the problem is either in wxpython or in the
operating system - the problem doesn't occur in any of the other
operating systems that our application is running in (including 32bit
Windows 7, other win-things, linux/gnome and OSX). Also our users are
testers and have reproduced the problem several times and the commit
that introduced the problem (2) is UI code.
The first commit that introduced the original problem is fairly small
(about 30 lines of Python). I'm not currently able to reproduce the
problem in the same way as it originally occurred in the last February
(both Windows 7 and Chrome have had many updates since..). I'll try to
investigate tomorrow how to make a new reproducible example. Could you
(or someone else) consider helping us solve this problem if I do this?
It is kind of critical that unrelated applications don't freeze each
other.
Does anyone have any idea why our wxpython program (that has no
relationship with Chrome) jams Chrome in 64bit Windows 7? This doesn't
happen on other operating systems. Also we are sure that it is somehow
related to wxpython.
That might be a problem as the application is a fairly big editor -
and the bug is very odd (seems to require some setting up .. and I
really did not believe it when the first report of the bug came(1)). I
also already tried to do this a while ago but it is not a trivial
task.
Still I'm convinced that the problem is either in wxpython or in the
operating system - the problem doesn't occur in any of the other
operating systems that our application is running in (including 32bit
Windows 7, other win-things, linux/gnome and OSX). Also our users are
testers and have reproduced the problem several times and the commit
that introduced the problem (2) is UI code.
The first commit that introduced the original problem is fairly small
(about 30 lines of Python). I'm not currently able to reproduce the
problem in the same way as it originally occurred in the last February
(both Windows 7 and Chrome have had many updates since..). I'll try to
investigate tomorrow how to make a new reproducible example. Could you
(or someone else) consider helping us solve this problem if I do this?
If I'm able to reliably reproduce the problem in a small standalone sample then I'll certainly take a look at it. However I can't make any promises for a fix without knowing more.
It is kind of critical that unrelated applications don't freeze each
other.