I'm playing around with the latest Litecoin code (0.21.2.1) and have modified the Genesis transaction so that I can spend it, however I get an error message when I spend the transaction and restart the core software.
2023-02-05T18:23:20Z init message: Rewinding blocks...
2023-02-05T18:23:20Z FlushStateToDisk: write coins cache to disk (0 coins, 0kB) started
2023-02-05T18:23:20Z FlushStateToDisk: write coins cache to disk (0 coins, 0kB) completed (0.00s)
2023-02-05T18:23:20Z init message: Verifying blocks...
2023-02-05T18:23:20Z Verifying last 2 blocks at level 3
2023-02-05T18:23:20Z [0%]...ERROR: VerifyDB(): *** irrecoverable inconsistency in block data at 2, hash=3b3699b72f5f7591c5790d6936ea4328ac2b657bb1e91b19ab4b0c32aa43d884
2023-02-05T18:23:20Z : Corrupted block database detected.
Please restart with -reindex or -reindex-chainstate to recover.
: Corrupted block database detected.
Please restart with -reindex or -reindex-chainstate to recover.
2023-02-05T18:23:20Z Aborted block database rebuild. Exiting.
2023-02-05T18:23:20Z Shutdown: In progress...
Step 1 - Disable skipping the genesis block (validation.cpp)
// Special case for the genesis block, skipping connection of its transactions
// (its coinbase is unspendable)
if (block.GetHash() == chainparams.GetConsensus().hashGenesisBlock) {
if (!fJustCheck)
view.SetBestBlock(pindex->GetBlockHash());
// return true; <- comment this line out
}
Step 2 - Skip assertion of previous block for genesis block (validation.cpp)
if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock) {
assert(pindex->pprev);
CBlockIndex *pindexBIP34height = pindex->pprev->GetAncestor(chainparams.GetConsensus().BIP34Height);
//Only continue to enforce if we're below BIP34 activation height or the block hash at that height doesn't correspond.
fEnforceBIP30 = fEnforceBIP30 && (!pindexBIP34height || !(pindexBIP34height->GetBlockHash() == chainparams.GetConsensus().BIP34Hash));
}
Step 3 - Skip writing undo data for genesis block (validation.cpp)
if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
{
if (!WriteUndoDataForBlock(blockundo, state, pindex, chainparams))
return false;
}
Have I forgotten or overlooked something? There must be some reason why the chain becomes invalid after using the Genesis TX.
I would like to make the genesis block fully available. I had already done that a long time ago, but I have the impression that something has changed a bit.
Would be nice if someone could give me a hint what I have to change so that the genesis block can be used like any other.
Related
When attempting to make a call to a program compiled with #solana/solidity, I'm getting the following error:
Transaction simulation failed: Error processing Instruction 0: Program failed to complete
Program jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N invoke [1]
Program log: pxKTQePwHC9MiR52J5AYaRtSLAtkVfcoGS3GaLD24YX
Program log: sender account missing from transaction
Program jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N consumed 200000 of 200000 compute units
Program failed to complete: BPF program Panicked in solana.c at 285:0
Program jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N failed: Program failed to complete
jdN1wZjg5P4xi718DG2HraGuxVx1mM7ebjXpxbJ5R3N is the program's public key and pxKTQePwHC9MiR52J5AYaRtSLAtkVfcoGS3GaLD24YX is the sender's public key.
I'm using a fork of the #solana/solidity library that exposes the Transaction object so that it can be signed and sent by Phantom Wallet on the front end. The code that results in the error is as follows:
// Generate the transaction
const transaction = contract.transactions.send(...args);
// Add recent blockhash and fee payer
const recentBlockhash = (await connection.getRecentBlockhash()).blockhash;
transaction.recentBlockhash = recentBlockhash;
transaction.feePayer = provider.publicKey;
// Sign and send the transaction (throws an error)
const res = await provider.signAndSendTransaction(transaction);
I would attempt to debug this further myself, but I'm not sure where to start. Looking up the error message hasn't yielded any results and the error message isn't very descriptive. I'm not sure if this error is occurring within the program execution itself or if it's an issue with the composition of the transaction object. If it is an issue within the program execution, is there a way for me to add logs to my solidity code? If it's an issue with the transaction object, what could be missing? How can I better debug issues like this?
Thank you for any help.
Edit: I'm getting a different error now, although I haven't changed any of the provided code. The error message is now the following:
Phantom - RPC Error: Transaction creation failed. {code: -32003, message: 'Transaction creation failed.'}
Unfortunately this error message is even less helpful than the last one. I'm not sure if Phantom Wallet was updated or if a project dependency was updated at some point, but given the vague nature of both of these error messages and the fact that none of my code has changed, I believe they're being caused by the same issue. Again, any help or debugging tips are appreciated.
I was able to solve this issue, and although I've run into another issue it's not related to the contents of this question so I'll post it separately.
Regarding my edit, I found that the difference between the error messages came down to how I was sending the transaction. At first, I tried sending it with Phantom's .signAndSendTransaction() method, which yielded the second error message (listed under my edit). Then I tried signing & sending the transaction manually, like so:
const signed = await provider.request({
method: 'signTransaction',
params: {
message: bs58.encode(transaction.serializeMessage()),
},
});
const signature = bs58.decode(signed.signature);
transaction.addSignature(provider.publicKey, signature);
await connection.sendRawTransaction(transaction.serialize())
Which yielded the more verbose error included in my original post. That error message did turn out to be helpful once I realized what to look for -- the sending account's public key was missing from the keys field on the TransactionInstruction on the Transaction. I added it in my fork of the #solana/solidity library and the error went away.
In short, the way I was able to debug this was by
Using provider.request({ method: 'signTransaction' }) and connection.sendRawTransaction(transaction) rather than Phantom's provider.signAndSendTransaction() method for a more verbose error message
Logging the transaction object and inspecting the instructions closely
I hope this helps someone else in the future.
I have a simple Kafka streams scenario where I am doing a groupyByKey then reduce and then an action. There could be duplicate events in the source topic hence the groupyByKey and reduce
The action could error and in that case, I need the streams app to reprocess that event. In the example below I'm always throwing an error to demonstrate the point.
It is very important that the action only ever happens once and at least once.
The problem I'm finding is that when the streams app reprocesses the event, the reduce function is being called and as it returns null the action doesn't get recalled.
As only one event is produced to the source topic TOPIC_NAME I would expect the reduce to not have any values and skip down to the mapValues.
val topologyBuilder = StreamsBuilder()
topologyBuilder.stream(
TOPIC_NAME,
Consumed.with(Serdes.String(), EventSerde())
)
.groupByKey(Grouped.with(Serdes.String(), EventSerde()))
.reduce { current, _ ->
println("reduce hit")
null
}
.mapValues { _, v ->
println(Id: "${v.correlationId}")
throw Exception("simulate error")
}
To cause the issue I run the streams app twice. This is the output:
First run
Id: 90e6aefb-8763-4861-8d82-1304a6b5654e
11:10:52.320 [test-app-dcea4eb1-a58f-4a30-905f-46dad446b31e-StreamThread-1] ERROR org.apache.kafka.streams.KafkaStreams - stream-client [test-app-dcea4eb1-a58f-4a30-905f-46dad446b31e] All stream threads have died. The instance will be in error state and should be closed.
Second run
reduce hit
As you can see the .mapValues doesn't get called on the second run even though it errored on the first run causing the streams app to reprocess the same event again.
Is it possible to be able to have a streams app re-process an event with a reduced step where it's treating the event like it's never seen before? - Or is there a better approach to how I'm doing this?
I was missing a property setting for the streams app.
props["processing.guarantee"]= "exactly_once"
By setting this, it will guarantee that any state created from the point of picking up the event will rollback in case of a exception being thrown and the streams app crashing.
The problem was that the streams app would pick up the event again to re-process but the reducer step had state which has persisted. By enabling the exactly_once setting it ensures that the reducer state is also rolled back.
It now successfully re-processes the event as if it had never seen it before
This might be a silly mistake from my side that I have overlooked but I'm fairly new to UVM and I tried tinkering with my code for a while before this. I'm trying to send in a stream of 8 bit data within a packet using Data valid stall protocol from my UVM driver to the DUT. I'm facing an issue with my input monitor not being able to pick up these transactions that are driven.
I have a while loop with a condition that the valid bit must be high and the stall bit should be low. As long as this condition holds good, the monitor needs to pick up the data byte and push into the queue. I know for a fact that the data is being picked up and pushed to a queue as I used $display statements along the way. The problem is arising once all the data bytes are received and the valid bit goes low. Ideally, this should cause the exit from the while loop but isn't doing so. Any help here would be appreciated. I have attached a snippet of the code below. Thanks in advance.
virtual task main_phase (uvm_phase phase);
$display("Run phase of input monitor");
collect_transfer();
endtask: main_phase
virtual task collect_transfer();
fork
forever begin
wait_for_valid_transaction_cycle();
create_and_populate_pkt();
broadcast_pkt();
#(iP0_vif.cb_iP0_MON);
end
join_none
endtask: collect_transfer
virtual task wait_for_valid_transaction_cycle();
wait(iP0_vif.cb_iP0_MON.ip_valid && ~iP0_vif.cb_iP0_MON.ip_stall);
endtask: wait_for_valid_transaction_cycle
virtual task create_and_populate_pkt();
pkt = Router_seq_item :: type_id :: create("pkt");
pkt.valid = iP0_vif.cb_iP0_MON.ip_valid;
pkt.sop = iP0_vif.cb_iP0_MON.ip_sop;
$display("before data collection");
while(iP0_vif.cb_iP0_MON.ip_valid === `HIGH && iP0_vif.cb_iP0_MON.ip_stall === `LOW) begin
$display("After checking for stall");
pkt.data = iP0_vif.cb_iP0_MON.ip_data;
$display(pkt.data);
pkt.data_q.push_front(pkt.data);
pkt.eop = iP0_vif.cb_iP0_MON.ip_eop;
$display("print check in input monitor # time = %0t", $time);
#(iP0_vif.cb_iP0_MON);
end
$display("before printing input packet from monitor");
Check_for_port_route_and_populate_packet_field(pkt);
print_packet(pkt);
endtask: create_and_populate_pkt
The $display statement "before printing input packet from monitor" is not being displayed.
HIGH is defined as a binary 1 and LOW is defined as a binary 0.
The output of the code in terms of display statements is as below.
before data collection
before checking for stall
After checking for stall
2
print check in input monitor # time = 105
before checking for stall
After checking for stall
1
print check in input monitor # time = 115
before checking for stall
After checking for stall
3
print check in input monitor # time = 125
It's possible that the main phase objection is being dropped elsewhere in your environment. UVM will automatically kill any threads that were spawned during a phase when it ends.
To fix this, do not object to the main phase in your monitor. Objecting to that phase is the responsibility of the threads creating the stimulus. Instead, you should be launching this monitor during the run_phase, which will ensure that your loop is not killed until the end of simulation.
Also, during the shutdown phase, you will want your monitor to object whenever it is currently seeing a packet. This will ensure that simulation doesn't end as soon as stimulus has been sent in, giving your other monitors time to collect responses from the DUT.
yaml-cpp team and everyone,
Our product receives an unfixed size of json response from a cloud service provider. We currently used a buffer with 16KB initial size to receive it, then pass it to yaml parser(we are using yaml-0.2.7). We expect yaml parser to throw an exception if the json document is incomplete during parsing and we will double the size of the buffer.
Today, we hit an assertion which shows "Assertion failed: (!m_tokens.empty()), function peek, file .../yaml-cpp-0.2.7/src/scanner.cpp, line 41." when doing parser.GetNextDocument(doc). The json document was incomplete due to small receiving buffer.
After examining the buffer and doing some experiment, I found out if some characters are missing following a certain pattern, the assertion in scanner will be hit during GetNextDocument. Such as for '{"access": "abc"}', if the last '}' is missing, then the assertion will be hit. Same thing happens if it is '{"access":' or '{"access"'. It will not hit the assertion if it is '"{"access":"abc' (note abc does not have the trailing double quote).
Will it help if I upgrade to the latest 0.5.3 version? I looked at the source code and saw the same assertion in Scanner::peek function is still there.
Here is the source code of the function where assertion is hit:
Token& Scanner::peek() {
{
EnsureTokensInQueue();
/** THIS ONE GOT HIT **/
assert(!m_tokens.empty()); // should we be asserting here? I mean, we really just be checking
// if it's empty before peeking.
#if 0
static Token *pLast = 0;
if(pLast != &m_tokens.front())
std::cerr << "peek: " << m_tokens.front() << "\n";
pLast = &m_tokens.front();
#endif
return m_tokens.front();
}
Much appreciate for the help! :)
This is fixed in 0.5.3, although I'm not sure when precisely it was fixed. I added tests for your examples and they pass (by throwing exceptions) as expected.
I've copied Vu's Script, (and of course renamed it) which have access to another DB, and when I run it I have in the output the old transaction name of the old script.
here is the old transaction name which are to seen in the output : MDM_GetAssociations
Here is the renamed transaction:MDM_GET_ASSOCIATIONS_Otmann
After renaming the transaction, I run the script, I got 2 errors:
1)
Error 14 undeclared identifier `MDM_GET_ASSOCIATIONS_Otmann' Action.c C:\GCDM_Test\Scripts\MDM\MDM_Get_POSTGRE_Otmann MDM_Get_POSTGRE_Otmann
2)
Error 15 type error in argument 1 to web_custom_request'; foundint' expected `pointer to const char' Action.c C:\GCDM_Test\Scripts\MDM\MDM_Get_POSTGRE_Otmann MDM_Get_POSTGRE_Otmann
and this is my script :
//########## start the test scenario ############
web_set_max_html_param_len("8000");
web_set_sockets_option("SSL_VERSION", "TLS");
web_add_auto_header("Content-Type","application/xml");
web_add_auto_header("Accept","application/json");
web_add_auto_header("Authorization",lr_eval_string("{AUTHORIZATION}"));
//GetAssociations, NOTE: our dummy customers have often NO associations!
web_reg_save_param("RESPONSE", "LB=", "RB=", "Search=Body", LAST);
lr_start_transaction((char*)MDM_GENERIC_TRANSACTION);
lr_start_transaction((char*)MDM_GET_ASSOCIATIONS);
web_custom_request(MDM_GET_ASSOCIATIONS,
"URL={TEST_ENV_HOSTNAME}/api/v3/clients/{BUSINESS_CONTEXT}/customers/{GCID}/associations",
"Method=GET",
"Resource=1", // => We are retrieving a ressource,
// which implies that it is not critical for the success of the script.
// Any failures (HTTP 404 - Not found etc.) in downloading the resource
// will be considered as warnings rather than errors.
"EncType=application/xml",
"Referer=Loadrunner",
LAST);
lr_end_transaction((char*)MDM_GET_ASSOCIATIONS, LR_AUTO);
lr_end_transaction((char*)MDM_GENERIC_TRANSACTION, LR_AUTO);
return 0;
}
and this is the output where the old transaction name apeared (MDM_GetAssociations), but I don't know where is she coded or from where she came, and as I said before when I try to change it in all position which has to do with Transactions,I got the errors mentioned above.
Here ist the output of the script, where you can see the name of the old the transaction(MDM_GetAssociations).
Action.c(13): Notify: Transaction "MDM_GenericServiceCall_ALL" started.
Action.c(14): Notify: Transaction "MDM_GetAssociations" started.
Action.c(15): web_custom_request("MDM_GetAssociations") started
Action.c(15): web_custom_request("MDM_GetAssociations") highest severity level was "warning", 505 body bytes, 1971 header bytes [MsgId: MMSG-26388]
Action.c(25): Notify: Transaction "MDM_GetAssociations" ended with "Pass" status (Duration: 1,8408 Wasted Time: 1,2668).
Action.c(26): Notify: Transaction "MDM_GenericServiceCall_ALL" ended with "Pass" status (Duration: 2,4066 Wasted Time: 1,2668).
Ending action Action.
Ending iteration 1.
You have two variables. You do not have their declarations here. You do not have their contents. And you appear to be casting them from another data type to a pointer to a character.
Does this pass with a literal, "My_Test_Transaction"? If so, then you are likely looking at oddities on how your variable is declared, populated and referenced.