Lily SEGV on unknown address with the test file binary_trees.lily.

[icytxw]

$ ./lily binary_trees.lily
Segmentation fault

The GDB debugging information is as follows:

(gdb) set args binary_trees.lily
(gdb) r
...
(gdb) x/10i $pc
=> 0x501d20 <lily_get_error+1520>: mov 0x7fff8000(%rax),%al
0x501d26 <lily_get_error+1526>: test %al,%al
0x501d28 <lily_get_error+1528>: jne 0x501dfe <lily_get_error+1742>
0x501d2e <lily_get_error+1534>: movzwl (%rdi),%ecx
0x501d31 <lily_get_error+1537>: mov %rsi,(%rsp)
0x501d35 <lily_get_error+1541>: xor %eax,%eax
0x501d37 <lily_get_error+1543>: mov 0x28(%rsp),%rdi
0x501d3c <lily_get_error+1548>: mov 0x30(%rsp),%r8
0x501d41 <lily_get_error+1553>: lea 0xd6578(%rip),%rsi # 0x5d82c0 <.str.177>
0x501d48 <lily_get_error+1560>: callq 0x5b9330 <lily_mb_add_fmt>
(gdb) i r rax
rax 0x1fffffffffffffff 2305843009213693951
(gdb) si

Program received signal SIGSEGV, Segmentation fault.
0x0000000000501d20 in build_error (parser=) at /home/icy/real/lily-asan/src/lily_parser.c:4836

4836 func->module->path, frame->code[-1], class_name,
(gdb) bt
#0 0x0000000000501d20 in build_error (parser=) at /home/icy/real/lily-asan/src/lily_parser.c:4836
#1 lily_get_error (s=) at /home/icy/real/lily-asan/src/lily_parser.c:5016
#2 0x00000000004f1dd4 in main (argc=, argv=) at /home/icy/real/lily-asan/run/lily.c:107
(gdb) c
Continuing.

ASAN:DEADLYSIGNAL

==63877==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000501d20 bp 0x0c0c00001670 sp 0x7fffffffe340 T0)
#0 0x501d1f (/home/icy/real/lily-asan/build/bin/lily+0x501d1f)
#1 0x4f1dd3 (/home/icy/real/lily-asan/build/bin/lily+0x4f1dd3)
#2 0x7ffff6ee682f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#3 0x41fd58 (/home/icy/real/lily-asan/build/bin/lily+0x41fd58)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/icy/real/lily-asan/build/bin/lily+0x501d1f)
==63877==ABORTING
[Inferior 1 (process 63877) exited with code 01]

The vulnerability was triggered in function build_error() at lily_parser.c:4836

4780 static void build_error(lily_parse_state *parser)
4781 {
...
4811 else {
4812 lily_call_frame *frame = parser->vm->call_chain;
4813
4814 lily_mb_add(msgbuf, "Traceback:\n");
4815
4816 while (frame->prev) {
4817 lily_function_val *func = frame->function;
4818 const char *class_name = func->class_name;
4819 const char *func_name = func->trace_name;
4820 char *separator = ".";
4821 if (class_name == NULL) {
4822 class_name = "";
4823 separator = "";
4824 }
4825 else if (strcmp(func_name, "") == 0) {
4826 func_name = "";
4827 separator = "";
4828 }
4829
4830 if (frame->function->code == NULL)
4831 lily_mb_add_fmt(msgbuf, " from [C]: in %s%s%s\n",
4832 class_name, separator, func_name);
4833 else
4834 lily_mb_add_fmt(msgbuf,
4835 " from %s:%d: in %s%s%s\n",
4836 func->module->path, frame->code[-1], class_name,
4837 separator, func_name);
4838
4839 frame = frame->prev;
4840 }
4841 }
4842 }

[FascinatedBox]

Strange. I don't see any issues when running it under valgrind, either normally or with -m32 on my own system.

What distro are you using to build Lily? Also, are you building from the latest version?

I'm quite confused about this because binary trees shouldn't be raising an exception at all, so that may be why it's crashing. The code[-1] section would fail if not properly within __main__. Can you figure out what's triggering a raise at all (if it's done through the vm, it'll go through maybe_catch_exception).

[icytxw]

Thank you for your attention, I run it under ubuntu16.04,64bit. I'll check the phenomenon again tomorrow @FascinatedBox

[icytxw]

I think it's a NullPointerException.Both ubuntu 16.04 and ubuntu 15.10 result in a crash.
Breakpoint 1, build_error (parser=) at /home/icy/real/lily/src/lily_parser.c:4836
4836 func->module->path, frame->code[-1], class_name,
(gdb) p *frame
$7 = {start = 0x868930, top = 0x868968, register_end = 0x869290, code = 0x0, function = 0x68f700,
return_target = 0x869ce0, prev = 0x86cbb0, next = 0x0}
(gdb) p frame->code[-1]
Cannot access memory at address 0xfffffffffffffffe

$ cat /etc/issue
Ubuntu 16.04.2 LTS \n \l

[FascinatedBox]

My apologies, I haven't run the benchmarking on my own system in quite some time. I saw both of your issues before heading out the door and feared that they were the cause of another arch or 32 bits.

I did a little bit of investigation while I was out. The underlying bug is that the recursion limit is being hit. I increased it to 20K and it's still being hit, and it was never hit before. But on top of that, the recursion limit raise isn't doing the code pointer fix that all other raises do as a preamble. That's why the crash is happening.

I didn't poke around much with the other bug, but my guess is that it happened during some hash api change.