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.
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'm getting the android logcat message "A resource failed to call close". I've tracked it down to where that message gets generated. Here's the code:
Properties defaultProperties = new Properties();
URL propURL = Util.class.getClassLoader().getResource(DEFAULT_PROPERTIES_FILE);
if (propURL != null)
{
InputStream is = null;
try
{
// Load properties from URL.
is = propURL.openConnection().getInputStream();
defaultProperties.load(is);
is.close();
}
catch (Exception ex)
{
The message is generated on the call to "defaultProperties.load(is)".
I put a breakpoint on that line, and when I step over that line, the warning message is generated. I'm not the author of the code but that line gets executed at least two times and its the second time when that line gets called when the warning gets generated. I just don't see how under any circumstances that a resource failed to close would be generated on that line. I'm at a lost to explain how or why that error message would be generated there. Any ideas?
After thinking about this, I've come to the conclusion that the problem doesn't have anything to do with the line "defaultProperties.load(is)" causing the warning. Although the message is always generated the second time that line is called, my current thought is that the problem is happening elsewhere but when this line gets called it's probably yielding to some other VM related thread time to process, and that process is detecting that some resource failed to close. I'm concluding that the problem is related to something altogether different and calling that line is the time when the problem surfaces, but it's not what's causing the problem.
Having:
Velocity template or macro
some object
How to validate the object (#if) and fail (stop further processing) in a way that is easily tracable to the place of failure (like throwing exception in Java).
I am looking for something like this:
#if ( ! $context.treasureMap.containsKey('gold'))
#fail('no golden treasure here')
#end
Background
I am writing a maven site page. The velocity context is injected by maven and contains POM information. I want to test existence of some information from effective pom. When the information is not available, I want to fail.
Requirements
fail Velocity processing > fail site generation > fail maven build.
error message should lead to the place of failure so the site should be fixed
preferably no configuration (no extensions, just constructs/tools contained in plain Velocity)
Tried
Strict Reference Mode
Unwanted configuration, do not want to fail on every occasion.
#evaluate('#end') aka syntax error
(Chose #end as most descriptive to my intent) Basically what I want. Fails the processing and maven build but the error message does not lead back to failure location:
ParseException: Encountered "#end" at line 1, column 1..
You need to make a method call which produce exception.See explanation:
The only place where one could run into trouble within Velocity is if there is a call to a method which throws an exception during runtime. For example, this VTL defines a String $foo and then attempts to call its substring() method on it would throw an IndexOutOfBoundsException:
#set ($foo = "bar")
#set ($bar = $foo.substring(0,10))
When the exception is thrown, the parser will stop processing and throw that exception up the stack tree where it can be caught in the method that caused the parser to execute. At that point, the exception can be handled gracefully.
I've got some code to parse an XML file like this:
[doc := (XML.XMLParser new) parse: aFilename asURI] on: XML.SAXParseException
do: [:ex | MyCustomError raiseSignal: ex description].
I now want to handle the MyCustomError higher in the stack, by moving the XML file to a folder named 'Failed', but I get a sharing violation error because the parser has not had the opportunity to close the file.
If I alter my code like this it works, but I wonder if there is a better way:
[doc := (XML.XMLParser new) parse: aFilename asURI] on: XML.SAXParseException
do: [:ex | description := ex description].
description ifNotNil: [MyCustomError raiseSignal: description].
Code can signal an exception for errors which are resumable (non-fatal); if you trap such an error you can't be certain that the XMLParser isn't intending to keep on going. For example, code that doesn't know whether it's being called in interactive or batch mode might signal an exception for a simple informational message; the caller would know whether to handle it in an interactive way (say with a message prompt) or a batch way (writing a message to a log file).
In order for this to work the pieces of code that are communicating in this way have to know what sort of an error it is they're dealing with. (This would typically be done with a severity level, encoded either by state in the exception object or by raising a different class of exception.) If you inspect the ex object you might be able to see this information.
In any case, the evidence suggests that XMLParser is treating SAXParseException as a resumable error (otherwise, it should clean up after itself). That being so, your "fix" seems appropriate enough.
you can also run the parser on a ReadStream instead of a URL. Then you can wrap your code in an ensure block where you close the readStream.
"The action of the default handlers is to print an explanatory message and exit." (link)
Example of such message:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 12 (X_ConfigureWindow)
Resource id in failed request: 0xc0007a
Serial number of failed request: 140
Current serial number in output stream: 141
If I set (XSetErrorHandler) my own "ignore everything" error handler, the "explanatory messages" disappear.
How to make Xlib ignore errors, but still print error messages?
If you actually want those error messages you pretty much have two options:
Pull _XPrintDefaultError out of XlibInt.c along with some private headers (with all the caveats of using library-private definitions).
Redefine exit() not to actually exit when _XDefautError calls it.
Neither is especially pretty and both may break and reduce your portability, but they do work.
You have to format your own message. The contents of the message is the contents of the XErrorEvent struct:
http://tronche.com/gui/x/xlib/event-handling/protocol-errors/default-handlers.html