I am trying to perform raw transaction in quorum , but I am getting the error:
Error: Number can only safely store up to 53 bits.
Please help.
The Code is,
web3.eth.sendSignedTransaction(rawTx).then(function(transactionReciept,error){
if(error){
console.log("Error occured in send Function")
callback(error,null,null);
}else{
console.log("Transaction is successfull ",transactionReciept)
transaction = JSON.stringify(transactionReciept);
});
JavaScript tried convert a BigNumber to a regular number, but the builtin number is too small. I am guessing it happens in the console.log when you try to print out the transactionReceipt.
Before do anything else please be sure that provided gas is round number
In many blogs I've found it was a Truffle version problem. Truffle v5 would make problems of this type. They suggest to downgrade to truffle#4.1.15.
This has not been so for me. I have continue to use truffle v5. I've resolved by checking my gas limit when I sent a transaction.
gasLimit: web3.utils.toHex( gas_limit ),//The maximum gas provided for this transaction (gas limit)
My packages version:
Node: v8.11.4
Truffle: 5.0.12
Web3: 1.0.0-beta.52
Truffle-contract: 4.0.11
Truffle-interface-adapter#0.1.2
│ └── web3#1.0.0-beta.37
└── web3#1.0.0-beta.37
Ganache-cli: v6.4.3 (ganache-core: 2.5.5)
Ethereumjs-tx: 1.3.4
Related
Using openzeppelin's UUPS upgradeable proxy contracts results in the following slither error. Are they false positives or should I be concerned?
Enviornment:
"#openzeppelin/contracts-upgradeable": "^4.5.2",
$ slither .
'npx hardhat compile --force' running
hardhat solidity version 0.8.9
Error 1:
ERC1967UpgradeUpgradeable._functionDelegateCall(address,bytes) (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#198-204) uses delegatecall to a input-controlled function id
- (success,returndata) = target.delegatecall(data) (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#202)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#controlled-delegatecall
Error 2:
ERC1967UpgradeUpgradeable._upgradeToAndCallUUPS(address,bytes,bool).slot (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#98) is a local variable never initialized
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#uninitialized-local-variables
Error 3:
ERC1967UpgradeUpgradeable._upgradeToAndCallUUPS(address,bytes,bool) (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#87-105) ignores return value by IERC1822ProxiableUpgradeable(newImplementation).proxiableUUID() (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#98-102)
ERC721Upgradeable._checkOnERC721Received(address,address,uint256,bytes) (node_modules/#openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol#393-414) ignores return value by IERC721ReceiverUpgradeable(to).onERC721Received(_msgSender(),from,tokenId,_data) (node_modules/#openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol#400-410)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unused-return
No, slither often flags OpenZepplin contracts, because they often use low-level functions like delegatecall or use assembly to deal with the return data.
So it's fine just keep in mind that while slither is an amazing piece of software it can't detect everything correctly.
When I test to reconstruct the elf executable from process image, i got the .dynamic and GOT_OFFSET_TABLE,but The global offset table was filled in with the resolved values of the corresponding shared library functions.I must replace these addresses with the original PLT stub addresses. So,how can I get the PLT stub addresses from a process image.
for(c=0;dyn[c].d_tag !=DT_NULL ;c++){
switch (dyn[c].d_tag){
case DT_PLTGOT:
got = (Elf64_Addr)dyn[c].d_un.d_ptr;
printf("[+]Located plt.got vaddr:0x%x\n",got);
printf("[+]Relevant GOT entries begin at 0x%x\n", (Elf64_Addr)dyn[c].d_un.d_ptr + 24);
got_off = dyn[c].d_un.d_ptr - h.data_vaddr;
GOT_TABLE = (Elf64_Addr*)&pmem[h.data_offset +got_off];
GOT_TABLE += 3;
break;
...
}
Elf64_Addr PLT_VADDR = ?
gdb-peda$ x/10gx 0x601000 + 3*8
0x601018: 0x00007f3eaf557800 0x00007f3eaf522740 0x601018->GOT_OFFSET_TABLE[3]
0x601028: 0x00007f3eaf578160 0x0000000000000000
0x601038: 0x0000000000000000 0x0000000000000000
0x601048: 0x0000000000000000 0x0000000000000000
0x601058: 0x0000000000000000 0x0000000000000000
Looks like we're reading the same book, 'Learning Linux Binary Analysis' and stuck on the same exercise. I did not find an elegant way to retrieve the .plt address but you may be able to find it by using ElfN_Shdr.sh_name and by doing a strcmp(ElfN_Shdr.sh_name, '.plt') on it.
The author, elfmaster seems to be using that :
https://github.com/elfmaster/ftrace/blob/master/ftrace.c#L418
So I managed do get my way out to .plt address on a stripped binary compiled with PIE(Process Independent Execution). I observed that the .plt section was always on top of .text section.
By substracting the rel relocation table size, stored in DT_RELSZ, to the entry point, e_entry, you can get the address of .plt. I do not know yet if it coincidence and that this trick is actually garbage but it works.
I checked multiples elfparser and it seems that they are all using section name(sh_name) to identify .plt section. We're asked to recover an ELF file in memory and it appears that section headers are only relevant for linking and not loaded for execution but I'm not sure and you should double checked that.
I've been using marcel/s3 until we recently had to upgrade to aws-sdk (version 2).
One change that we noticed was that we now can't sign URLs with expirations longer than a week, as we get an exception: ArgumentError: expires_in value of #{X} exceeds one-week maximum.
I tried overriding the ONE_WEEK constant, which let me create the signed URL. The thing is that now curl the obtained URL I get 400 response including X-Amz-Expires must be less than a week (in seconds); that is, the given X-Amz-Expires must be less than 604800 seconds.
How can I sign an URL for longer than a week using aws-sdk v2 (as I could with marcel/s3)? Is switching to aws-sdk v1 an alternative to achieve this?
The difference I've noted between the URLs generated by each lib:
marcel-s3: uses AWSAccessKeyId, Expires and Signature as query parameters.
aws-sdk v2: uses X-Amz-Algorithm, X-Amz-Credential, X-Amz-Date, X-Amz-Expires, X-Amz-SignedHeaders and X-Amz-Signature as query parameters.
Using v1 of aws-sdk (along with v2 for the other stuff) worked for me. Sample code:
def url s3_key, public_path=false
s3 = AWS::S3.new # aws-sdk v1 s3 client
v1_obj = s3.buckets[BUCKET_NAME].objects[s3_key]
if public_path
v1_obj.public_url.to_s
else
v1_obj.url_for(:read, expires: (2.weeks.since - Time.now).to_i).to_s
end
last week I published my first Windows 8.1 app on the Windows Store. So far everything works fine but now two user reported that the app crashes immediately when being launched.
Additionally I discovered that there is a CrashDump listed in the Reports/Quality section of the Dashboard. I dowloaded the CrashDump and tried to find the source of the problem using WinDbg by following this instruction: http://blogs.msdn.com/b/ntdebugging/archive/2014/01/13/debugging-a-windows-8-1-store-app-crash-dump.aspx
I was able to follow the instruction almost up to the end but then the sos library is not found:
0:006> .sympath SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
...
0:006> .exr -1
ExceptionAddress: 769eb1d7 (combase+0x000fb1d7)
ExceptionCode: c000027b
ExceptionFlags: 00000001
NumberParameters: 2
Parameter[0]: 03f3f32c
Parameter[1]: 00000001
0:006> !error c000027b
Error code: (NTSTATUS) 0xc000027b (3221226107) - Anwendungsinterne Ausnahme.
0:006> .ecxr
eax=03f3f030 ebx=00000000 ecx=00000000 edx=00000000
esi=03f3f360 edi=03f3f030 eip=769eb01f esp=03f3f314
ebp=03f3f3bc iopl=0 nv up ei pl nz ac po nc cs=001b
ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212
combase+0xfb01f: 769eb01f 6a03 push 3
0:006> knL
*** Stack trace for last set context - .thread/.cxr resets it
...
0:006> dt 03f3f32c combase!_STOWED_EXCEPTION_INFORMATION_HEADER*
0x05f182e4
+0x000 Size : 0x28
+0x004 Signature : 0x53453032
0:006> .formats 0x53453032
Evaluate expression:
Hex: 53453032
Decimal: 1397043250
Octal: 12321230062
Binary: 01010011 01000101 00110000 00110010
Chars: SE02
Time: Wed Apr 09 13:34:10 2014
Float: low 8.46917e+011 high 0
Double: 6.90231e-315
0:006> dt -a1 03f3f32c combase!_STOWED_EXCEPTION_INFORMATION_V2*
[0] # 03f3f32
---------------------------------------------
0x05f182e4
+0x000 Header : _STOWED_EXCEPTION_INFORMATION_HEADER
+0x008 ResultCode : 80131500
+0x00c ExceptionForm : 0y01
+0x00c ThreadId : 0y000000000000000000010001100101 (0x465)
+0x010 ExceptionAddress : 0x76943bff Void
+0x014 StackTraceWordSize : 4
+0x018 StackTraceWords : 0xa
+0x01c StackTrace : 0x04c6c010 Void
+0x010 ErrorText : 0x76943bff "趍ﯰ???" +0x
+0x020 NestedExceptionType : 0x314f454c
+0x024 NestedException : 0x05f1be44 Void
0:006> !error 80131500
Error code: (HRESULT) 0x80131500 (2148734208) - <Unable to get error code text>
0:006> dpS 0x04c6c010 La 7697a9f1 combase!RoOriginateLanguageException+0x3b [d:\blue_gdr\com\combase\winrt\error\error.cpp # 1083]
63da3bc6 mscorlib_ni+0x9b3bc6
63e41976 mscorlib_ni+0xa51976
63e415c1 mscorlib_ni+0xa515c1
5b72f9df System_Runtime_WindowsRuntime_ni+0x1f9df
5b72f965 System_Runtime_WindowsRuntime_ni+0x1f965
6372de66 mscorlib_ni+0x33de66
5b72f934 System_Runtime_WindowsRuntime_ni+0x1f934
5b6bff16 Windows_UI_ni+0x9ff16
64492a36 clr!COMToCLRDispatchHelper+0x28
0:006> !sos.pe
The call to LoadLibrary(sos) failed, Win32 error 0n2
"The system cannot find the file specified."
Please check your debugger configuration and/or network access.
0:006> .loadby sos clr
The call to LoadLibrary(c:\symbols\clr.dll\52E0B78469b000\sos) failed, Win32 error 0n126
"The system cannot find the file specified."
Please check your debugger configuration and/or network access.
I does not have experience with this kind of debugging and without the instruction I would not have known any of the commands that I had to use in WinDbg.
Does anyone have an idea how to go on from here?
I have uploaded the CrashDump to my OneDrive. Would be great if anyone with more experience could have a look at it:
http://1drv.ms/1gZzrRK
Is it somehow possible to get additional information from the users who reported the crash to the support? Can they extract a crash dump / error report from their systems?
Is there any possibility to supply a changed version to these users to check if these changes influence the problem?
Thank you very much!
In order to get more insight into what your app is doing when it's running on users' devices, you could add logging of some kind. Local logging to file is an option, but a poor one, since you have to let your user dig into hidden files to retreive your application log. It might be acceptable though, depending on your scenario. In that case you might want to look at this logging sample for Windows Store Apps that uses EWT to log.
Alternatives would be using some kind of logging framework. I haven't got any experience in any of those so I couldn't tell you which one to use.
As for getting a changed version to your user: simply build an app-package locally, put it on OneDrive and send them a link to it. They can sideload the app themselves (although it requires running a Powershell script and logging in with a live-account). I've used this approach with several clients and it's workable.
I don't have a good knowledge of SSL principles, but just want the encryption to work for me.
I have a DB and a user with "REQUIRE X509" specified.
The necessary certificates have been created as described in MySQL docs, and work well - i can connect to the server from Windows command line.
The problem arises, when i try to do the same from my program using MySQL Client API (without SSL, the program also works fine).
The unit used is: http://www.audio-data.de/mysql.html.
These are my action paths:
1) if i just add mysql_ssl_set() call (with proper params) before mysql_real_connect(), the last one gives generic SSL Connection Error.
2) the MySQL docs in en/mysql-ssl-set.html say, that the function always returns 0. But when i checked that, it appeared that the result is the number 11150848. Then i wrote it like that:
showmessage(inttostr(mysql_ssl_set(mys, '.\certs\client-key.pem', '.\certs\client-cert.pem', '.\certs\ca-cert.pem', nil)));
...and repeated the line 8 times.
Each time it returned a slightly greater number - 11158528, 11158784, 11159040, ... and two zeroes for the last two calls.
After which mysql_real_connect() was finally successful! The program even managed to execute some queries, return proper results for them (i know the data), but then it crashed with an Access Violation: write of address ... at some place.
The crash point varied between runs and slight changes to code.
It looks much like a version incompatibility issue. I tried libraries from both MySQL 5.0 and 5.1 Windows installations (the server is 5.1 and runs under Linux remotely; however, 5.0 mysql-client programs do not have troubles when SSL-connecting to it), but with no success.
Is anybody familiar with the issue? Thanks a lot for the help & sorry for the mistakes in the question.
As I see the mysql_ssl_set declaration is incorrect. It is declared:
function mysql_ssl_set(_mysql: PMYSQL; key, cert, ca, capath: PAnsiChar): longint; stdcall;
But the mysql.h contains:
my_bool STDCALL mysql_ssl_set(MYSQL *mysql, const char *key,
const char *cert, const char *ca,
const char *capath, const char *cipher);
That explains the garbage in return value, AV's and so on.