Intermittant segmentation fault with ctrl-c (threads and queues)

[cgoldberg]

BPO	5160
Superseder	bpo-1856: shutdown (exit) can hang or segfault with daemon threads running

^{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 2009-02-08.14:58:03.966>
created_at = <Date 2009-02-05.21:11:51.636>
labels = ['interpreter-core', 'type-crash']
title = 'Intermittant segmentation fault with ctrl-c (threads and queues)'
updated_at = <Date 2009-02-08.14:58:03.965>
user = 'https://bugs.python.org/cgoldberg'

bugs.python.org fields:

activity = <Date 2009-02-08.14:58:03.965>
actor = 'ocean-city'
assignee = 'none'
closed = True
closed_date = <Date 2009-02-08.14:58:03.966>
closer = 'ocean-city'
components = ['Interpreter Core']
creation = <Date 2009-02-05.21:11:51.636>
creator = 'cgoldberg'
dependencies = []
files = []
hgrepos = []
issue_num = 5160
keywords = []
message_count = 5.0
messages = ['81228', '81233', '81255', '81357', '81382']
nosy_count = 2.0
nosy_names = ['ocean-city', 'cgoldberg']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '1856'
type = 'crash'
url = 'https://bugs.python.org/issue5160'
versions = ['Python 2.5']

[cgoldberg]

I can get the Python interpreter to core dump when running the following
code:

http://pastebin.com/f261f398f

To reproduce:

• run the above code and press ctrl-c to quit while it is running. It
  crashes (segfault) the interpreter every few times you stop it like this.

I think it has something to do with the thread launching another thread
containing a queue.

• Tested on Windows XP and Ubuntu Linux 8.10 (both running Python 2.5.2)

[cgoldberg]

little more info:

If you create a Queue in the main thread and pass this to each worker
thread, it works fine.

If you create the Queue inside the worker thread and then pass it to a
new thread, it can crash.

when it crashes, you get an immediate core dump with no error messages
or stack trace.

This happens very intermittently but can be reproduced easily.

[ocean-city]

Here is stack trace.

PyEval_EvalFrameEx(_frame * 0x00a62060, int 83) line 2841 + 6 bytes
fast_function(_object * 0x00000000, _object * * * 0x00fbfa98, int 1, int
1, int 9870576) line 3946
call_function(_object * * * 0x00fbfa98, int 0) line 3880 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a60ac0, int 131) line 2515
fast_function(_object * 0x00000000, _object * * * 0x00fbfbe0, int 1, int
1, int 9870576) line 3946
call_function(_object * * * 0x00fbfbe0, int 0) line 3880 + 16 bytes
PyEval_EvalFrameEx(_frame * 0x00a60918, int 131) line 2515
PyEval_EvalCodeEx(PyCodeObject * 0x00a142c8, _object * 0x00a60918,
_object * 0x00000001, _object * * 0x00a194ac, int 1, _object * *
0x00000000, int 0, _object * * 0x00000000, int 0, _object * 0x00000000)
line 3104 + 11 bytes
function_call(_object * 0x00a35350, _object * 0x00a19498, _object *
0x00000000) line 529 + 64 bytes
PyObject_Call(_object * 0x00a35350, _object * 0x00a19498, _object *
0x00000000) line 2506 + 15 bytes
instancemethod_call(_object * 0x00a35350, _object * 0x00a19498, _object

• 0x00000000) line 2579 + 17 bytes
  PyObject_Call(_object * 0x009fdef8, _object * 0x008c1038, _object *
  0x00000000) line 2506 + 15 bytes
  PyEval_CallObjectWithKeywords(_object * 0x009fdef8, _object *
  0x008c1038, _object * 0x00000000) line 3729
  t_bootstrap(void * 0x008c7608) line 426 + 26 bytes
  bootstrap(void * 0x00234d08) line 122 + 7 bytes
  _threadstartex(void * 0x009aeaf0) line 227 + 13 bytes
  KERNEL32! 77e5b3bc()

//////////////////////////////////////////

	if (tstate->frame->f_exc_type != NULL) /* crash: tstate->frame is NULL */
		reset_exc_info(tstate);
	else {
		assert(tstate->frame->f_exc_value == NULL);
		assert(tstate->frame->f_exc_traceback == NULL);
	}

[cgoldberg]

note:
on Windows Vista it is not ery intermittant :)
crashes every time the program is stopped.

[ocean-city]

This seems to be duplicate of bpo-1856. Let me close this entry.