python core dump (SIGBUS) on Solaris

[Gary Pennington - UK Performance Centre]

Hi,

I've encountered a fairly unusual problem using python on Solaris.
Before I investigate further, has anyone else already resolved this one?

Env:
Solaris 2.6 (all latest relevant patches)
compiler egcs-2.91.66

Test case to reproduce core is pretty straightforward :-

python
>>> import Cookie
>>> C=Cookie.Cookie("webJudgeUser=garyp;")
>>> C

At this point when using python interactively, a sigbus is generated.

Here's some trace from gdb

foucalt:/home/garyp 82 $ gdb python
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.6"...
(gdb) run
Starting program: /usr/local/bin/python
[New LWP    2        ]
[New LWP    3        ]
Python 1.5.2 (#1, Jul  6 1999, 16:50:14)  [GCC egcs-2.91.66 19990314
(egcs-1.1.2  on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
[New LWP    4        ]
>>> import Cookie
>>> C=Cookie.Cookie("webJudgeUser=garyp;")
>>> C

Program received signal SIGBUS, Bus error.
0xef2c5ab8 in _smalloc () from /usr/lib/libc.so.1
(gdb) info threads
  7 Thread 3          0xef647c14 in _swtch () from
/usr/lib/libthread.so.1
  6 Thread 2 (LWP 2)  0xef2b98d0 in _signotifywait () from
/usr/lib/libc.so.1
* 5 Thread 1 (LWP 1)  0xef2c5ab8 in _smalloc () from /usr/lib/libc.so.1
  4 LWP    4          0xef2b973c in ___lwp_cond_wait () from
/usr/lib/libc.so.1
  3 LWP    3          0xef2b699c in door_restart () from
/usr/lib/libc.so.1
  2 LWP    2          0xef2b98d0 in _signotifywait () from
/usr/lib/libc.so.1
  1 LWP    1          0xef2c5ab8 in _smalloc () from /usr/lib/libc.so.1
(gdb) where
#0  0xef2c5ab8 in _smalloc () from /usr/lib/libc.so.1
#1  0xef2c5b00 in malloc () from /usr/lib/libc.so.1
#2  0x4c094 in PyString_FromString (str=0x9d698 "<stdin>")
    at stringobject.c:145
#3  0x4d8d8 in PyString_InternFromString (cp=0x9d698 "<stdin>")
    at stringobject.c:1098
#4  0x2a434 in jcompile (n=0x0, filename=0xe0e90 "", base=0xe0ed8)
    at compile.c:3423
#5  0x2a328 in PyNode_Compile (n=0x11d938, filename=0x9d698 "<stdin>")
    at compile.c:3382
#6  0x32f94 in run_node (n=0x11d938, filename=0x9d698 "<stdin>",
    globals=0xe5b30, locals=0xe5b30) at pythonrun.c:883
#7  0x322f8 in PyRun_InteractiveOne (fp=0xffffffff, filename=0x9d698
"<stdin>")
    at pythonrun.c:528
#8  0x32120 in PyRun_InteractiveLoop (fp=0xd7430, filename=0x9d698
"<stdin>")
    at pythonrun.c:472
#9  0x32038 in PyRun_AnyFile (fp=0xd7430, filename=0x9d698 "<stdin>")
    at pythonrun.c:449
#10 0x1dfc4 in Py_Main (argc=1, argv=0xefffe844) at main.c:287
#11 0x1d9e4 in main (argc=1, argv=0xefffe844) at python.c:12
(gdb)


You can see that the problem is being manifested in _smalloc.

I started thinking about what the problem could be and I think it may be
related to the mymalloc routines which are used in the pypcre routines.
I seem to recall encountering problems before when there are multiple
malloc functions being used.

Does an instant remedy suggest itself to anyone?

Investigations to date:-

Rebuilt python without using threads - MADE NO DIFFERENCE
Tried different combinations of regex and it seems to fail only when 31
bytes are required.


Yours,

Gary Pennington
Sun UK