This would not have happened in a language with a proper type system as the type checker would have rejected the program at compile time.
literally 3 seconds with google:"ghc segfault"
Make CPython segfault in 5 lines of code
31–40 of 78 posts
Re: Make CPython segfault in 5 lines of code
#32Even some "safe" python libraries can be segfaulted using similar techniques. See for example https://github.com/pydata/numexpr/issues/323
I think this particular bug is even marked 'wont fix'. But I cannot find the bpo at the moment.
Re: Make CPython segfault in 5 lines of code
#33If # of lines are important, this problem can actually be demonstrated in 1 line: for x, x.__new__ in [(__import__('queue').Full, print)]: __import__('glob').iglob(0).throw(x)
This doesn't trigger a segfault for me in Python 3.7, just an exception that `print_exception` expects an `Exception`. Someone commented below the gist with this one-liner: (i for i in []).throw(type('E', (BaseException,), dict(__new__=lambda cls, *args: cls))()) I managed to golf it a bit down to this ;): n="__new__";(i for i in []).throw(type(n,(IOError,),{n:lambda c,*a:c})())
Just one character but replace `[]` with `n` too :)
Re: Make CPython segfault in 5 lines of code
#34Earlier quoted context omitted.
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.
The Python interpreter should not segfault for this.
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.
Re: Make CPython segfault in 5 lines of code
#35Earlier quoted context omitted.
The Python interpreter should not segfault for this.
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.
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.
Re: Make CPython segfault in 5 lines of code
#36Earlier quoted context omitted.
> What does divide by zero do? Returns a value, of course! (And that said, JavaScript does have some trapped errors, such as (1/0).foo.foo (and yes you need the second .foo…)) IMO, the execution "error" here (in this thread) is accessing memory illegally. Sometimes the runtime traps it, but sometimes it does not, and "sometimes" isn't always, so its effectively untrapped as we cannot depend on the trap. (Especially i…
> such as (1/0).foo.foo (and yes you need the second .foo…) I don't understand the nuance here. In my Firefox developer tools, I can do the following: > (1/0).foo.foo ---> TypeError: (intermediate value).foo is undefined > (1/0).foo ---> undefined > (1/1).foo.foo ---> TypeError: 1.foo is undefined > Infinity.foo.foo ---> TypeError: Infinity.foo is undefined > undefined.foo ---> TypeError: undefined has no properties…
The point they were making is that (1/0).foo is not an error, as it returns a value.
Re: Make CPython segfault in 5 lines of code
#37Segfaults in scripting languages are remarkably common, especially if arbitrary bytecode can be loaded into the VM. One I ran into in the wild recently is that in older versions of Lua, exceptions in GC finalizers (the `__gc` metamethod) can trigger a segfault. In those same versions of Lua, the bytecode format is notoriously dangerous to load. I wonder whether this will be a large component of newer scripting langua…
Is anybody fuzzing Python bytecodes? This sounds like a super-great application for afl.
You don't need a fuzzer. Python doesn't do bounds checking of stack manipulation. This is not considered a bug
Re: Make CPython segfault in 5 lines of code
#38Earlier quoted context omitted.
> What does divide by zero do? Returns a value, of course! (And that said, JavaScript does have some trapped errors, such as (1/0).foo.foo (and yes you need the second .foo…)) IMO, the execution "error" here (in this thread) is accessing memory illegally. Sometimes the runtime traps it, but sometimes it does not, and "sometimes" isn't always, so its effectively untrapped as we cannot depend on the trap. (Especially i…
> such as (1/0).foo.foo (and yes you need the second .foo…) I don't understand the nuance here. In my Firefox developer tools, I can do the following: > (1/0).foo.foo ---> TypeError: (intermediate value).foo is undefined > (1/0).foo ---> undefined > (1/1).foo.foo ---> TypeError: 1.foo is undefined > Infinity.foo.foo ---> TypeError: Infinity.foo is undefined > undefined.foo ---> TypeError: undefined has no properties…
None of those are trapped errors.
In Python, Java, C, OCaml, and most other languages, 1 / 0 aborts the program. That is, division by zero is a trapped error.
In JavaScript, it's not. It keeps going and lets you do stuff like access nonexistent properties .foo on the result, which are also untrapped errors.
So JavaScript is unsafe in Cardelli's terminology. It gives you untrapped errors rather than trapped ones. The program keeps chugging along until you find out later and have to trace backwards to the bug.
Re: Make CPython segfault in 5 lines of code
#39Earlier quoted context omitted.
> such as (1/0).foo.foo (and yes you need the second .foo…) I don't understand the nuance here. In my Firefox developer tools, I can do the following: > (1/0).foo.foo ---> TypeError: (intermediate value).foo is undefined > (1/0).foo ---> undefined > (1/1).foo.foo ---> TypeError: 1.foo is undefined > Infinity.foo.foo ---> TypeError: Infinity.foo is undefined > undefined.foo ---> TypeError: undefined has no properties…
None of those are trapped errors. In Python, Java, C, OCaml, and most other languages, 1 / 0 aborts the program. That is, division by zero is a trapped error. In JavaScript, it's not. It keeps going and lets you do stuff like access nonexistent properties .foo on the result, which are also untrapped errors . So JavaScript is unsafe in Cardelli's terminology. It gives you untrapped errors rather than trapped ones. The…
It's Infinity in Haskell
Prelude> 1.0 / 0.0 :: Double
InfinityRe: Make CPython segfault in 5 lines of code
#40Earlier quoted context omitted.
None of those are trapped errors. In Python, Java, C, OCaml, and most other languages, 1 / 0 aborts the program. That is, division by zero is a trapped error. In JavaScript, it's not. It keeps going and lets you do stuff like access nonexistent properties .foo on the result, which are also untrapped errors . So JavaScript is unsafe in Cardelli's terminology. It gives you untrapped errors rather than trapped ones. The…
It's Infinity in Haskell Prelude> 1.0 / 0.0 :: Double Infinity
Because / is floating point division, and infinity is a defined value in floating point numbers.
Try it again with div for integer division.