What is the meaning of Wrapped EGLD Token ?
Maiar Exchange gives an popup with this message Reclaim your EGLD and the value is equivalent with the Wrapped EGLD Token value and I don't know what that is.
There are 2 types of tokens on the Elrond blockchain:
EGLD (the "coin")
ESDT, similar to ERC20 (like MEX, WUSDC, wrapped EGLD, RIDE, AERO, SUPER, etc.)
See here details about Elrond Standard Digital Token
Because EGLD is not an ESDT token, if you want to:
swap EGLD -> MEX, you will actually make EGLD -> wrapped EGLD -> MEX
swap MEX -> EGLD, you will actually make MEX -> wrapped EGLD -> EGLD
In Maiar Exchange you can see this information under the Swap button:
and under Balances, you can see Tokens > Wrapped EGLD with an Unwrap button. That amount was gained because the prices were fluctuating. If you unwrap it, you'll get EGLD.
For more details, check this:
https://github.com/ElrondNetwork/sc-bridge-elrond
Wrapped Tokens
... we're going to use ESDT to implement wrapped tokens, but how is the wrapping actually done? For that, we have the EgldEsdtSwap, a very simple SC, whose only purpose is to exchange 1:1 native eGLD to WrappedEgld ESDT tokens. You can also do the reverse operation at any time, which is known as unwrapping.
and this:
https://github.com/ElrondNetwork/sc-bridge-elrond/tree/main/egld-esdt-swap
Related
(1) In XCB, we must manually allocate XID before some requests. For example,
xcb_window_t win = xcb_generate_id(conn);
xcb_create_window(conn, XCB_COPY_FROM_PARENT, win, ...);
Then, what should we do to free (or unallocate) the XID? Is it enough to invoke xcb_destroy_window?
(2) How about in a case xcb_create_window fails? For example,
xcb_generic_cookie_t cookie = xcb_create_window_checked(conn, XCB_COPY_FROM_PARENT, win, ...);
if(xcb_request_check(conn, cookie)) ... // xcb_create_window failed.
In the example above, xcb_create_window failed. So, the XID win is allocated but not used. What should we do for win in this case?
Is it enough to invoke xcb_destroy_window?
Yup. Sadly, I don't have any authoritative docs to link to, so I can just say "trust me".
That's the simple answer for question 1. Answer 2... uhm, I guess it does not have a simple answer. So I guess you need "the full truth".
When an X11 client connects to the X11 server, it is assigned a range of XIDs to use. These are the fields resource-id-base and resource-id-mask in the server response here: https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html#server_response
Conceptually, these two fields describe something like "all XIDs from 0x100 to 0x200 are for you".
xcb_generate_id() now simply returns the next entry from this range and marks it as used. So, after the first call and staying with the example above, "all XIDs from 0x101 to 0x200" are still available.
This is quite a simple data structure and there is no way to return XIDs as "no longer used".
So, what happens after all XIDs were used? For this, the XC-MISC extension exists: https://www.x.org/releases/X11R7.7/doc/xcmiscproto/xc-misc.html
When it is out of XIDs, libxcb will send a XCMiscGetXIDRange request to get a "new" batch of XIDs and then starts handing out them.
I write "new" in quotes since it is actually a sub-range of the original XID range: The X11 server knows which range it originally assigned this client. It knows which XIDs are in use. Thus, it can pick a free range and return it to the client.
Thanks to this mechanism, libxcb does not have to track used XIDs in any way. Stuff just works automatically.
I have an account that stores some data and is owned by my Solana program. I'd like to implement a Close instruction that "closes" the account and transfers the remaining native-SOL into a wrapped-SOL token account, and then call spl-token's sync_native instruction.
If I try to use the SystemProgram's Transfer instruction, I hit the error in the processor that says Transfer: from must not carry data.
So instead, I just do this:
let dest_starting_lamports = dest_account_info.lamports();
**dest_account_info.lamports.borrow_mut() = dest_starting_lamports
.checked_add(source_account_info.lamports())
.unwrap();
**source_account_info.lamports.borrow_mut() = 0;
However, if I later call sync_native via CPI anywhere in the same instruction, I get an error:
sum of account balances before and after instruction do not match
Is it possible to both modify the lamport values (transfer) of accounts AND call a CPI instruction? Or alternatively, is there a way to close the account with the SystemProgram?
Okay So here I want to figure it out that CPI in a single instructions causes conflict with each other
as in my case I was using token program and system program in a single instruction
and I figured it out that token program CPI should be done above the system program CPI.
This may be a bug in the runtime, because otherwise it looks like you're doing everything correctly. The only time this should fail is if dest_account_info and source_account_info are the same, but you mentioned that the sync_native is what caused the problem.
As a workaround, you can have sync_native done as a separate instruction in the transaction rather than as a CPI.
I have some crash dump that was caused by a stack overrun. The driver was compiled with /GS, so when the security cookie gets corrupted, it triggers a bugcheck. No surprise there. However, the arguments are:
DRIVER_OVERRAN_STACK_BUFFER (f7)
A driver has overrun a stack-based buffer. This overrun could potentially
allow a malicious user to gain control of this machine.
DESCRIPTION
A driver overran a stack-based buffer (or local variable) in a way that would
have overwritten the function's return address and jumped back to an arbitrary
address when the function returned. This is the classic "buffer overrun"
hacking attack and the system has been brought down to prevent a malicious user
from gaining complete control of it.
Do a kb to get a stack backtrace -- the last routine on the stack before the
buffer overrun handlers and bugcheck call is the one that overran its local
variable(s).
Arguments:
Arg1: ffffd000a91557dd, Actual security check cookie from the stack
Arg2: 00008505f890dcd0, Expected security check cookie
Arg3: ffffd466d2205dcd, Complement of the expected security check cookie
Arg4: 0000000000000000, zero
Note that Arg2 != ~Arg3. In all similar crash dumps I've seen, they always matched.
The security check cookie is calculated by XORing the ___security_cookie with the return address. Then when checking it, it calculates the same thing. I always assumed the complement was there for redundancy, since they always return 4 arguments.
What could it mean that the expected cookie and its complement don't match?
I use compute shaders to compute a triangle list and to store it in a RWStructuredBuffer. For testing I read this buffer and pass it to the IA via context.InputAssembler.SetVertexBuffers (…). This approach works, but is valid only for testing the data for correctness.
Now I want to bind the (already existing) buffer to the IA stage using a resource view (aka without passing a pointer to the vertex buffer).
I am reading some good books (Frank D. Luna, Jason Zink), but they never mention this case.
===============
EDIT:
The syntax I am using here in imposed by the SharpDX wrapper.
I can bind the buffer to the vertex shader via context.VertexShader.SetShaderResource(...), bindig a ResoureceView. In the VS I use SV_VertexID to access the buffer. So I HAVE a working solution for moment, but there might be cases in the future where I must bind the buffer to the input assembler.
Simply put, you can't bind a structured buffer to the IA stage, at least directly, runtime will not allow this.
If you put ResourceOptionFlags.BufferStructured as OptionFlags, you are not allowed to use : VertexBuffer/IndexBuffer/StreamOutput/ConstantBuffer/RenderTarget/Depth as bind flags, Resource creation will fail.
One option, which costs you a GPU copy, is to create a second buffer with VertexBuffer BindFlags, and Default usage (same size as your structured buffer).
Once you are done processing your structuredbuffer, call:
DeviceContext.CopyResource
And you'll have a standard vertex buffer ready to use.
I have some questions regarding COM memory management:
I have a COM method:
STDMETHODIMP CWhitelistPolicy::GetWebsitesStrings(SAFEARRAY** result)
result = SAFEARRAY(BSTR). If I receive another SAFEARRAY(BSTR) from another interface method(in order to set *result) do I have to make copies of the strings received in order to pass them to *result and outside client? Or considering I will not use the strings for myself I can just pass them to the client (and passing out the ownership)?
2.
STDMETHODIMP CWhitelistPolicy::SetWebsitesStrings(SAFEARRAY* input)
Here I receive a BSTR array as input. Again my method is responsible for the memory allocated in input?
3.
STDMETHOD(SetUsers)(SAFEARRAY* input);
Here I call a method on another interface (SetUsers) and I allocate memory for the input SAFEARRAY. After I call SetUsers I can dispose of the SAFEARRAY? Memory is always copied when marshaling takes place isn't it? (in my case SetUsers method is called on an interface that is hosted as a COM DLL inside my process)
The way I think about it to answer questions like this is to think about a COM call that crosses machines. Then it's obvious for an [out] param; I the caller own and have to free the memory because the remote marshaling layer can't do it. For [in] parameters, it's obvious the marshaling layer must copy my data and again the remote marshaling layer can't free what I passed in.
A core tenet in COM is location neutrality, the rules when calling in the same apartment are the rules when using DCOM across machines.
You're responsible to free - you don't pass ownership when you call the next fnc because it could be remote and getting a copy, not your original data.
No - as the callee, you don't have to free it. If it's intra-apartment, it's the memory the caller provided and the caller has to free it. If it's a remote call, the server stub allocates it and will free it when the method returns.
Yes, you free it - no, it's not always copied (it might be), which is why the answer to 2 is no. If it's copied, there's a stub that allocated and the stub will free it.
Note my answers to your questions didn't cover the case of [in,out] parameters - see the so question Who owns returned BSTR? for some more details on this case.
Com allocation rules are complicated but rational. Get the book "essential com" by Don Box if you want to understand/see examples of all the cases. Still you're going to make mistakes so you should have a strategy for detecting them. I use gflags (part of Windbg) and its heap checking flags to catch when a double free occurs (a debug message is displayed and execution halted at the call with an INT 3). Vstudio's debugger used to turn them on for you when it launched the executable (it likely still does) but you can force them on with gflags under the image options tab.
You should also know how to use UMDH (also part of windbg) to detect leaks. DebugDiag is the newer tool for this and seems easier to use, but sadly, you can only have the 32 bit or 64 bit version installed, but not both.
The problem then are BSTRs, which are cached, make detecting double frees and leaks tricky because interacting with the heap is delayed. You can shut off the ole string cache by setting the environment variable OANOCACHE to 1 or calling the function SetOaNoCache. The function's not defined in a header file so see this SO question Where is SetOaNoCache defined?. Note the accepted answer shows the hard way to call it through GetProcAddress(). The answer below the accepted one shows all you need is an extern "C" as it's in the oleaut32 export lib. Finally, see this Larry Osterman blog post for a more detailed description of the difficulties caused by the cache when hunting leaks.