[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
Bugs item #1311784, was opened at 2005-10-03 12:18 Message generated for change (Comment added) made by pete_icoserve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&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: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. -- >Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-04 08:02 Message: Logged In: YES user_id=299547 I would leave the code for pre-VS2005 compilers as is and introduce a specific workaround for VS2005 and all following compilers. Something like this comes to my mind: #if defined (_WIN32) && _MSC_VER >= 1400 ... #endif This works for 32 and 64 bit platforms since _WIN32 is defined in both cases. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 19:54 Message: Logged In: YES user_id=33168 Do you suggest this be special cased for VS2005 specifically or Windows in general (ie, any version/compiler)? -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-03 18:10 Message: Logged In: YES user_id=299547 VS2005 is still not released. It is scheduled for November 7th 2005. I tested with CTP (Community Technology Preview) August 2005. However I doubt they will change the behavior of their C library at this point of development. -- Comment By: Michael Hudson (mwh) Date: 2005-10-03 13:05 Message: Logged In: YES user_id=6656 Is VS2005 actually out now then? This behaviour violates the C standard, as far as we can tell, so we when VS2005 was in beta we hoped that they would fix it for the final release. If it is released, though, I guess we need to do something like you suggest (along with some colourful comments, I guess). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1237015 ] Missing sk_SK in windows_locale
Bugs item #1237015, was opened at 2005-07-13 00:51 Message generated for change (Settings changed) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237015&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: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: Missing sk_SK in windows_locale Initial Comment: Please, could you add sk_SK locale to windows_locale array in module locale? Corresponding entry should look like: 0x041b: "sk_SK", # Slovak Information about language ID taken is from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1237015&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1262856 ] fcntl.ioctl have a bit problem.
Bugs item #1262856, was opened at 2005-08-18 09:53 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&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 Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raise L. Sail (fullsail) Assigned to: Neal Norwitz (nnorwitz) Summary: fcntl.ioctl have a bit problem. Initial Comment: First, I write python program on Linux. The function ioctl of fcntl module, take a integer parameter as ioctl command. in python 2.3.x, if this command value is more than 0x8000, interpreter will popup some warnning message. but in python 2.4.x, it raise a exception directly. My solution is writing one cutoms module in C. but this is so ugly. There are some ioctl command value are more than 0x8000, I think we should not reject "negative" ioctl command. enjoy. -- >Comment By: Michael Hudson (mwh) Date: 2005-10-04 11:10 Message: Logged In: YES user_id=6656 Uh, no, that patch is about fcntl, this report is about ioctl. ioctl has been fixed in CVS, afaik, so this report should probably be closed unless the OP shows up and tells us it isn't. Something similar should almost certainly be done to fcntl. That's what 1309352 is about. Maybe I should have fixed fcntl when I did ioctl, but I actually use ioctl and don't use fnctl myself... -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 05:49 Message: Logged In: YES user_id=33168 This could be related to: patch 1309352. -- Comment By: Michael Hudson (mwh) Date: 2005-08-23 13:10 Message: Logged In: YES user_id=6656 I think this is fixed in CVS HEAD. Can you try that? As a workaround, you can probably pass ~int(~v&0x) to ioctl instead of v (which is very ugly, yes, but probably not as ugly as a C extension). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint
Bugs item #1313051, was opened at 2005-10-04 12:37 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=1313051&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 Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: mac_roman codec missing "apple" codepoint Initial Comment: The mac_roman codec is missing a single codepoint for the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple docs), which prevents round-tripping of mac_roman text through Unicode. Adding the codepoint as a private encoding (per Apple) has no trademark implications, only the character itself, in a font, would have such issues. I'm using Python 2.3, but AFAICT it is an issue in later Python versions as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1262856 ] fcntl.ioctl have a bit problem.
Bugs item #1262856, was opened at 2005-08-18 01:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&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 Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raise L. Sail (fullsail) Assigned to: Neal Norwitz (nnorwitz) Summary: fcntl.ioctl have a bit problem. Initial Comment: First, I write python program on Linux. The function ioctl of fcntl module, take a integer parameter as ioctl command. in python 2.3.x, if this command value is more than 0x8000, interpreter will popup some warnning message. but in python 2.4.x, it raise a exception directly. My solution is writing one cutoms module in C. but this is so ugly. There are some ioctl command value are more than 0x8000, I think we should not reject "negative" ioctl command. enjoy. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 10:12 Message: Logged In: YES user_id=33168 Ah, I see. I was confused since both are in the fcntl module. I agree this bug isn't related to the patch. This got me looking into fcntl.ioctl() and I wonder if there's still not a problem. In the patch, I had to make arg a long which is consistent with fcntl() doc. ioctl() says the param is ..., so I don't know if it should be an int or a long. The current ioctl uses an int (lines 98 and 175). ISTM that arg should probably be unsigned (like the code variable) or a long here. (By unsigned I mean at least the format 'I' instead of 'i', if not the variable itself.) Any ideas? -- Comment By: Michael Hudson (mwh) Date: 2005-10-04 03:10 Message: Logged In: YES user_id=6656 Uh, no, that patch is about fcntl, this report is about ioctl. ioctl has been fixed in CVS, afaik, so this report should probably be closed unless the OP shows up and tells us it isn't. Something similar should almost certainly be done to fcntl. That's what 1309352 is about. Maybe I should have fixed fcntl when I did ioctl, but I actually use ioctl and don't use fnctl myself... -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 21:49 Message: Logged In: YES user_id=33168 This could be related to: patch 1309352. -- Comment By: Michael Hudson (mwh) Date: 2005-08-23 05:10 Message: Logged In: YES user_id=6656 I think this is fixed in CVS HEAD. Can you try that? As a workaround, you can probably pass ~int(~v&0x) to ioctl instead of v (which is very ugly, yes, but probably not as ugly as a C extension). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313119 ] urlparse "caches" parses regardless of encoding
Bugs item #1313119, was opened at 2005-10-04 17:57
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=1313119&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: Ken Kinder (kkinder)
Assigned to: M.-A. Lemburg (lemburg)
Summary: urlparse "caches" parses regardless of encoding
Initial Comment:
The issue can be summarized with this code:
>>> urlparse.urlparse(u'http://www.python.org/doc')
(u'http', u'www.python.org', u'/doc', '', '', '')
>>> urlparse.urlparse('http://www.python.org/doc')
(u'http', u'www.python.org', u'/doc', '', '', '')
Once the urlparse library has "cached" a URL, it stores
the resulting value of that cache regardless of
datatype. Notice that in the second use of urlparse, I
passed it a STRING and got back a UNICODE object.
This can be quite confusing when, as a developer, you
think you've already encoded all your objects, you use
urlparse, and all of a sudden you have unicode objects
again, when you expected to have strings.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313119&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint
Bugs item #1313051, was opened at 2005-10-04 18:37 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&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 Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: mac_roman codec missing "apple" codepoint Initial Comment: The mac_roman codec is missing a single codepoint for the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple docs), which prevents round-tripping of mac_roman text through Unicode. Adding the codepoint as a private encoding (per Apple) has no trademark implications, only the character itself, in a font, would have such issues. I'm using Python 2.3, but AFAICT it is an issue in later Python versions as well. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-10-04 20:07 Message: Logged In: YES user_id=89016 The codepoint 0xF8FF is in the Private Use Area, so this is not an official Unicode character, and for other uses 0xF8FF might mean something completely different. So I think this mapping shouldn't be added to mac_roman. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint
Bugs item #1313051, was opened at 2005-10-04 12:37 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&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 Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: mac_roman codec missing "apple" codepoint Initial Comment: The mac_roman codec is missing a single codepoint for the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple docs), which prevents round-tripping of mac_roman text through Unicode. Adding the codepoint as a private encoding (per Apple) has no trademark implications, only the character itself, in a font, would have such issues. I'm using Python 2.3, but AFAICT it is an issue in later Python versions as well. -- >Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 16:41 Message: Logged In: YES user_id=1356214 It isn't Python's job to tell people what characters they are allowed to use. Apple defined the codepoint and its mapping to Unicode. Python is not the Unicode Police, and should not damage the data it was given just to prove a point. Damaging the user's data isn't very "batteries included". -- Comment By: Walter Dörwald (doerwalter) Date: 2005-10-04 14:07 Message: Logged In: YES user_id=89016 The codepoint 0xF8FF is in the Private Use Area, so this is not an official Unicode character, and for other uses 0xF8FF might mean something completely different. So I think this mapping shouldn't be added to mac_roman. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser
Bugs item #1246405, was opened at 2005-07-28 01:07 Message generated for change (Comment added) made by jean-pierre24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... -- >Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-05 00:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 07:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint
Bugs item #1313051, was opened at 2005-10-04 18:37 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&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 Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: mac_roman codec missing "apple" codepoint Initial Comment: The mac_roman codec is missing a single codepoint for the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple docs), which prevents round-tripping of mac_roman text through Unicode. Adding the codepoint as a private encoding (per Apple) has no trademark implications, only the character itself, in a font, would have such issues. I'm using Python 2.3, but AFAICT it is an issue in later Python versions as well. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-04 23:48 Message: Logged In: YES user_id=38388 Tony, comment like yours are not very helpful. Python's codecs rely on facts defined by standards bodies, e.g. the Unicode consortium, ISO, etc.. If you don't present proof of your claim then there's nothing much we can do about your particular problem. Fortunately, proof isn't hard to find in this case: http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT Looks like Apple added the mapping sometime after the codec was created. Walter: it is common for companies to add their logos as private Unicode characters. This happens a lot in the Asian world. Of course, interop isn't great, but at least you don't lose information by converting to Unicode. Tony: Python is not damaging your data - the codec will raise an exception in case that particular character is converted to Unicode. Please recreate the codec using gencodec.py (which you can find the Tools/ directory) and add it as attachement to this bug report. Thanks. -- Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 22:41 Message: Logged In: YES user_id=1356214 It isn't Python's job to tell people what characters they are allowed to use. Apple defined the codepoint and its mapping to Unicode. Python is not the Unicode Police, and should not damage the data it was given just to prove a point. Damaging the user's data isn't very "batteries included". -- Comment By: Walter Dörwald (doerwalter) Date: 2005-10-04 20:07 Message: Logged In: YES user_id=89016 The codepoint 0xF8FF is in the Private Use Area, so this is not an official Unicode character, and for other uses 0xF8FF might mean something completely different. So I think this mapping shouldn't be added to mac_roman. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint
Bugs item #1313051, was opened at 2005-10-04 12:37 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&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 Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: mac_roman codec missing "apple" codepoint Initial Comment: The mac_roman codec is missing a single codepoint for the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple docs), which prevents round-tripping of mac_roman text through Unicode. Adding the codepoint as a private encoding (per Apple) has no trademark implications, only the character itself, in a font, would have such issues. I'm using Python 2.3, but AFAICT it is an issue in later Python versions as well. -- >Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 22:16 Message: Logged In: YES user_id=1356214 >Tony: Python is not damaging your data - the codec will >raise an exception in case that particular character is >converted to Unicode. Right, crashing the unsuspecting user's program and destroying the data utterly. Anyway, it doesn't damage /my/ data because I add the missing codepoint to the codec: # Fix missing Apple logo in mac_roman. import encodings.mac_roman if not encodings.mac_roman.decoding_map[0xF0]: encodings.mac_roman.decoding_map[0xF0] = 0xF8FF encodings.mac_roman.encoding_map[0xF8FF] = 0xF0 It just damages data for all the other users of the codec. >Please recreate the codec using gencodec.py (which you can >find the Tools/ directory) and add it as attachement to this >bug report. Thanks. Umm, I take it you want me to download a mapping file first. Here is a new mac_roman.py. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-04 17:48 Message: Logged In: YES user_id=38388 Tony, comment like yours are not very helpful. Python's codecs rely on facts defined by standards bodies, e.g. the Unicode consortium, ISO, etc.. If you don't present proof of your claim then there's nothing much we can do about your particular problem. Fortunately, proof isn't hard to find in this case: http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT Looks like Apple added the mapping sometime after the codec was created. Walter: it is common for companies to add their logos as private Unicode characters. This happens a lot in the Asian world. Of course, interop isn't great, but at least you don't lose information by converting to Unicode. Tony: Python is not damaging your data - the codec will raise an exception in case that particular character is converted to Unicode. Please recreate the codec using gencodec.py (which you can find the Tools/ directory) and add it as attachement to this bug report. Thanks. -- Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 16:41 Message: Logged In: YES user_id=1356214 It isn't Python's job to tell people what characters they are allowed to use. Apple defined the codepoint and its mapping to Unicode. Python is not the Unicode Police, and should not damage the data it was given just to prove a point. Damaging the user's data isn't very "batteries included". -- Comment By: Walter Dörwald (doerwalter) Date: 2005-10-04 14:07 Message: Logged In: YES user_id=89016 The codepoint 0xF8FF is in the Private Use Area, so this is not an official Unicode character, and for other uses 0xF8FF might mean something completely different. So I think this mapping shouldn't be added to mac_roman. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser
Bugs item #1246405, was opened at 2005-07-27 16:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 20:34 Message: Logged In: YES user_id=33168 I don't have the problem with Python 2.3.4 and wx 2.5.5.1. Are you able to try different versions of wxPython? I notice that wx 2.6.2 is available. Are you able to run under valgrind or purify? If you run under valgrind, be sure to specify --suppressions=Misc/valgrind-python.supp The file is in the Python distribution. You can download it through SourceForge ViewCVS. -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-04 15:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 22:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313496 ] bisect C replacement doesn't accept named args
Bugs item #1313496, was opened at 2005-10-04 21:27 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=1313496&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 Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Drew Perttula (drewp) Assigned to: Nobody/Anonymous (nobody) Summary: bisect C replacement doesn't accept named args Initial Comment: Code like "bisect.bisect(a,x,lo=y)" works in 2.3 but not in 2.4 due to the new _bisect module not accepting named arguments. _bisect (and all of the other C modules, for that matter) should accept named arguments to their functions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
