OpenBSD 3.2: make altinstall dumps core #38240

Activity

1. logistix commented on Mar 30, 2003

   

   logistixmannequin

   on Mar 30, 2003

   MannequinAuthor

   More actions

   "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
2. logistix

   closed this as completedon Mar 30, 2003
3. logistix

   closed this as completedon Mar 30, 2003
4. loewis commented on Mar 30, 2003

   

   loewismannequin

   on Mar 30, 2003

   Mannequin

   More actions

   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.
5. logistix commented on Mar 30, 2003

   

   logistixmannequin

   on Mar 30, 2003

   MannequinAuthor

   More actions

   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.
6. loewis commented on Mar 30, 2003

   

   loewismannequin

   on Mar 30, 2003

   Mannequin

   More actions

   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.
7. logistix commented on Mar 31, 2003

   

   logistixmannequin

   on Mar 31, 2003

   MannequinAuthor

   More actions

   Logged In: YES
   user_id=699438

   Here's a (hopefully) non-bogus traceback.
8. loewis commented on Mar 31, 2003

   

   loewismannequin

   on Mar 31, 2003

   Mannequin

   More actions

   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.
9. logistix commented on Mar 31, 2003

   

   logistixmannequin

   on Mar 31, 2003

   MannequinAuthor

   More actions

   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.
10. loewis commented on May 4, 2003

    

    loewismannequin

    on May 4, 2003

    Mannequin

    More actions

    Logged In: YES
    user_id=21627

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

    transferred this issue fromon Apr 9, 2022