Comment 7 for bug 508618

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.