On Fri, Jun 7, 2013 at 12:39 AM, nazriel wrote:
> On Thursday, 6 June 2013 at 21:50:58 UTC, Timothee Cour wrote:
>
>> Great!
>> two issues (on OSX at least):
>>
>> A)
>> it seems the top-most element of the call stack gets chopped off; eg in
>> your code, the main_module.main symbol will not appe
On Thursday, 6 June 2013 at 21:50:58 UTC, Timothee Cour wrote:
Great!
two issues (on OSX at least):
A)
it seems the top-most element of the call stack gets chopped
off; eg in
your code, the main_module.main symbol will not appear in the
stack trace.
Any idea why or how to fix that?
Is that so
just to be clear, this is what i get:
0 test_stacktrace_sigint 0x000102e2f69f
handleTermination + 35
1 libsystem_c.dylib 0x7fff919d794a _sigtramp + 26
2 ??? 0x0005 0x0 + 5
3 test_stacktrace_sigint
Great!
two issues (on OSX at least):
A)
it seems the top-most element of the call stack gets chopped off; eg in
your code, the main_module.main symbol will not appear in the stack trace.
Any idea why or how to fix that?
Is that some inlining issue ? I tried with dmd -g, or -gs or -gc.
This can be
On Wednesday, 5 June 2013 at 21:05:53 UTC, Timothee Cour wrote:
how do i get a stacktrace inside handleTermination?
If not currently possible, could we have a compile flag that
would enable
this kind of feature? (making code slower would be OK, its an
opt in
feature)
Ideally we'd also be able
how do i get a stacktrace inside handleTermination?
If not currently possible, could we have a compile flag that would enable
this kind of feature? (making code slower would be OK, its an opt in
feature)
Ideally we'd also be able to walk up or down the stack trace (kind of what
gdb would do, but I
