Improve builtin error handler to return more information about problem #19
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
An example of error thrown by the current implementation of error handler looks as follows:
We miss a lot of information, especially a line number and some stacktrace.
17c486d599
makes error reports more like in PHPTODO:
Last point is very important, because output consumer takes a blob that needs memory allocation. If we exhaust all memory and some operation failed, it is almost certain that another try to allocate a memory for error blob will also fail. Then the callback from SAPI should be called. It should be implemented in SAPI, because it determines what to do with output.
Additionally, we can think about logging feature in the future.
Last point is not necessary, because it does not call the allocator on OOM. We just need to ensure there is a bit of memory left, because it can step on to the next instruction and throw error. I reserved 10KB for this purpose.
I got some doubt here:
Actually, to get information about file and line, we need to access pVm->aInstrSet, that is currently filled only if debugging is enabled. This is the only place, where we could find information about last or current byte code instruction call. Each instruction contains information about operator, file and line. This information is missing or provides false data on each error thrown. The only trust information can be found in this SySet. However, this needs some memory. When debugging is enabled, all instructions are put there, so they can be dumped after byte code execution. On normal execution, we just need current instruction IMHO. Thus I wonder, how to resolve this, as there are 2 ways:
The difference in memory usage for below sample code is exactly 5760 bytes! What do you think, which way to go?
OK, I checked this and definitely we should NOT store all instructions if this is not necessary! 10000 times empty 'for' loop iteration generated 80016 instructions. With debugging disabled, it allocated 415862 bytes, while with debugging enabled, the memory consumption increased to 6706934 bytes. It is almost 7MB! When increasing iterations to 100000, memory consumption grew again to over 50MB (50747126) with 800016 instructions stored.
Actually the following functions are used to report errors in VM:
Additionally, the following functions are used from PH7 context:
Example errors from new error handler:
Branch debug_rewrite merged to master.