Segmentation fault running XSV

[jbcombes]

BPO	893610
Nosy	@terryjreedy

^{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 2004-03-23.15:11:33.000>
created_at = <Date 2004-02-09.18:46:38.000>
labels = ['interpreter-core']
title = 'Segmentation fault running XSV'
updated_at = <Date 2004-03-23.15:11:33.000>
user = 'https://bugs.python.org/jbcombes'

bugs.python.org fields:

activity = <Date 2004-03-23.15:11:33.000>
actor = 'jbcombes'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-02-09.18:46:38.000>
creator = 'jbcombes'
dependencies = []
files = []
hgrepos = []
issue_num = 893610
keywords = []
message_count = 4.0
messages = ['19957', '19958', '19959', '19960']
nosy_count = 2.0
nosy_names = ['terry.reedy', 'jbcombes']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue893610'
versions = ['Python 2.3']

[jbcombes]

Python 2.3.* segfaults while running XSV. Python 2.2 is OK
I have no clue about what may be the problem.
Here is a backtrace by GDB :

(gdb) run commandLine.py

[New Thread 1024 (LWP 29583)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 29583)]
__pthread_mutex_lock (mutex=0x475) at mutex.c:99
99 mutex.c: No such file or directory.
in mutex.c
(gdb) bt
#0 __pthread_mutex_lock (mutex=0x475) at mutex.c:99
#1 0x400e2be8 in __libc_free (mem=0x4029d528) at
malloc.c:3152
#2 0x402f0dcf in Item_Dealloc (self=0x4029d528) at
NSLintermodule.c:2641
#3 0x080a7092 in call_function (pp_stack=0xbfffea2c,
oparg=2)
at Python/ceval.c:3467
#4 0x080a5667 in eval_frame (f=0x818a42c) at
Python/ceval.c:2116
#5 0x080a65f3 in PyEval_EvalCodeEx (co=0x402b6720,
globals=0x40273714,
locals=0x0, args=0x81e69d8, argcount=2,
kws=0x81e69e0, kwcount=0,
defs=0x403b5a38, defcount=1, closure=0x0) at
Python/ceval.c:2663
#6 0x080a8adb in fast_function (func=0x4025ef7c,
pp_stack=0xbfffebcc, n=2,
na=2, nk=0) at Python/ceval.c:3532
#7 0x080a7036 in call_function (pp_stack=0xbfffebcc,
oparg=2)
at Python/ceval.c:3458
#8 0x080a5667 in eval_frame (f=0x81e6874) at
Python/ceval.c:2116
#9 0x080a8a77 in fast_function (func=0x4025ef0c,
pp_stack=0xbfffecdc, n=2,
na=2, nk=0) at Python/ceval.c:3518
#10 0x080a7036 in call_function (pp_stack=0xbfffecdc,
oparg=2)
at Python/ceval.c:3458
#11 0x080a5667 in eval_frame (f=0x816c6d4) at
Python/ceval.c:2116
#12 0x080a8a77 in fast_function (func=0x402afe64,
pp_stack=0xbfffedec, n=2,
na=2, nk=0) at Python/ceval.c:3518
#13 0x080a7036 in call_function (pp_stack=0xbfffedec,
oparg=1)
at Python/ceval.c:3458
---Type <return> to continue, or q <return> to quit---
#14 0x080a5667 in eval_frame (f=0x81bc834) at
Python/ceval.c:2116
#15 0x080a65f3 in PyEval_EvalCodeEx (co=0x402641a0,
globals=0x4027335c,
locals=0x0, args=0x40345b00, argcount=3, kws=0x0,
kwcount=0,
defs=0x402b2db8, defcount=2, closure=0x0) at
Python/ceval.c:2663
#16 0x080e3def in function_call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
at Objects/funcobject.c:504
#17 0x0805a004 in PyObject_Call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
at Objects/abstract.c:1755
#18 0x08060cc3 in instancemethod_call (func=0x402afe2c,
arg=0x4020d2ec, kw=0x0)
at Objects/classobject.c:2433
#19 0x0805a004 in PyObject_Call (func=0x403c6c84,
arg=0x4020d2ec, kw=0x0)
at Objects/abstract.c:1755
#20 0x080a82ab in PyEval_CallObjectWithKeywords
(func=0x403c6c84,
arg=0x4020d2ec, kw=0x0) at Python/ceval.c:3346
#21 0x0805cd5f in PyInstance_New (klass=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
at Objects/classobject.c:575
#22 0x0805a004 in PyObject_Call (func=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
at Objects/abstract.c:1755
#23 0x080a8b66 in do_call (func=0x402c2b6c,
pp_stack=0xbffff2cc, na=2, nk=0)
at Python/ceval.c:3644
#24 0x080a704d in call_function (pp_stack=0xbffff2cc,
oparg=2)
at Python/ceval.c:3460
#25 0x080a5667 in eval_frame (f=0x814867c) at
Python/ceval.c:2116
---Type <return> to continue, or q <return> to quit---

#26 0x080a65f3 in PyEval_EvalCodeEx (co=0x40206520,
globals=0x401feb54, 
    locals=0x0, args=0x8159db0, argcount=12,
kws=0x8159de0, kwcount=0, 
    defs=0x40277620, defcount=11, closure=0x0) at
Python/ceval.c:2663
#27 0x080a8adb in fast_function (func=0x40347144,
pp_stack=0xbffff46c, n=12, 
    na=12, nk=0) at Python/ceval.c:3532
#28 0x080a7036 in call_function (pp_stack=0xbffff46c,
oparg=12)
    at Python/ceval.c:3458
#29 0x080a5667 in eval_frame (f=0x8159c04) at
Python/ceval.c:2116
#30 0x080a65f3 in PyEval_EvalCodeEx (co=0x402062e0,
globals=0x401feb54, 
    locals=0x0, args=0x819303c, argcount=15,
kws=0x8193078, kwcount=0, 
    defs=0x4026c628, defcount=14, closure=0x0) at
Python/ceval.c:2663
#31 0x080a8adb in fast_function (func=0x4034709c,
pp_stack=0xbffff60c, n=15, 
    na=15, nk=0) at Python/ceval.c:3532
#32 0x080a7036 in call_function (pp_stack=0xbffff60c,
oparg=15)
    at Python/ceval.c:3458
#33 0x080a5667 in eval_frame (f=0x8192ea4) at
Python/ceval.c:2116
#34 0x080a8a77 in fast_function (func=0x40202c34,
pp_stack=0xbffff71c, n=1, 
    na=1, nk=0) at Python/ceval.c:3518
#35 0x080a7036 in call_function (pp_stack=0xbffff71c,
oparg=1)
    at Python/ceval.c:3458
#36 0x080a5667 in eval_frame (f=0x812444c) at
Python/ceval.c:2116
#37 0x080a65f3 in PyEval_EvalCodeEx (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, closure=0x0) at Python/ceval.c:2663
#38 0x080a8976 in PyEval_EvalCode (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c) at Python/ceval.c:542
#39 0x080c4db1 in run_node (n=0x4019f488, 
    filename=0xbffffa73 "commandLine.py",
globals=0x401b879c, locals=0x401b879c, 
    flags=0xbffff89c) at Python/pythonrun.c:1265
#40 0x080c3781 in PyRun_SimpleFileExFlags (fp=0x8122288, 
    filename=0xbffffa73 "commandLine.py", closeit=1,
flags=0xbffff89c)
    at Python/pythonrun.c:862
#41 0x0805506a in Py_Main (argc=2, argv=0xbffff934) at
Modules/main.c:415
#42 0x4007e507 in __libc_start_main (main=0x8054980
<main>, argc=2, 
    ubp_av=0xbffff934, init=0x8053cb0 <_init>,
fini=0x80e6ae0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff92c)
    at ../sysdeps/generic/libc-start.c:129
(gdb)

[jbcombes]

Logged In: YES
user_id=116408

Quite strange. It works on Linux Mandrake 9.1, and segfaults
on redhat 7.2.

[terryjreedy]

Logged In: YES
user_id=593130

I know nothing of XSV, even if it is C or Python coded, so
can only offer generic comment: You are more likely to get
attention of voluteer patchers if you can pinpoint the line of
XSV code inducing the segfault.

It works on Linux Mandrake 9.1, and segfaults
on redhat 7.2

The header lines displayed in interactive mode describing the
respective builds might help explain. A possible reason is a
bug in the compiler or compilation mode (such as
optimization) in one and not the other.

Good luck. This is beyond my competance.

[jbcombes]

Logged In: YES
user_id=116408

Thanks tjreedy. I lack time to track it down, so => close.
Also a segfault noted on Solaris 2.8