Re: Need help to find source file location by PC address
On Saturday, 12 December 2020 at 15:51:46 UTC, Calvin P wrote: I made a cross build with LDC -g -gdwarf-4 -O0 -D_DEBUG, the app crash with a report include PC address 0x005e34a9. [...] Find the solution: lldb-11 tests_curl (lldb) target create "tests_curl" Current executable set to 'tests_curl' (i686). (lldb) image lookup --address 0x005e34a9 Address: tests_curl[0x005e34a9] (tests_curl..text + 1975465) Summary: tests_curl`getinfo_offt + 1817 at getinfo.c (lldb) q
Need help to find source file location by PC address
I made a cross build with LDC -g -gdwarf-4 -O0 -D_DEBUG, the app crash with a report include PC address 0x005e34a9. Is there a way to find the source location for that PC address? ==4172==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x035dfcf0 at pc 0x005e34a9 bp 0x035dfa20 sp 0x035dfa1c WRITE of size 8 at 0x035dfcf0 thread T0 Address 0x035dfcf0 is a wild pointer. SUMMARY: AddressSanitizer: stack-buffer-overflow Shadow bytes around the buggy address: 0x306bbf40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x306bbf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x306bbf60: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 04 f3 0x306bbf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x306bbf80: 00 00 00 00 00 00 00 00 f1 f1 04 f3 00 00 00 00 =>0x306bbf90: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1[04]f3 0x306bbfa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x306bbfb0: f1 f1 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 0x306bbfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x306bbfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x306bbfe0: 00 f2 f2 f2 f2 f2 f2 f2 f2 f2 04 f2 00 00 f3 f3 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==4172==ABORTING
invalid path to external symbolizer!
I try find a memory issue with ldc -betterC -g -fsanitize=address -disable-fp-elim, get invalid path to external symbolizer! Is there a way to print the symbol and line ? = ==113433==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x606008a0 at pc 0x0070dcf2 bp 0x7ffedf7514c0 sp 0x7ffedf7514b8 WRITE of size 8 at 0x606008a0 thread T0 ==113433==WARNING: invalid path to external symbolizer! ==113433==WARNING: Failed to use and restart external symbolizer! #0 0x70dcf1 (/root/ncore+0x70dcf1) #1 0x5bea1f (/root/ncore+0x5bea1f) #2 0x5be68b (/root/ncore+0x5be68b) #3 0x5bd626 (/root/ncore+0x5bd626) #4 0x7f7644 (/root/ncore+0x7f7644) #5 0x7fc078 (/root/ncore+0x7fc078) #6 0x7fc1cd (/root/ncore+0x7fc1cd) #7 0x5c1060 (/root/ncore+0x5c1060) #8 0x730f4f (/root/ncore+0x730f4f) #9 0x738dea (/root/ncore+0x738dea) #10 0x6c2a12 (/root/ncore+0x6c2a12) #11 0x6dbdc1 (/root/ncore+0x6dbdc1) #12 0x724fa3 (/root/ncore+0x724fa3) #13 0x6d1707 (/root/ncore+0x6d1707) #14 0x724bb6 (/root/ncore+0x724bb6) #15 0x7f8fb6dbd09a (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) #16 0x4ea029 (/root/ncore+0x4ea029) 0x606008a0 is located 0 bytes to the right of 64-byte region [0x60600860,0x606008a0) allocated by thread T0 here: #0 0x562952 (/root/ncore+0x562952) #1 0x66c009 (/root/ncore+0x66c009) #2 0x70d991 (/root/ncore+0x70d991) #3 0x5bea1f (/root/ncore+0x5bea1f) #4 0x5be68b (/root/ncore+0x5be68b) #5 0x5bd626 (/root/ncore+0x5bd626) #6 0x7f7644 (/root/ncore+0x7f7644) #7 0x730f4f (/root/ncore+0x730f4f) #8 0x6dbdc1 (/root/ncore+0x6dbdc1) #9 0x724fa3 (/root/ncore+0x724fa3) #10 0x6d1707 (/root/ncore+0x6d1707) #11 0x724bb6 (/root/ncore+0x724bb6) #12 0x7f8fb6dbd09a (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) SUMMARY: AddressSanitizer: heap-buffer-overflow (/root/ncore+0x70dcf1) Shadow bytes around the buggy address: 0x0c0c7fff80c0: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x0c0c7fff80d0: 00 00 00 00 00 00 00 05 fa fa fa fa fd fd fd fd 0x0c0c7fff80e0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa 0x0c0c7fff80f0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa 0x0c0c7fff8100: fd fd fd fd fd fd fd fa fa fa fa fa 00 00 00 00 =>0x0c0c7fff8110: 00 00 00 00[fa]fa fa fa 00 00 00 00 00 00 00 07 0x0c0c7fff8120: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x0c0c7fff8130: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd 0x0c0c7fff8140: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd 0x0c0c7fff8150: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa 0x0c0c7fff8160: fd fd fd fd fd fd fd fd fa fa fa fa 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==113433==ABORTING
Re: need help to get member function const address
On Thursday, 19 March 2020 at 23:46:01 UTC, Boris Carvajal wrote: https://issues.dlang.org/show_bug.cgi?id=20687 https://github.com/dlang/dmd/pull/10946 Thanks very much for such a quick fix.
Re: need help to get member function const address
On Thursday, 19 March 2020 at 13:23:41 UTC, Adam D. Ruppe wrote:
Check the error message there... you already have a function
pointer, no need to use the .funcptr metod.
It is a bit weird though because it actually EXCLUDES the
hidden argument for `this`. I prefer doing wrapper functions
usually.
Thanks for the tips, I can get it into enum but not be able to
use it as const at compile time. I come up with this workaround:
static void* getCallee() pure @nogc nothrow {
enum callee_ptr = &(__traits(getMember, App, name));
return callee_ptr;
}
__gshared const AppHelper APP_HELPER = {, ..};
Re: need help to get member function const address
On Monday, 16 March 2020 at 18:43:47 UTC, Steven Schveighoffer
wrote:
enum A0 =
Note that you can't call it at all, but you can get the
function pointer, and put it into a delegate later by assigning
.funcptr.
void main()
{
A a;
void delegate() dg;
dg.ptr =
dg.funcptr = A0;
dg(); // calls a.d()
}
-Steve
Thanks for the tips, Steve.
I need to put them into a big const struct to use on runtime, so
they can not be modify on runtime by mistake.
I can not put the address into enum, because Error: need this
to access d
add cast(void*) still get same error:
enum callee_ptr = cast(void*) &(__traits(getMember, A, "d")); //
Error: need this to access d
but I come up with a workaround:
static void* getCallee() pure @nogc nothrow {
enum callee_ptr = &(__traits(getMember, App, name));
return callee_ptr;
}
__gshared const AppHelper APP_HELPER = {, ..};
Re: need help to get member function const address
On Thursday, 19 March 2020 at 06:34:40 UTC, Alex wrote: A non-static member method can use the context of the struct where it is defined in. E.g. it could alter a member variable. This context has to be constructed at run time (and there could be many instances of the context) and does not exist in compile time. Therefore the difference to the static method. I am not try to get the context, I just need the function address which is const and should able to get at compile time. On Thursday, 19 March 2020 at 09:13:42 UTC, Boris Carvajal wrote: On Thursday, 19 March 2020 at 04:30:32 UTC, Calvin P wrote: You can assemble a delegate with an struct pointer or class reference and a function member pointer. Sorry for duplicate thread. The last time I submit my question on web, it keep get blocked. I thought it was not submitted successfully, so I submit from draft again.
need help to get member function const address
I use this code to get member function address on runtime:
=
struct A {
this(){};
}
auto ctor = (&__traits(getMember, A.init,"__ctor")).funcptr;
=
my question is, how to get it in compile time like static
function address:
=
struct A {
void d(){};
static void fn(){};
}
enum FN = // static method address is ok
enum A0 = &(A.d).funcptr; // Error: need this for d of type void()
enum A1 = (&__traits(getMember, A,"d")).funcptr; // Error: no
property funcptr for type void function()
enum A2 = (&__traits(getMember, A.init,"d")).funcptr; // Error:
(().d).funcptr cannot be evaluated at compile time
=
need help to get member function const address
I use this code to get member function address on runtime:
=
struct A {
this(){};
}
auto ctor = (&__traits(getMember, A.init,"__ctor")).funcptr;
=
my question is, how to get it in compile time like static
function address:
=
struct A {
void d(){};
static void fn(){};
}
enum FN = // static method address is ok
enum A0 = &(A.d).funcptr; // Error: need this for d of type void()
enum A1 = (&__traits(getMember, A,"d")).funcptr; // Error: no
property funcptr for type void function()
enum A2 = (&__traits(getMember, A.init,"d")).funcptr; // Error:
(().d).funcptr cannot be evaluated at compile time
=
Re: @property with opCall
On Monday, 9 March 2020 at 19:10:54 UTC, Timon Gehr wrote: https://wiki.dlang.org/DIP24 Hi , Timon Gehr Thanks for the reply, very good DIPS. I think this is very basic work, why the core team not take care it for such a long time.
Re: " include imported modules in the compilation " should exclude di file
On Monday, 9 March 2020 at 13:55:08 UTC, Calvin P wrote: The current compiler "-i=module_name" option will include imported modules as source code. When the module define from di file extension, I think compiler should avoid treat it as source file. What do you think? The use case: If I want to define a collection function only use for ctfe, I can put them into di file to avoid binary bloat. It also can be used create helper module for BetterC library, so you can use "new Struct" in the di and import it from betterC module. without use "-I=-lib_helper" to exclude every helper module in the library.
" include imported modules in the compilation " should exclude di file
The current compiler "-i=module_name" option will include imported modules as source code. When the module define from di file extension, I think compiler should avoid treat it as source file. What do you think?
Re: @property with opCall
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
Here's a wiki page referencing one of the 2013 discussions
https://wiki.dlang.org/Property_Discussion_Wrap-up
though i'll note the thing is older than that.
What especially drove me nuts is people would so often say
"property *syntax*" instead of "property semantics" - everyone
would go on and on and on about banning optional parenthesis
which should be a totally unrelated discussion when we should
have been talking about the semantic question and focusing on
the case you discovered - the case that actually matters.
Thanks for reply.
after read the wiki, I am try answer some question.
Some people find it difficult to decide if something is a
property or a function
How can we get the getter / setter functions? Do we need to get
those?
This can be fixed with a new __traits. and should allow get
getter/setter functions.
Some people think the additional @property attribute clutters
the source code
I think it made code more readable.
Can we get a reference to the property? What does _
mean?
this should be decide base the Getter function attribute, ref
function should allow get reference. ref scope function allow
get scope ref.
> What is the type of the property? Return type, setter function
type or getter function type? How to get the other types?
I think setter should force return void, typeof(@property)
should return getter return type, if no getter should return void.
What does x.property_++ do?
this should only allow for ref getter with a setter.
Is returning ref values from the getter OK?
returning ref values from getter should be allowed.
I find one nice use case will be create a scope ref @property
base on pointer filed.
struct A {
B* _ptr;
@property ref auto b() return scope
{
return *_ptr;
}
}
Is taking ref values in the setter OK?
I think no harm to allow this.
UCFS and @property
If can not avoid conflict with UCFS, we can force @property only
work for class|struct instance method function.
How many parameters are allowed for property functions?
limit to 1 parameter. use backtrace for caller position.
Are templated properties allowed?
I think better not allow templated properties to keep it simple.
Ambiguous / complicated if a function returns a delegate or
similar (solvable with special case rules)
Complicates semantics for human reader of the code (see
comments about readability in "How those are (not!) related")
I can not answer this. but I think a simple rule can be apply to
@property:
When there is conflict, treat it like field, not function.
base on this rule, I think getter function should be @nogc, no
memory alloc.
Re: @property with opCall
On Monday, 9 March 2020 at 09:44:40 UTC, Simen Kjærås wrote: As written on https://dlang.org/spec/function.html#property-functions: WARNING: The definition and usefulness of property functions is being reviewed, and the implementation is currently incomplete. Using property functions is not recommended until the definition is more certain and implementation more mature. So no, I don't think it's necessary to file a bug - we're aware they're somewhat wonky, and until a resolution has been agreed on, I don't think filing bugs on what's undecided behavior is worth it. -- Simen Thanks for your reply. @property exists so many years, Druntime & Phobos use it 2280 times. I can't believe it is not recommended. Is there any discuss link or documents about the review process?
@property with opCall
Is this a bugs ?
==
struct A {
ref auto opCall(string tmp) scope return {
return this;
}
}
struct B {
A _a;
@property ref auto a() scope return {
return _a;
}
}
extern(C) int main(){
A a;
a("a")("b");
B b;
b.a("a")("b"); // Error: function test_opCall.B.a() is
not callable using argument types (string)
return 0;
}
==
I has to use b.a()("a")("b") to avoid the compiler error. I
think it should work to avoid the unnecessary ()
Should I submit a bugs ?
