luad_unittest segfault

[belm0]

I'm seeing luad_unittest segfault on Ubuntu x86_64 with DMD64 v2.059.

The backtrace is lacking symbol info so I'm not sure how to proceed. E.g.:

#0  0x00000000004a9280 in rt.deh2.terminate() ()
No symbol table info available.
#1  0x000000000049a576 in _d_throwc ()
No symbol table info available.
#2  0x0000000000000001 in ?? ()
No symbol table info available.
#3  0x000000000000002a in ?? ()
No symbol table info available.
...

[belm0]

Example phonebook segfaults as well, although hello and precompiled work.

[JakobOvrum]

The stack trace for luad_unittest looks like issue #35. What did the stack trace for the phonebook example look like?

[belm0]

The phonebook segfault appears to have been regarding panic handler as well. I was trying to invoke it as bin/phonebook and it wasn't able to find the data file. (BTW I don't think any source or data like contacts.lua should be kept in the bin directory. That would eliminate the complicated bin/.gitignore as well.)

Regarding -fno-omit-frame-pointer (assuming that's indeed the issue) I'm not sure what to do. I'm getting these failures against stock lua5.1 and luajit-5.1 Debian packages. It would be fairly hard to someday incorporate LuaD into the standard distributions unless this issue is resolved. (I'm the lua5.1 package maintainer BTW.)

[JakobOvrum]

The phonebook segfault appears to have been regarding panic handler as well. I was >trying to invoke it as bin/phonebook and it wasn't able to find the data file. (BTW I don't >think any source or data like contacts.lua should be kept in the bin directory. That >would eliminate the complicated bin/.gitignore as well.)

Indeed, you are correct. It used to be in the phonebook example directory, then copied to the output directory on build. I tried a few different post-build commands, but it always managed to crash VisualD, so the current setup is a workaround.

Regarding -fno-omit-frame-pointer (assuming that's indeed the issue) I'm not sure >what to do. I'm getting these failures against stock lua5.1 and luajit-5.1 Debian >packages. It would be fairly hard to someday incorporate LuaD into the standard >distributions unless this issue is resolved. (I'm the lua5.1 package maintainer BTW.)

Foregoing exceptions would be disastrous for D integration, which makes it a really difficult problem. Without proper stack unrolling, destructors aren't called and your program could be in all kinds of trouble. There are a lot of different solutions, but I can't think of one which is compatible with most stock Lua packages. I don't know what the best solution is either.

[belm0]

I confirmed that the frame pointer setting is the issue. From what I've read, mostly from Mike Pall, for architectures other than x86 (such as x86_64 in my case), gcc disables frame pointers implicitly when optimization is enabled. Mike states that frame pointers are not used by modern debuggers on these archs.

I'd like to learn more about why LuaD has a dependency on frame pointers for its exception handling, and whether there isn't some other mechanism available.

[belm0]

I found this article on walking stack without frame pointer:
http://www.yosefk.com/blog/getting-the-call-stack-without-a-frame-pointer.html

There is data called DWARF CFI that can be generated by the compiler to help with unwinding, which has no effect on runtime performance.

I'm not clear on what is using the frame pointer. Is it the Lua runtime or the D runtime?

[JakobOvrum]

It is the D runtime, when an exception is thrown and the stack is unrolled.

[belm0]

I found this thread regarding incorporating C++ build into the Debian Lua package enlightening:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560139

What they settled on is compiling a variant of the Lua library in C++, but with the C ABI. This allows unwinding yet the ability to use Lua modules implemented in C. The claim is that only the Lua library itself needs the unwinding support because it's the only thing able to emit Lua errors. Also the claim is that gcc typically emits an eh_frame section containing data for unwinding.

I wonder if the D runtime supports the common unwind data formats (eh_frame or debug_frame), or if it could be reasonably made to.

[JakobOvrum]

I don't know how DMD and the standard druntime deals with exceptions, or why it needs frame pointers; indeed there could be cause for improvement here.

I think GDC uses a fork of druntime out of necessity. I'm planning on playing around with GDC when I have time, to see if there are any configurations working without frame pointers. I might not be able to do it today, but maybe some time this weekend (feel free to help out, your help is much appreciated).

[JakobOvrum]

This is a duplicate of issue #35, let's try to keep the conversation centralized.