使用tdm-gcc
https://jmeubank.github.io/tdm-gcc/download/
然后再系统环境变量path里把tdragon的位置上移到cygwin上面,
让系统调用gcc时先识别tdragon的gcc,或者直接把cygwin的环境路径直接删除了,
或者直接从goland里的settings->Go->GoPath里添加tdragon的路径,如下图

Surou 发布的文章
使用tdm-gcc
https://jmeubank.github.io/tdm-gcc/download/
然后再系统环境变量path里把tdragon的位置上移到cygwin上面,
让系统调用gcc时先识别tdragon的gcc,或者直接把cygwin的环境路径直接删除了,
或者直接从goland里的settings->Go->GoPath里添加tdragon的路径,如下图

./scripts/eosio_build.sh -o Debug
sudo sysctl -w kernel.core_pattern=/corefiles/core.%p.%e
sudo mkdir /corefiles
sudo chmod -R 777 /corefiles
ulimit -c unlimited
当nodeos异常退出时,就会在/corefiles/生成dump文件
rm.get_account_limits( result.account_name, result.ram_quota, result.net_weight, result.cpu_weight );
set_resource_limits( res_itr->owner, res_itr->ram_bytes + ram_gift_bytes, net, cpu );
ram_bytes是实际买的RAM 大小,ram_quota 是加上了 赠送的ram_gift_bytes(等于1400)(github)
cleos -u https://api.eoslaomao.com get account bcskillsurou
返回
memory:
quota: 4.348 KiB used: 3.49 KiB
查看账户资源表
cleos -u https://api.eoslaomao.com get table eosio bcskillsurou userres
返回
{
"rows": [{
"owner": "bcskillsurou",
"net_weight": "0.0046 EOS",
"cpu_weight": "0.0147 EOS",
"ram_bytes": 3052
}
],
"more": false,
"next_key": ""
}
计算
quota 与 ram_bytes差值等于 1400,与ram_gift_bytes值一致。
最近链发送交易过大时容易发生一下错误
{
"message": "Internal Service Error",
"code": "500",
"error": {
"code": "3080004",
"name": "tx_cpu_usage_exceeded",
"what": "Transaction exceeded the current CPU usage limit imposed on the transaction",
"details": [{
"message": "transaction was executing for too long",
"file": "transaction_context.cpp",
"line_number": 488,
"method": "checktime"
}, {
"message": "pending console output: ",
"file": "apply_context.cpp",
"line_number": 113,
"method": "exec_one"
}]
}
}
根据错误信息,定位源代码位置 (github)
由于now > _deadline并且 deadline_exception_code == tx_cpu_usage_exceeded::code_value 走到此断言逻辑
倒推到函数调用位置(github)
checktime(); // Fail early if deadline has already been exceeded
提示信息为:如果已超过截止日期,则提早失败
继续反推代码
由于(github)交易组装时trx.max_cpu_usage_ms固定设置的0。所以,判断逻辑出自(github)
// Possibly lower objective_duration_limit to the maximum cpu usage a transaction is allowed to be billed
if( cfg.max_transaction_cpu_usage <= objective_duration_limit.count() ) {
objective_duration_limit = fc::microseconds(cfg.max_transaction_cpu_usage);
billing_timer_exception_code = tx_cpu_usage_exceeded::code_value;
_deadline = start + objective_duration_limit;
}
auto& rl = control.get_mutable_resource_limits_manager();
objective_duration_limit = fc::microseconds( rl.get_block_cpu_limit() );
_deadline = start + objective_duration_limit;
if(now > _deadline) {
// 报异常
}
get_mutable_resource_limits_manager(github)
resource_limits_manager& controller::get_mutable_resource_limits_manager()
{
return my->resource_limits;
}
get_block_cpu_limit(github)
uint64_t resource_limits_manager::get_block_cpu_limit() const {
const auto& state = _db.get<resource_limits_state_object>();
const auto& config = _db.get<resource_limits_config_object>();
return config.cpu_limit_parameters.max - state.pending_cpu_usage;
}
发现是由于合约中使用了std::vector<std::string> 持续存储大量数据,导致单次CPU运算执行耗时持续增长。
当合约中Table单条记录中,如果使用vector不要存储过多数据,以及数据结构过于复杂的struct。
如有对应需求,可以拆分子表,然后使用子表记录id索引对应。
tail -f命令可以查看文件更新的记录,但是在wsl中,可能无法正常工作。
经查找发现,Linux是通过inotify来获取文件变动的,但是不知道是bug还是什么原因,感知不到文件变动,造成此问题。
解决方案:
tail -f ---disable-inotify info.log