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. I
>> 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 h
> 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 a
On 2008-12-11 19:15, Adam Olsen wrote:
> On Thu, Dec 11, 2008 at 2:34 AM, Victor Stinner
> 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: "Se
On Thu, Dec 11, 2008 at 12:15 PM, Adam Olsen 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 handling. The
On Thu, Dec 11, 2008 at 2:34 AM, Victor Stinner
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 helps a
>> >> lot for
On Thu, Dec 11, 2008 at 10:08 AM, Jeffrey Yasskin wrote:
> On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
> 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
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 longj
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
>> 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
V
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 real
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
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. The
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 toda
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 Pyth
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
comma
>
> 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 als
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 P
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 o
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
condition
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
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
> 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 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
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, re
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, recovering would be likely (caveat emptor of course).
2008/12/10, Adam Olsen <[EMAIL
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 Python
On Wed, Dec 10, 2008 at 11:37 AM, 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 a
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 a
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. Using it, it's possible to catch them and
> > continue the execution of y
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
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 don'
32 matches
Mail list logo
