[issue4358] Segfault in stringobject.c

[STINNER Victor]

STINNER Victor  added the comment:

There are not enough informations to reproduce the issue or understand 
the problem. Since farshad didn't answer since 4 months, I choose to 
close the bug. Reopen the bug if you have new informations!

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[STINNER Victor]

STINNER Victor  added the comment:

farshad: Is the bug still open? If yes, can you give more 
informations? If you don't answer, I will have to close this issue 
because it's not possible find the bug with so few informations :-/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

> The application is a web service with postgresql backend, so it
> heavily uses pyexpat and pygresql in a threaded environment.

pyexpat or pygresql is maybe not thread safe. To catch such error, you 
have to use Valgrind. And to use Valgrind, you have to recompile 
Python with the define "Py_USING_MEMORY_DEBUGGER": read 
Misc/valgrind.supp (comments at the top). Then, 
use "valgrind --suppressions=Misc/valgrind.supp  
". You might also try 
helgrind: "valgrind --tool=helgrind --suppressions=Misc/valgrind.supp 
 ".

Note: remember me to translate this article to english!
http://www.haypocalc.com/blog/index.php/2008/08/22/160-deboguer-programme-python-avec-gdb

--
nosy: +haypo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[Farshad Khoshkhui]

Farshad Khoshkhui <[EMAIL PROTECTED]> added the comment:

No, there isn't any custom made C extension, nor I'm using ctypes. (It
was a mistake selecting ctypes).
The application is a web service with postgresql backend, so it heavily
uses pyexpat and pygresql in a threaded environment. 
I'll recompile python with pydebug and get back with results.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

This is difficult: the backtrace only show plain python operations.
Some hints though:

One backtrace shows a memory corruption in the obmalloc data. This may come 
from a 
buffer overrun.

You initially selected ctypes in "Components", does this mean that your program 
also use ctypes?
With ctypes it is easy to be caught with a python string converted to a 
(mutable) 
char* pointer.

For example, on Windows:
>>> import ctypes
>>> c = ctypes.CDLL('msvcrt')
>>> a = ""
>>> c.strcpy(a, "X" * 50)
50
>>> a
''
... and the crash is not far.

Another case of corruption in obmalloc is to try to allocate python objects 
while 
the GIL is not held. This may happen if you wrote a C function that uses the 
Python API, and call this with ctypes.

In any case, I suggest that you build and a use a debug-enabled version of 
python 
(configure with --with-pydebug). It catches some errors earlier and sometimes 
more 
reliably.

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[Thomas Heller]

Changes by Thomas Heller <[EMAIL PROTECTED]>:


--
assignee: theller -> 
nosy:  -theller

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

Has nothing to do with ctypes (the package), unassigning.

--
components:  -ctypes

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[Farshad Khoshkhui]

Farshad Khoshkhui <[EMAIL PROTECTED]> added the comment:

Another Backtrace. I have three other core dumps with exact same
backtrace on two different machines.

Added file: http://bugs.python.org/file12064/backtrace2

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4358] Segfault in stringobject.c

[Farshad Khoshkhui]

New submission from Farshad Khoshkhui <[EMAIL PROTECTED]>:

I'm encountering random segfaults on multiple machines. By examining
core dumps, it's all happening  in stringobject.c (_PyString_Resize or
string_join). 
By using pyframev I figured out it's always happening inside
xmlrpclib.py (/usr/lib/python2.5/xmlrpclib.py (716): dump_struct or
/usr/lib/python2.5/xmlrpclib.py (627): dumps)

I'm using Python 2.5.2 on debian in a threaded environment with heavy
use of xmlrpc.

--
assignee: theller
components: XML, ctypes
files: backtrace1
messages: 76066
nosy: farshad, theller
severity: normal
status: open
title: Segfault in stringobject.c
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file12063/backtrace1

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com