3 ms·

A quick search in bugs.python.org shows several crashes. I don’t know much about Python. Is there anything particularly special about this one?

coolreader18 7y ago
Not necessarily, but I just found it interesting that it wasn't really anything all that crazy - it could in theory be possible to encounter this in a big enough code base that makes heavy use of coroutines and custom exception types.
- xapata 7y ago
  It is crazy to have a class constructor return something that isn't an instance of the class. That's nonsense code and is unlikely to occur in a codebase of any size, regardless of how often they define custom exception types. I wouldn't have bothered filing the bug.
  - saagarjha 7y ago
    The Python interpreter should not segfault for this.
    - xapata 7y ago
      Yes, of course. But is it worth your time to fix it? Probably not. If I jump on my bed enough, it'd probably break, but I'm not complaining to the manufacturer about the issue.
      - serf 7y ago
        to re-analogize with tools : if I used my Snap-On(tm) wrench as a prybar (incorrect usage) and broke it, Snap-On would still replace it in exchange for the broken tool and knowledge of the situation that broke it. To pretend that a language bug isn't worth reporting because you and your codebases will never encounter it seems short-sighted. Down the line, years from now, who knows what you'll have to do to get something to work. Maybe it'll be something this silly, and you'll be happy that the folks before you encountered it and remediated it. All that said, from a practical standpoint I agree with you. If you're doing something wacky, and it turns out as wacky as you thought it would, you're probably attacking the problem from the wrong angle, anyway. I just want to remind everyone that 'wacky' things are required and implemented daily in codebases around the world -- regardless of how bad they smell.
mentat 7y ago
I read it as related to the "limit Python to 1 million lines so it can be stable."
- OskarS 7y ago
  These two things have nothing to do with each other. The 1 million limit wouldn't have any effect here.
lucy_gatenby 7y ago
Just for fun, here's another one: import sys, threading def r(): sys.stdin.buffer.read(1) t = threading.Thread(target=r, daemon=True) t.start()
- saagarjha 7y ago
  At least that one is an abort…
- Thorrez 7y ago
  Here's a Python 2 segfault I ran into recently. import sys, threading, time t = threading.Thread(target=sys.stdin.read, args=(1,)) t.start() time.sleep(1) sys.stdin.close() Run it then after a few seconds press enter. It doesn't segfault in Python 3, but it still doesn't behave how I'd like, because I would like the close() to unblock the read(), but it doesn't unblock the read(), the read() still hangs until it gets some input.
  - loeg 7y ago
    The whole threading library in Python is a mess. Python was designed around single threaded programs with shared-nothing state and the cracks show as you move beyond that. The whole idea of replacing the GIL with... multiple same-process distinct-state Python interpreters with cheap-ish message passing sort of highlights how ugly it gets.
    - h2odragon 7y ago
      Back around python 1.5, there was almost a fork of python where every object had locks, there were memory arenas, and multiprocessing was almost thoughtlessly easy. That and stackless would've been great.
      - PixyMisa 7y ago
        It was also terribly slow. IronPython did that too, on .Net. It ran around one quarter the speed of CPython.

coolreader18 7y ago

Not necessarily, but I just found it interesting that it wasn't really anything all that crazy - it could in theory be possible to encounter this in a big enough code base that makes heavy use of coroutines and custom exception types.

xapata 7y ago
It is crazy to have a class constructor return something that isn't an instance of the class. That's nonsense code and is unlikely to occur in a codebase of any size, regardless of how often they define custom exception types. I wouldn't have bothered filing the bug.
- saagarjha 7y ago
  The Python interpreter should not segfault for this.
  - xapata 7y ago
    Yes, of course. But is it worth your time to fix it? Probably not. If I jump on my bed enough, it'd probably break, but I'm not complaining to the manufacturer about the issue.
    - serf 7y ago
      to re-analogize with tools : if I used my Snap-On(tm) wrench as a prybar (incorrect usage) and broke it, Snap-On would still replace it in exchange for the broken tool and knowledge of the situation that broke it. To pretend that a language bug isn't worth reporting because you and your codebases will never encounter it seems short-sighted. Down the line, years from now, who knows what you'll have to do to get something to work. Maybe it'll be something this silly, and you'll be happy that the folks before you encountered it and remediated it. All that said, from a practical standpoint I agree with you. If you're doing something wacky, and it turns out as wacky as you thought it would, you're probably attacking the problem from the wrong angle, anyway. I just want to remind everyone that 'wacky' things are required and implemented daily in codebases around the world -- regardless of how bad they smell.

mentat 7y ago

I read it as related to the "limit Python to 1 million lines so it can be stable."

OskarS 7y ago
These two things have nothing to do with each other. The 1 million limit wouldn't have any effect here.

lucy_gatenby 7y ago

Just for fun, here's another one: import sys, threading def r(): sys.stdin.buffer.read(1) t = threading.Thread(target=r, daemon=True) t.start()

saagarjha 7y ago
At least that one is an abort…
Thorrez 7y ago
Here's a Python 2 segfault I ran into recently. import sys, threading, time t = threading.Thread(target=sys.stdin.read, args=(1,)) t.start() time.sleep(1) sys.stdin.close() Run it then after a few seconds press enter. It doesn't segfault in Python 3, but it still doesn't behave how I'd like, because I would like the close() to unblock the read(), but it doesn't unblock the read(), the read() still hangs until it gets some input.
- loeg 7y ago
  The whole threading library in Python is a mess. Python was designed around single threaded programs with shared-nothing state and the cracks show as you move beyond that. The whole idea of replacing the GIL with... multiple same-process distinct-state Python interpreters with cheap-ish message passing sort of highlights how ugly it gets.
  - h2odragon 7y ago
    Back around python 1.5, there was almost a fork of python where every object had locks, there were memory arenas, and multiprocessing was almost thoughtlessly easy. That and stackless would've been great.
    - PixyMisa 7y ago
      It was also terribly slow. IronPython did that too, on .Net. It ran around one quarter the speed of CPython.