This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: OpenBSD 3.2: make altinstall dumps core
Type: Stage:
Components: None Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: loewis, logistix
Priority: normal Keywords:

Created on 2003-03-30 03:44 by logistix, last changed 2022-04-10 16:07 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
stacktrace.txt logistix, 2003-03-30 21:05 stack trace of core dump.
bt.txt logistix, 2003-03-31 04:10 non-bogus traceback
Messages (8)
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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2022-04-10 16:07:57adminsetgithub: 38240
2003-03-30 03:44:43logistixcreate