On Dec 11, 2008, at 3:05 PM, Martin v. Löwis wrote:
If it is actually possible to print a stack trace, that could be
useful indeed. I'm then skeptical that this is possible in the
general case (i.e. displaying the full C stack), but displaying
(parts of) the Python stack might be possible.
Le Wednesday 10 December 2008 20:04:00 Terry Reedy, vous avez écrit :
Recover after a segfault is dangerous, but my first goal was to get the
Python backtrace instead just one line: Segmentation fault. It helps a
lot for debug!
Exactly! That's why it doesn't belong in the Python core. We
If we could calculate how much stack is left we'd have a much more
robust way of doing recursion limits. I suppose this could be done by
reading a byte from each page with a temporary SIGSEGV handler
installed, but I'm not convinced you can't ask the platform directly
somehow. I'd also be
Simon Some indictation of what Python was executing when the segfault
Simon occurred would help narrow now the possibilities rapidly.
The Python distribution comes with a Misc/gdbinit file (you can grab it from
the Subversion source tree via the web as well) that defines a pystack
skip at pobox.com writes:
The Python distribution comes with a Misc/gdbinit file (you can grab it from
the Subversion source tree via the web as well) that defines a pystack
command. It will work with core files as well as running processes and
should give you a very good idea where your
Antoine Still, it would be much better if the stack trace could be
Antoine printed by Python itself rather than having to resort to gdb
Antoine wizardry. Especially if the problem is reported by one of your
Antoine non-developer users.
I understand. The guy has a problem today
skip at pobox.com writes:
I understand. The guy has a problem today for which there is a solution
that I posted. If he's been meaning to look into the problem and he's
posting to python-dev I presume he knows at least a little about running gdb
if he's operating in a Unix environment.
Hi Martin,
On Dec 11, 2008, at 12:12 AM, Martin v. Löwis wrote:
Several people already said (essentially) that: -1. I don't think such
code should be added to the Python core, no matter how smart or
correct
it is.
does your -1 apply only to attempts to resume execution after SIGSEGV,
or
Le Thursday 11 December 2008 13:57:03 [EMAIL PROTECTED], vous avez écrit :
Simon Some indictation of what Python was executing when the segfault
Simon occurred would help narrow now the possibilities rapidly.
The Python distribution comes with a Misc/gdbinit file
Hum, do you really
The Python distribution comes with a Misc/gdbinit file
Victor Hum, do you really run *all* programs in gdb? Most of the time,
Victor you don't expect a crash (because you trust your softwares). You
Victor will have to try to reproduce the crash, but sometimes it's very
On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
[EMAIL PROTECTED] wrote:
But if -as many people wrote-
Python is totally broken after a segfault, it is maybe not a good idea :-)
While it's true that after a segfault or unexpected longjmp, there are
no guarantees whatsoever about the state of
On Dec 11, 2008, at 11:08 AM, Jeffrey Yasskin wrote:
On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
[EMAIL PROTECTED] wrote:
But if -as many people wrote-
Python is totally broken after a segfault, it is maybe not a good
idea :-)
While it's true that after a segfault or unexpected
On Thu, Dec 11, 2008 at 10:08 AM, Jeffrey Yasskin jyass...@gmail.com wrote:
On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
But if -as many people wrote-
Python is totally broken after a segfault, it is maybe not a good idea :-)
While it's true that after
On Thu, Dec 11, 2008 at 2:34 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Le Wednesday 10 December 2008 20:04:00 Terry Reedy, vous avez écrit :
Recover after a segfault is dangerous, but my first goal was to get the
Python backtrace instead just one line: Segmentation fault. It
On Thu, Dec 11, 2008 at 12:15 PM, Adam Olsen rha...@gmail.com wrote:
You have to use the low-level stderr, nothing that invokes Python.
I'd hate to get a second segfault while printing the first.
Just think about how indirect refcounting bugs tend to be. Another
example is messing up GIL
On Dec 11, 2008, at 12:12 AM, Martin v. Löwis wrote:
Several people already said (essentially) that: -1. I don't think such
code should be added to the Python core, no matter how smart or correct
it is.
does your -1 apply only to attempts to resume execution after SIGSEGV,
or also to the
The Python distribution comes with a Misc/gdbinit file
Hum, do you really run *all* programs in gdb? Most of the time, you don't
expect a crash (because you trust your softwares). You will have to try to
reproduce the crash, but sometimes it's very hard (eg. Heisenbugs!).
You don't have
Hi,
I published a new version of my fault handler: it installs an handler for
signals SIGFPE and SIGSEGV. Using it, it's possible to catch them and
continue the execution of your Python program. Example:
try:
call_evil_code()
except MemoryError:
print A segfault? Haha, I
On Wed, Dec 10, 2008 at 4:06 AM, Victor Stinner
[EMAIL PROTECTED] wrote:
Hi,
I published a new version of my fault handler: it installs an handler for
signals SIGFPE and SIGSEGV. Using it, it's possible to catch them and
continue the execution of your Python program. Example:
This will of
On Wed, Dec 10, 2008 at 12:37 PM, Victor Stinner
[EMAIL PROTECTED] wrote:
Oh, I forgot the issue URL:
http://bugs.python.org/issue3999
I also attached an example of catching segfaults.
I published a new version of my fault handler: it installs an handler for
signals SIGFPE and SIGSEGV.
Benjamin Peterson wrote:
On Wed, Dec 10, 2008 at 12:37 PM, Victor Stinner
This will of course leave the program in an undefined state. It is
very likely to crash again, emit garbage, hang, or otherwise be
useless.
Recover after a segfault is dangerous, but my first goal was to get the
On Wed, Dec 10, 2008 at 12:22 PM, BJörn Lindqvist [EMAIL PROTECTED] wrote:
One thing i think it would be useful for in the real world is for
unittesting extension modules. You cant profitably write unit tests
for segfaults because that breaks the test harness. In situations like
those,
On 2008-12-10 21:05, Adam Olsen wrote:
On Wed, Dec 10, 2008 at 12:22 PM, BJörn Lindqvist [EMAIL PROTECTED] wrote:
One thing i think it would be useful for in the real world is for
unittesting extension modules. You cant profitably write unit tests
for segfaults because that breaks the test
I would appreciate a review, especially for the patch in Python/ceval.c.
In this specific case, it is not clear for what objective you want such
review. For inclusion into Python?
Several people already said (essentially) that: -1. I don't think such
code should be added to the Python core, no
On Wed, Dec 10, 2008 at 6:12 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
I would appreciate a review, especially for the patch in Python/ceval.c.
In this specific case, it is not clear for what objective you want such
review. For inclusion into Python?
Even if it does not result in an
On Wed, Dec 10, 2008 at 5:21 PM, Alexander Belopolsky
[EMAIL PROTECTED] wrote:
On Wed, Dec 10, 2008 at 6:12 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Several people already said (essentially) that: -1. I don't think such
code should be added to the Python core, no matter how smart or correct
On Wed, Dec 10, 2008 at 8:01 PM, Adam Olsen [EMAIL PROTECTED] wrote:
..
It is impossible to do in general, and I am -1 on any misguided
attempts to do so.
I agree, recovering from segfaults caused by buggy third party C
modules is a losing proposition, but for a limited number of
conditions
On Wed, Dec 10, 2008 at 8:37 PM, Victor Stinner
[EMAIL PROTECTED] wrote:
Recover after a segfault is dangerous, but my first goal was to get the Python
backtrace instead just one line: Segmentation fault. It helps a lot for
debug!
This would be extremely useful. I've had PyGTK segfault on me a
28 matches
Mail list logo
