| msg15307 - (view) |
Author: Grant Olson (logistix) |
Date: 2003-03-30 03:44 |
| "make altinstall" fails when building on OpenBSD 3.2. The core dump appears to happen when the newly built python program attempts to byte-compile "./Lib/test/test_pep263.py". A gdb 'bt' shows a segmentation fault in a call to libiconv.so.3.0's div() function. This could be a bug in libiconv.so's unicode handling. Also, running "./python ./Lib/test/test_pep263.py" from the newly built python throws an assertation error. I am using a home-built version of OpenBSD, so I'd appreciate it if someone else could verify this. make altinstall's output: ... Compiling /usr/local/lib/python2.3/test/test_pep263.py ... python in free(): warning: modified (chunk-) pointer. python in free(): warning: modified (chunk-) pointer. python in free(): warning: modified (chunk-) pointer. Memory fault (core dumped) *** Error code 139 |
|
|
| msg15308 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2003-03-30 09:05 |
| Logged In: YES user_id=21627 It is surprising that it runs into iconv, as test_pep263 should use encodings.koi8_r.Codec, not the IconvCodec. What do you get if you do codecs.lookup("koi8-r") In any case, the iconv codec (when used) should not crash. It looks like there is some memory corruption going on. However, without an OpenBSD system to debug libiconv, this probably won't be found. |
|
|
| msg15309 - (view) |
Author: Grant Olson (logistix) |
Date: 2003-03-30 21:05 |
| Logged In: YES user_id=699438 Okay, I lied. I'm primarily a windows developer who's a bit new to the wonderful world of gdb! It found the codec fine. libiconv was just the last library that gdb imported a symbol table from. The error actaully occurs on a realloc() to a list object. I've attached the stack trace if it means anything. man realloc also explains the error message: ``modified (chunk-/page-) pointer.'' The pointer passed to free or realloc has been modified. |
|
|
| msg15310 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-03-30 21:27 |
| Logged In: YES user_id=21627 The traceback is bogus. For example, in stackframe 19, decode_str does not feature a call to PyUnicodeUCS2_Decode. The most likely reason is that not all object files were built with -g, so that some symbols are missing. I recommend that you rebuild from scratch with --with-pydebug. Make sure you have no object files left over from an earlier build. If this causes the bug to disappear, configure with regular options, and add -g to Makefile.pre manually. In either case, verify that -g does get added to the compile commands. |
|
|
| msg15311 - (view) |
Author: Grant Olson (logistix) |
Date: 2003-03-31 04:10 |
| Logged In: YES user_id=699438 Here's a (hopefully) non-bogus traceback. |
|
|
| msg15312 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-03-31 05:43 |
| Logged In: YES user_id=21627 That sounds reasonable, and suggests that the bug is within libiconv. It crashes at the line iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1"); Please do the following steps: a) produce a preprocessor output of _iconv_module.c (with --save-temps), to see what UNICODE_ENCODING expands to. b) write a test program, with #include <iconv.h> int main() { iconv_t hdl = iconv_open(UNICODE_ENCODING, "ISO-8859-1"); } and see whether this runs correctly. If it doesn't, it's an OpenBSD bug, if it does, we would need debug information for libiconv as well. |
|
|
| msg15313 - (view) |
Author: Grant Olson (logistix) |
Date: 2003-03-31 07:11 |
| Logged In: YES user_id=699438 It's using 'ucs-2-internal' for it's UNICODE_ENCODING. The test progam you gave me ran just fine (no core dump). I'm trying to get some directions now on the recommended way to do a full system debug build. When I do, I'll provide more info. |
|
|
| msg15314 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2003-05-04 12:53 |
| Logged In: YES user_id=21627 I assume this is fixed now, since the iconv module has been removed from Python. |
|
|