3 ms·

You can crash Emacs for example with the recipe from #2099: $ emacs -Q --eval "(let (v) (while t (setq v (cons v v))))" In response to how such deep struct

by zmonx 9y ago

You can crash Emacs for example with the recipe from #2099: $ emacs -Q --eval "(let (v) (while t (setq v (cons v v))))" In response to how such deep structures can arise: They may for example arise when testing Emacs with randomly generated code snippets. For testing edge cases, it is highly desirable that Emacs run robustly also in such situations.

stevekemp 9y ago
Indeed emacs should be robust. I recently ran some fuzz-testing of Emacs, and found evaluating a similar recursive example would crash it: https://blog.steve.fi/i_ve_never_been_more_proud.html https://blog.steve.fi/i_ve_never_been_more_proud.html My case was resolved (a file with a few thousand "`" characters), but despite running more fuzzing I couldn't get any other interesting results.
- kazinator 9y ago
  I use AFL (American Fuzzy Lop) on TXR from time to time. And, guess what, there was also a problem with nested backquotes. Backquote is spelled ^ (caret) in TXR Lisp, so the cases that were triggering the degenerate behavior had ^^^^^^^ rather than ```````... http://www.kylheku.com/cgit/txr/commit/?id=ab98634ea8992722046ab857ec0eaec7cb024761 http://www.kylheku.com/cgit/txr/commit/?id=ab98634ea89927220...
  - stevekemp 9y ago
    Small world. This is my bug-report, which meandered a little: https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-07/msg00133.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-07/msg...
kazinator 9y ago
That loop doesn't release any of the objects that it creates; the pointer v always hangs on to every cons cell that was created. So there is nothing for the garbage collector to do here other than to confirm that everything is reachable and not actually reclaim anything. If we disable garbage collection, it will hit OOM. Die here, die there. BTW: (setq v (cons v v)) -> (push v v)
- zmonx 9y ago
  Whatever it does, I expect Emacs to not crash. If it cannot allocate more memory, I expect it to throw a Lisp exception that tells me so, not to crash the whole process. I greatly appreciate Daniel's work to increase the robustness of Emacs, because it means that there will be fewer situations where a process crash leads to lost work for users. In addition, increasing the robustness of Emacs in such cases will also greatly broaden the set of test cases that can be run reliably, and hence help to detect and correct even more issues.
  - kazinator 9y ago
    Without a question, if cons cannot allocate, it should throw some exception; the code with its best intentions should be there. That way, someone who can tune their operating system or run on a MMU-less system can take advantage of it. The rest of the people won't actually it though; their system will thrash and either it or they will kill the offending process before it has a chance to reach that exception throw. That's if they don't run out of patience and just reboot the machine.

by zmonx 9y ago

stevekemp 9y ago

Indeed emacs should be robust. I recently ran some fuzz-testing of Emacs, and found evaluating a similar recursive example would crash it: https://blog.steve.fi/i_ve_never_been_more_proud.html https://blog.steve.fi/i_ve_never_been_more_proud.html My case was resolved (a file with a few thousand "`" characters), but despite running more fuzzing I couldn't get any other interesting results.

kazinator 9y ago
I use AFL (American Fuzzy Lop) on TXR from time to time. And, guess what, there was also a problem with nested backquotes. Backquote is spelled ^ (caret) in TXR Lisp, so the cases that were triggering the degenerate behavior had ^^^^^^^ rather than ```````... http://www.kylheku.com/cgit/txr/commit/?id=ab98634ea8992722046ab857ec0eaec7cb024761 http://www.kylheku.com/cgit/txr/commit/?id=ab98634ea89927220...
- stevekemp 9y ago
  Small world. This is my bug-report, which meandered a little: https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-07/msg00133.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-07/msg...

kazinator 9y ago

That loop doesn't release any of the objects that it creates; the pointer v always hangs on to every cons cell that was created. So there is nothing for the garbage collector to do here other than to confirm that everything is reachable and not actually reclaim anything. If we disable garbage collection, it will hit OOM. Die here, die there. BTW: (setq v (cons v v)) -> (push v v)

zmonx 9y ago
Whatever it does, I expect Emacs to not crash. If it cannot allocate more memory, I expect it to throw a Lisp exception that tells me so, not to crash the whole process. I greatly appreciate Daniel's work to increase the robustness of Emacs, because it means that there will be fewer situations where a process crash leads to lost work for users. In addition, increasing the robustness of Emacs in such cases will also greatly broaden the set of test cases that can be run reliably, and hence help to detect and correct even more issues.
- kazinator 9y ago
  Without a question, if cons cannot allocate, it should throw some exception; the code with its best intentions should be there. That way, someone who can tune their operating system or run on a MMU-less system can take advantage of it. The rest of the people won't actually it though; their system will thrash and either it or they will kill the offending process before it has a chance to reach that exception throw. That's if they don't run out of patience and just reboot the machine.