Bug in struct.pack() for Sparc Solaris 2.3? 
Author Message
 Bug in struct.pack() for Sparc Solaris 2.3?

Hello,

I observed the following:

Python 1.1.1 (Nov 16 1994)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam

Quote:
>>> import struct
>>> struct.pack('d', 1.0)

Bus error (core dumped)

(gdb) bt
#0  0x22aa0 in struct_pack ()
#1  0x33114 in call_builtin ()
#2  0x3303c in call_object ()
#3  0x300dc in eval_code ()
#4  0x3da2c in run_node ()
#5  0x3d2d4 in run_tty_1 ()
#6  0x3d110 in run_tty_loop ()
#7  0x3d030 in run ()
#8  0x3cf2c in realmain ()
#9  0x197d0 in main ()

Something other than double works, for example float:

Python 1.1.1 (Nov 16 1994)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam

Quote:
>>> import struct
>>> struct.pack('f', 1.0)
'?\200\000\000'

I verified with python 1.0.2 on Decstation that pack works there for
doubles as well.

Python 1.0.2 (Jun 26 1994)
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam

Quote:
>>> import struct
>>> struct.pack('d', 1.0)

'\000\000\000\000\000\000\360?'

I took a cursory look at code to see if there is something fishy going
on.  Unfortunately, I could not see anything immediately wrong.  I do
suspect some kind of alignment problem.

Take Care,

Harri
--
------------------------------------------------------



Sun, 04 May 1997 21:27:02 GMT  
 Bug in struct.pack() for Sparc Solaris 2.3?

h> I observed the following:

h> Python 1.1.1 (Nov 16 1994)
h> Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam

Quote:
>>> import struct
>>> struct.pack('d', 1.0)

h> Bus error (core dumped)

h> (gdb) bt
h> #0  0x22aa0 in struct_pack ()
h> #1  0x33114 in call_builtin ()
h> #2  0x3303c in call_object ()
h> #3  0x300dc in eval_code ()
h> #4  0x3da2c in run_node ()
h> #5  0x3d2d4 in run_tty_1 ()
h> #6  0x3d110 in run_tty_loop ()
h> #7  0x3d030 in run ()
h> #8  0x3cf2c in realmain ()
h> #9  0x197d0 in main ()

h> I took a cursory look at code to see if there is something fishy going
h> on.  Unfortunately, I could not see anything immediately wrong.  I do
h> suspect some kind of alignment problem.

I think that your suspicion is correct.  If you take a look at
Object/stringobject.h you will find:

   typedef struct {
        OB_VARHEAD
   #ifdef CACHE_HASH
        long ob_shash;
   #endif
        char ob_sval[1];
   } stringobject;

If the CACHE_HASH compile time option is enabled, the ob_sval field,
ends up 12 bytes from the start of the structure.  Since struct.pack
actually builds a string object to store the data, it is trying to put
a double on a 4 byte boundary.  On many machines, a double requires an
8 byte alignment.  At the cost of a little wasted space, you could make the
following change to stringobject.h

   typedef struct {
        OB_VARHEAD
   #ifdef CACHE_HASH
        long ob_shash;
   #endif
        union {
            char ob_sval[1];
            double align_me;
        } u;
   } stringobject;

   #define ob_sval u.ob_sval

--
Donald Beaudry                                V.I. Corporation

                  "So much code, so little time..."



Sun, 04 May 1997 22:53:54 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. glob bug on Solaris 2.3

2. TCL7.3 on Solaris 2.3 compilation bug

3. Nested structs and struct.pack

4. Bug with pack followed by grid, tk 8.0b2, Solaris 2.5

5. OW4.1 on Solaris 2.3

6. VW 2.0/Solaris 2.3: DLLCC race conditions?

7. Looking for Solaris 2.3 Smalltalk

8. Gambit-C 2.3 dynamic loading on Sun/Solaris

9. Does MIT Scheme run on Solaris 2.3?

10. Elk 2.2 on Solaris 2.3 - dlopen problems

11. gdb and multithread on Solaris 2.3

12. problem with gnat on solaris 2.3

 

 
Powered by phpBB® Forum Software