[ python-Bugs-1434298 ] CHM file contains proprietary link format
Bugs item #1434298, was opened at 2006-02-18 21:22 Message generated for change (Comment added) made by alexanderweb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Alexander Schremmer (alexanderweb) Assigned to: Thomas Heller (theller) Summary: CHM file contains proprietary link format Initial Comment: The .chm file distributed with Python contains URL using the proprietary link scheme mk:@MSITStore. While this is not a problem in Windows environments, it prevents e.g. xchm from loading the pictures. My suggestion is to advise the html help compiler to make these links absolute without specifying a protocol. As I do not have setup the html help compiler here, I cannot check if this is a working work around. Having a .chm file that is compatible to multiple platforms is a large advantage because you can advise newbies to get this file. They are easy navigatable and tend to be complete. -- >Comment By: Alexander Schremmer (alexanderweb) Date: 2006-03-08 12:30 Message: Logged In: YES user_id=254738 I figured out that this issue seems to be related to xchm and that there are no ms-specific URLs in the source. I recommend non-windows users to choose http://www.kchmviewer. net/ as it is known to work correctly with python's chm file. -- Comment By: Thomas Heller (theller) Date: 2006-02-18 22:19 Message: Logged In: YES user_id=11105 The project files are generated by calling the script Doc/tools/prechm.py. See als PEP 101. -- Comment By: Alexander Schremmer (alexanderweb) Date: 2006-02-18 21:50 Message: Logged In: YES user_id=254738 I could check if it is possible if you can tell me where the HTML help compiler project etc. files are in the source tree. -- Comment By: Thomas Heller (theller) Date: 2006-02-18 21:36 Message: Logged In: YES user_id=11105 Can you tell me how this is done? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 21:27 Message: Logged In: YES user_id=1188172 Moving to Bugs. Martin, do you create the CHM file? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1434298&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441884 ] A (treaded) Python crash only on dual core machines
Bugs item #1441884, was opened at 2006-03-02 18:17
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines
Initial Comment:
There is a strange freeze/crash only on dual core machines:
I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.
Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.
I found no hints other than:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325
.. both discussions remaining in uncertainty.
Are there (known) problems with Python/Pythonwin
specifically for dual core's (py2.3.5 / pywin203) ?
What could I do to find the problem?
Robert
--
PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:
//
#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
class CAllowThreads {
public:
PyThreadState *_save; \
CAllowThreads() {
_save = PyEval_SaveThread();
}
~CAllowThreads() {
PyEval_RestoreThread(_save);
}
};
PyObject* PyListView_GetSubItemRect(
HWND hwndLV,
int iItem,
int iSubItem,
int code
//LPRECT lpRect
)
{
RECT r;
{
CAllowThreads _t;
ListView_GetSubItemRect(
hwndLV,
iItem,
iSubItem,
code,
&r );
}
return Py_BuildValue("",
r.left,r.top,r.right,r.bottom);
}
int GetStringAddr(const char* s) {
return (int)s;
}
int PlaySoundResource(int resid, HMODULE hmod)
{
CAllowThreads _t;
return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}
int PlaySoundFile(const char* fname, int flag)
{
CAllowThreads _t;
return PlaySound(fname, NULL, flag);
}
PyObject* py_ToolTipRelayMsg( PyObject* self,
PyObject* args )
{
MSG msg;
HWND hwTT;
if(!PyArg_ParseTuple(args,"i(i(ii)):ToolTipRelayMsg",
&hwTT,
&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
&msg.pt, ((int*)&msg.pt)+1) )
return NULL;
{
CAllowThreads _t;
SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
}
Py_INCREF( Py_None );
return Py_None;
}
---
"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):
self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))
--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
PyObject *resultobj;
char *arg0 ;
int result ;
if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
result = (int )GetStringAddr((char const *)arg0);
resultobj = PyInt_FromLong((long)result);
return resultobj;
}
--
>Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 12:31
Message:
Logged In: YES
user_id=972995
Find no indications, that it is a GIL problem. Whenever
there was a GIL problem in past, I quickly got problems on
any machine, not specifically only on dual cores.
(The thread-state handling of above short extension code is
done in the same style as in PythonWin for critical
functions, which might come back as new messages in the
message handler. This should be ok. Otherwise there is only
normal Python/Pythonwin code).
The python part of the soft is too big, and I didn't manage
to isolate the problem further as I have only a handful of
user reports like this:
"""
Yes here is one popup window.
---
app.exe - Application Error
---
The instruction at "0x73dd11c7" referenced memory at
"0x0004". The memory could not be "read".
Click on OK to terminate the program
---
OK
---
"""
"""
AppName: app.exe AppVer: 2.7.0.0 ModName: python23.dll
Mod
[ python-Bugs-1441884 ] A (treaded) Python crash only on dual core machines
Bugs item #1441884, was opened at 2006-03-02 18:17
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines
Initial Comment:
There is a strange freeze/crash only on dual core machines:
I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.
Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.
I found no hints other than:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325
.. both discussions remaining in uncertainty.
Are there (known) problems with Python/Pythonwin
specifically for dual core's (py2.3.5 / pywin203) ?
What could I do to find the problem?
Robert
--
PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:
//
#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
class CAllowThreads {
public:
PyThreadState *_save; \
CAllowThreads() {
_save = PyEval_SaveThread();
}
~CAllowThreads() {
PyEval_RestoreThread(_save);
}
};
PyObject* PyListView_GetSubItemRect(
HWND hwndLV,
int iItem,
int iSubItem,
int code
//LPRECT lpRect
)
{
RECT r;
{
CAllowThreads _t;
ListView_GetSubItemRect(
hwndLV,
iItem,
iSubItem,
code,
&r );
}
return Py_BuildValue("",
r.left,r.top,r.right,r.bottom);
}
int GetStringAddr(const char* s) {
return (int)s;
}
int PlaySoundResource(int resid, HMODULE hmod)
{
CAllowThreads _t;
return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}
int PlaySoundFile(const char* fname, int flag)
{
CAllowThreads _t;
return PlaySound(fname, NULL, flag);
}
PyObject* py_ToolTipRelayMsg( PyObject* self,
PyObject* args )
{
MSG msg;
HWND hwTT;
if(!PyArg_ParseTuple(args,"i(i(ii)):ToolTipRelayMsg",
&hwTT,
&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
&msg.pt, ((int*)&msg.pt)+1) )
return NULL;
{
CAllowThreads _t;
SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
}
Py_INCREF( Py_None );
return Py_None;
}
---
"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):
self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))
--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
PyObject *resultobj;
char *arg0 ;
int result ;
if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
result = (int )GetStringAddr((char const *)arg0);
resultobj = PyInt_FromLong((long)result);
return resultobj;
}
--
>Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 16:41
Message:
Logged In: YES
user_id=972995
Indications point more to a "dual core" problem in Pythonwin
=> Bug 1442426 in sf pywin32 project.
--
Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 12:31
Message:
Logged In: YES
user_id=972995
Find no indications, that it is a GIL problem. Whenever
there was a GIL problem in past, I quickly got problems on
any machine, not specifically only on dual cores.
(The thread-state handling of above short extension code is
done in the same style as in PythonWin for critical
functions, which might come back as new messages in the
message handler. This should be ok. Otherwise there is only
normal Python/Pythonwin code).
The python part of the soft is too big, and I didn't manage
to isolate the problem further as I have only a handful of
user reports like this:
"""
Yes here is one popup window.
---
app.exe - Application Error
---
The in
[ python-Bugs-1445781 ] install fails on hard link
Bugs item #1445781, was opened at 2006-03-08 11:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) Assigned to: Nobody/Anonymous (nobody) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445807 ] install fails on hard link
Bugs item #1445807, was opened at 2006-03-08 11:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445807&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) Assigned to: Nobody/Anonymous (nobody) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445807&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445807 ] install fails on hard link
Bugs item #1445807, was opened at 2006-03-08 11:38 Message generated for change (Settings changed) made by goldenautumnday You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445807&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) Assigned to: Nobody/Anonymous (nobody) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445807&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445781 ] install fails on hard link
Bugs item #1445781, was opened at 2006-03-08 11:06 Message generated for change (Comment added) made by goldenautumnday You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) Assigned to: Nobody/Anonymous (nobody) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). -- >Comment By: goldenautumnday (goldenautumnday) Date: 2006-03-08 14:22 Message: Logged In: YES user_id=1471082 Changing line 599 in Makefile.pre.in to: (cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python $(VERSION)$(EXE) $(PYTHON)) allowed make to complete. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445901 ] os.path.realpath works on windows
Bugs item #1445901, was opened at 2006-03-08 20:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445901&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.realpath works on windows Initial Comment: documentation says "Availability: Unix," but it works on Windows too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445901&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1445901 ] os.path.realpath works on windows
Bugs item #1445901, was opened at 2006-03-08 20:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445901&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.realpath works on windows Initial Comment: documentation says "Availability: Unix," but it works on Windows too. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-08 20:59 Message: Logged In: YES user_id=849994 Thanks, updated the docs in rev. 42923, 42924. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445901&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError
Bugs item #1446043, was opened at 2006-03-08 19:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError
Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.
I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441884 ] A (treaded) Python crash only on dual core machines
Bugs item #1441884, was opened at 2006-03-02 18:17
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441884&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: A (treaded) Python crash only on dual core machines
Initial Comment:
There is a strange freeze/crash only on dual core machines:
I have a python app (Python 2.3.5 /Pythonwin build 203
/ Windows) running with no stability problems on normal
machines (Or a crash is so rare, that absolutely nobody
obverses it, though the overall majority of users uses
single core machines). Threads, network &
pythonwin/win32ui all in use.
Yet, from 3 users, _all_ using a Dual Processor System
(XEON, amd x2 3800+) computer, I have reports, that the
application freezes hard and/or crashes with a kind of
random stack dump (operating system). I cannot
experiment with those machines.
I found no hints other than:
http://groups.google.de/group/comp.lang.python/browse_frm/thread/64ca033e1a7f6c61/719b147e870bd5e6
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=480325
.. both discussions remaining in uncertainty.
Are there (known) problems with Python/Pythonwin
specifically for dual core's (py2.3.5 / pywin203) ?
What could I do to find the problem?
Robert
--
PS: there is very little C extension-code (SWIG)
involved, yet I looked over that so often, I guess its
save:
//
#include "stdafx.h"
#include "commctrl.h"
#include "ext.h"
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
class CAllowThreads {
public:
PyThreadState *_save; \
CAllowThreads() {
_save = PyEval_SaveThread();
}
~CAllowThreads() {
PyEval_RestoreThread(_save);
}
};
PyObject* PyListView_GetSubItemRect(
HWND hwndLV,
int iItem,
int iSubItem,
int code
//LPRECT lpRect
)
{
RECT r;
{
CAllowThreads _t;
ListView_GetSubItemRect(
hwndLV,
iItem,
iSubItem,
code,
&r );
}
return Py_BuildValue("",
r.left,r.top,r.right,r.bottom);
}
int GetStringAddr(const char* s) {
return (int)s;
}
int PlaySoundResource(int resid, HMODULE hmod)
{
CAllowThreads _t;
return PlaySound(MAKEINTRESOURCE(resid), hmod,
SND_RESOURCE);
}
int PlaySoundFile(const char* fname, int flag)
{
CAllowThreads _t;
return PlaySound(fname, NULL, flag);
}
PyObject* py_ToolTipRelayMsg( PyObject* self,
PyObject* args )
{
MSG msg;
HWND hwTT;
if(!PyArg_ParseTuple(args,"i(i(ii)):ToolTipRelayMsg",
&hwTT,
&msg.hwnd,&msg.message,&msg.wParam,&msg.lParam,&msg.time,
&msg.pt, ((int*)&msg.pt)+1) )
return NULL;
{
CAllowThreads _t;
SendMessage(hwTT,TTM_RELAYEVENT,0,(LPARAM)&msg);
}
Py_INCREF( Py_None );
return Py_None;
}
---
"GetStringAddress" is used only once like this (leades
to correct NUL termination I think):
self.sb.SendMessage(commctrl.SB_SETTEXT,iPane,extension.GetStringAddr(text))
--- swig:
static PyObject *_wrap_GetStringAddr(PyObject *self,
PyObject *args) {
PyObject *resultobj;
char *arg0 ;
int result ;
if(!PyArg_ParseTuple(args,(char
*)"s:GetStringAddr",&arg0)) return NULL;
result = (int )GetStringAddr((char const *)arg0);
resultobj = PyInt_FromLong((long)result);
return resultobj;
}
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-03-09 02:13
Message:
Logged In: YES
user_id=21627
Well, this bug here is clearly something different. An
attempt to access 0x0004 very obviously is a null
pointer access, at a structure offset at offset 4. At offset
4, if this is a Python object (which it might not be), is
the ob_type field of an object. So it might be that somebody
tries to find out the Python type of a null pointer (which
ought to crash).
This is different from 1442426, which apparently is not a
null-pointer access.
Without any kind of backtrace, it is very hard to guess what
the cause of this null-pointer access might be - it could be
everywhere (including Python, PythonWin, and,
last-but-not-least, your code).
So I'm closing this as "unreproducable" (for which SF only
has "works for me").
--
Comment By: Robert Kiendl (kxroberto)
Date: 2006-03-08 16:41
Message:
Logged In: YES
user_id=972995
Indications point more to a "dual core" problem in Pythonw
[ python-Bugs-1446119 ] subprocess interpreted double quotation mark wrong on window
Bugs item #1446119, was opened at 2006-03-09 15:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: simon (simonhang) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess interpreted double quotation mark wrong on window Initial Comment: If we run below python command print subprocess.Popen([r'c:\test.bat', r'test"string:']).pid Actually c:\test.bat test\"string\" is executed. Module subprocess doesn't interpret double quotation mark right. Back slash shouldn't be added. I believe problem is in function subprocess.list2cmdline. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446119 ] subprocess interpreted double quotation wrong on windows
Bugs item #1446119, was opened at 2006-03-09 15:26 Message generated for change (Settings changed) made by simonhang You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: simon (simonhang) Assigned to: Nobody/Anonymous (nobody) >Summary: subprocess interpreted double quotation wrong on windows Initial Comment: If we run below python command print subprocess.Popen([r'c:\test.bat', r'test"string:']).pid Actually c:\test.bat test\"string\" is executed. Module subprocess doesn't interpret double quotation mark right. Back slash shouldn't be added. I believe problem is in function subprocess.list2cmdline. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 14:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-08 22:03 Message: Logged In: YES user_id=33168 I just changed this to print an error message and exit in 2.5. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 16:16 Message: Logged In: YES user_id=33168 Ok, I understand that part. But if you can't accept input from the user, what can you do? If all you are suggesting is to change Py_FatalError() to raising a SystemError and still exiting, I'm fine with that if it can work. I agree this would probably be nicer too. Or am I still missing your point? Do you want to work on a patch? I'm fine with any improvement, I'm just not sure how much can be done. If you want to improve the error message, that would be good too. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 15:57 Message: Logged In: YES user_id=44345 No, we're still discussing stdin. My only point is that what you do might be predicated on whether or not you think you can communicate with the user on stderr. My thought was that if stderr is valid you can raise an exception that prints a traceback. If not, Py_FatalError is your only recourse. Your code checks for the directori-ness of stdin as the first thing, then bails if it is. If it checked to see if stderr was valid first, it could decide to raise SystemError instead of calling Py_FatalError. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 14:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 14:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 05:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week.
