Setting max-specpdl-size of 34295 allows segfaults with 'simple' elisp

Bug #508618 reported by themusicgod1
2
Affects Status Importance Assigned to Milestone
emacs23 (Ubuntu)
New
Undecided
Unassigned
emacs24 (Ubuntu)
New
Undecided
Unassigned
emacs25 (Debian)
New
Unknown
emacs25 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: emacs23

Setting max-specpdl-size higher than 34295, and then running the following code results in a segfault of emacs. I am
running a system of mostly 9.04 with some packages (such as this one) upgraded. I know it's kind of pushing emacs to the limit, but still; this seems like an arbitrary limit on emacs' otherwise diety-like functionality. What should happen is emacs should continue to fail to execute with "file-truename: Variable binding depth exceeds max-specpdl-size" as it does below 34295., or at the very least when setting max-specpdl-size higher than 34295 it should warn you that you are making some kind of error if this is not acceptable.

example code:

(defun por (pcurrent pb numberleft)
       (if (= numberleft 0)
           pcurrent
    (por (- (+ pcurrent pb) (* pcurrent pb)) pb (- numberleft 1))))

(por 0 0.01 10000)

(setq max-lisp-eval-depth 1000000) ; this may be necessary, but doesn't appear to be the problem
(setq max-specpdl-size 34295) ; setting this lower results in predictable, expected behaviour - emacs refuses to run the result, citing max-specpdl-size not high enough. Setting this higher (like...34296), results in a segfault of emacs

emacs23:
  Installé : 23.1+1-4ubuntu3
  Candidat : 23.1+1-4ubuntu3
 Table de version :
 *** 23.1+1-4ubuntu3 0
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: emacs23 23.1+1-4ubuntu3
ProcEnviron:
 PATH=(custom, user)
 LANG=fr_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: emacs23
Uname: Linux 2.6.28-16-generic x86_64
UnreportableReason: Ceci n'est pas un authentique paquet Ubuntu

Revision history for this message
themusicgod1 (themusicgod1) wrote :
Revision history for this message
themusicgod1 (themusicgod1) wrote :

should be (por 0 0.01 100000)

Revision history for this message
themusicgod1 (themusicgod1) wrote :

I should note that it isn't hitting memory limits on my system (unless it's trying to allocate too fast or something) -- top shows I have gigs of ram to spare. Just tried on karmic's emacs23, as well as debian syd: bug still exists.

Revision history for this message
themusicgod1 (themusicgod1) wrote :

I meant debian sid <_<. Freudian slip.

Revision history for this message
themusicgod1 (themusicgod1) wrote :

This appears to be fixed in emacs version 23.1.91, not 100% sure but seems to be.

Revision history for this message
themusicgod1 (themusicgod1) wrote :

...or not, disregard #5. Seemed to be working for abit but it's back to segfaulting again. Hmm...

Revision history for this message
themusicgod1 (themusicgod1) wrote :

Backtrace:

#0 0x00000000005fccda in Feval (form=Cannot access memory at address 0x7fff7aa96fc8
) at eval.c:2217
#1 0x00000000005fd0e6 in Feval (form=17203878) at eval.c:2311
#2 0x00000000005fea9a in apply_lambda (fun=17203526, args=17203734, eval_flag=1) at eval.c:3122
#3 0x00000000005fd584 in Feval (form=17203974) at eval.c:2406
#4 0x00000000005f9a29 in Fprogn (args=17203558) at eval.c:415
#5 0x00000000005f995c in Fif (args=17204006) at eval.c:364
#6 0x00000000005fd033 in Feval (form=17204070) at eval.c:2293
#7 0x00000000005f9a29 in Fprogn (args=17203542) at eval.c:415
#8 0x00000000005fee7e in funcall_lambda (fun=17203526, nargs=3, arg_vector=0x7fff7aa97780) at eval.c:3204
#9 0x00000000005feb31 in apply_lambda (fun=17203526, args=17203734, eval_flag=1) at eval.c:3135

At least from the past few versions of the source (23.2.9x), the crash always happened one layer below eval.c line 2311,

          while (!NILP (args_left))
            {
              vals[argnum++] = Feval (Fcar (args_left)); <--- this line, in Feval.
              args_left = Fcdr (args_left);
              gcpro3.nvars = argnum;
            }

Looking at the cons cells of args_left it seems like the first(?) actual symbol contains an unreadable memory location. But why this is happening, I don't know. Trigger-happy GC (GCPRO3 is called before this code block) perhaps? I looked through the entire last_marked array but didn't see anything that would correlate with anything else that I saw.

Revision history for this message
themusicgod1 (themusicgod1) wrote :

(needless to say there was more to the backtrace than that, about 3-5000 frames worth after #9)

and version 23.1.9x which still has the bug

Revision history for this message
themusicgod1 (themusicgod1) wrote :

just making clear this still does exist in emacs24

Revision history for this message
themusicgod1 (themusicgod1) wrote :

Still valid in Ubuntu 15.10 / emacs 24.4+1-4ubuntu1

Revision history for this message
themusicgod1 (themusicgod1) wrote :

still valid in ubuntu 16.04 / emacs 24.5+1-6ubuntu1

tags: added: xenial
tags: added: yakkety
Revision history for this message
era (era) wrote :

Did you ever attempt to report this upstream? Does the bug exist in a recent emacs-snapshot? If so, we should probably forward this to the Emacs maintainers rather than have it linger here.

Revision history for this message
themusicgod1 (themusicgod1) wrote :

I don't remember and don't see anything in debian's bug tracking system.
That said... I can no longer crash emacs25 in zesty with the above sample code. The code still doesn't work...but the bug in question here (crashing the entirety of emacs) no longer exists.

Revision history for this message
themusicgod1 (themusicgod1) wrote :
Download full text (9.4 KiB)

reproduced same kind of issue in emacs 25 using slightly more complicated lisp code, plenty of ram left:

first file seqfile1:

(setq undo-outer-limit (expt 2 23))
(setq max-lisp-eval-depth (expt 2 17))
(setq max-specpdl-size (expt 2 17))
(setq message-log-max 40000)
(setq shell-command-default-error-buffer 'stderror-buffe)
(setq max-lisp-eval-depth (expt 2 16))
(defun insert (L)
          (message "insert into urls values ('%s',%i);" L counter)
          (setq counter (+ 1 counter))
)
(defun insertall (L)
          (map 'insert L))
(setq counter 28531843)
(insertall
'(

seqfile2:
seq 11718 > seqfile1

seqfile3:
))

cat seqfile1 seqfile2 seqfile3 > seqfile4

run each command in seqfile4 in order, same result: emacs segfault after #77287 frames, plent of ram left

slightly different stack trace (but that could be because it's got different lisp code leading to it)

virtual memory at segfault; 458mb
resident memory: 75mb
shared memory 34.9mb

#0 0x00007fb13d43b53f in raise (sig=sig@entry=11)
    at ../sysdeps/unix/sysv/linux/raise.c:58
#1 0x00000000004f0f04 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:381
#2 0x000000000050929e in handle_fatal_signal (sig=sig@entry=11)
    at sysdep.c:1601
#3 0x00000000005094c9 in deliver_thread_signal (sig=sig@entry=11, handler=0x509290 <handle_fatal_signal>) at sysdep.c:1575
#4 0x000000000050952f in deliver_fatal_thread_signal (sig=11) at sysdep.c:1613
#5 0x000000000050952f in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1695
#6 0x00007fb13d43b670 in <signal handler called> ()
    at /lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00000000004aa56c in bidi_resolve_weak (bidi_it=bidi_it@entry=0x7ffd69b29600) at bidi.c:2173
#8 0x00000000004ab31f in bidi_find_bracket_pairs (bidi_it=bidi_it@entry=0x7ffd69b29600) at bidi.c:2679
#9 0x00000000004ab9e5 in bidi_resolve_brackets (bidi_it=bidi_it@entry=0x7ffd69b29600) at bidi.c:2852
#10 0x00000000004abadc in bidi_resolve_neutral (bidi_it=bidi_it@entry=0x7ffd69b29600) at bidi.c:2953
#11 0x00000000004ac018 in bidi_type_of_next_char (bidi_it=0x7ffd69b29600)
    at bidi.c:3158
#12 0x00000000004ac018 in bidi_level_of_next_char (bidi_it=bidi_it@entry=0x7ffd69b29600) at bidi.c:3225
#13 0x00000000004acf1f in bidi_move_to_visually_next (bidi_it=bidi_it@entry=0x7ffd69b29600) at bidi.c:3418
#14 0x0000000000444350 in set_iterator_to_next (it=it@entry=0x7ffd69b28c60, reseat_p=reseat_p@entry=true) at xdisp.c:7428
#15 0x000000000044557f in move_it_in_display_line_to (it=it@entry=0x7ffd69b28c60, to_charpos=to_charpos@entry=105, to_x=to_x@entry=-1, op=op@entry=MOVE_TO_POS)
    at xdisp.c:9012
#16 0x0000000000446fd2 in move_it_to (it=it@entry=0x7ffd69b28c60, to_charpos=105, to_x=to_x@entry=-1, to_y=to_y@entry=-1, to_vpos=to_vpos@entry=-1, op=op@entry=8) at xdisp.c:9333
#17 0x00000000004513d8 in resize_mini_window (w=w@entry=0x112cc30, exact_p=exact_p@entry=false) at xdisp.c:10989
#18 0x000000000045158e in display_echo_area_1 (a1=18009136, a2=<optimized out>)
    at xdisp.c:10864
#19 0x0000000000431e1d in with_echo_area_buffer (w=w@entry=0x112cc30, which=which@entry=0, fn=fn@entry=
    0x451...

Read more...

tags: added: zesty
tags: added: artful
Revision history for this message
themusicgod1 (themusicgod1) wrote :

Looks like my example code needed 'map'
(defun map (f l)
  "map function?"
  (if
  (nullp l)
  '()
    (if (listp l)
    (if (= 1 (length l))
    (list (funcall f (car l)))
  (if (> (length l) 1)
       (cons (map f (car l))
     (map f (cdr l)))))
  (funcall f l)
  )))

tags: added: bionic
Revision history for this message
era (era) wrote :

Do you mean this is a new way to repro? Which replaces the old? (For all versions, or just the latest one you tried?)

If we are to finally report this upstream, can you provide a brief use case to assess the priority of this? If it's just an academic curiosity, I don't really see the point; but even in that case, it would make more sense for it to sit in the Emacs bug tracker where the people who can do something about it at least have a chance to stumble into it. Here, it's not doing anyone any good.

Changed in emacs25 (Debian):
status: Unknown → New
tags: added: cosmic
Revision history for this message
themusicgod1 (themusicgod1) wrote :

emacs26 in disco gives the error

"Re-entering top level after C stack overflow" which seems like an appropriate error.

Changed in emacs25 (Ubuntu):
status: New → Fix Committed
Changed in emacs25 (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.