OpenBSD 3.2: make altinstall dumps core

[logistix]

BPO	712056
Nosy	@loewis
Files	stacktrace.txt: stack trace of core dump. bt.txt: non-bogus traceback

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2003-05-04.12:53:24.000>
created_at = <Date 2003-03-30.03:44:43.000>
labels = []
title = 'OpenBSD 3.2: make altinstall dumps core'
updated_at = <Date 2003-05-04.12:53:24.000>
user = 'https://bugs.python.org/logistix'

bugs.python.org fields:

activity = <Date 2003-05-04.12:53:24.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['None']
creation = <Date 2003-03-30.03:44:43.000>
creator = 'logistix'
dependencies = []
files = ['834', '835']
hgrepos = []
issue_num = 712056
keywords = []
message_count = 8.0
messages = ['15307', '15308', '15309', '15310', '15311', '15312', '15313', '15314']
nosy_count = 2.0
nosy_names = ['loewis', 'logistix']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue712056'
versions = []

[logistix]

"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

[loewis]

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.

[logistix]

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.

[loewis]

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.

[logistix]

Logged In: YES
user_id=699438

Here's a (hopefully) non-bogus traceback.

[loewis]

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.

[logistix]

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.

[loewis]

Logged In: YES
user_id=21627

I assume this is fixed now, since the iconv module has been
removed from Python.