Xdebug's call stack shows 10 entries. Is there a way to show more? I didn't seem to find an option related to this in the documentation (http://xdebug.org/docs/all_settings).
From what I gathered, it appears that 100, not 10 is the default maximum depth a call stack can reach. It is controlled by the xdebug.max_nesting_level variable:
xdebug.max_nesting_level
Type: integer, Default value: 100
Controls the protection mechanism for infinite recursion protection. The value of this
setting is the maximum level of nested functions that are allowed
before the script will be aborted.
http://xdebug.org/docs/all_settings#max_nesting_level
It won't work as a solution to control how many steps are shown in a call stack though. If this setting was for example used to limit the shown calls to 5, it would also mean that the script would fail after a nesting level of 5. Whether an actual error had occurred or not.
In conclusion: there is no mechanism in Xdebug that would be usable to control the amount of calls displayed once an actual error occurred.
Related
I am trying to understand how the auto rescheduling logic is supposed to work.
The recommended values in nagios.cfg are:
auto_reschedule_checks=1
auto_rescheduling_interval=30
auto_rescheduling_window=45
Supposedly this is after they realized the default values (same as above but with window=180) had the potential to have checks that never actually get executed (See https://support.nagios.com/kb/print-19.html).
But.. How are these new values any different?
How I understand it, every 30sec, it takes the next 45sec of checks, finds checks that overlap, and reschedules those evenly across the 45sec.
Isnt it possible for a check to indefinitely get rescheduled into that last 15 seconds of the 45sec window?
Am I missing something? Do rescheduled checks get an elevated priority so they arent rescheduled again? Reading through the code, it doesnt appear they are given any special treatment.
Seems to me that the only way to prevent that is for the interval and window to be the same.
Which means maybe a couple checks occurring right at each 30sec transition may go unnoticed,
but Id rather that than what I am presuming the behavior is with the "recommended" interval=30sec , window=45sec.
Any insights would be helpful!
I am using react profiler to make my app more efficient. It will commonly spit out a graph like this:
I am confused because the timings do not add up. For example, it would make sense if the total commit time for "Shell" was 0.3ms then "Main" was "0.2ms of 0.3ms." But that is not the case.
What precisely do these timings mean and how do they add up?
(note: I have read "Introducing the React Profiler" but it appears from this section that this time-reporting convention is new since that article.)
The first number (0.2ms) is the self duration and the second number (0.3ms) is the actual duration. Mostly the self duration is the actual duration minus the time spent on the children. I have noticed that the numbers don't always add up perfectly, which I would guess is either a rounding artifact or because some time is spent on hidden work. For example, in your case, the Shell has an actual time of 3.1ms and a self duration of 0.3ms, which means the 2 children (Navbar and Main), should add up to 3.1ms - 0.3ms, or 2.8ms. However, we see that the Navbar is not re-rendered, so it's 0ms, but the actual duration for Main is only 2.7ms, not 2.8ms. It's not going to have any impact in practical terms when you're performance tuning, but it does violate expectations a bit.
I'm trying to evaluate Apache Flink for the use case we're currently running in production using custom code.
So let's say there's a stream of events each containing a specific attribute X which is a continuously increasing integer. That is a bunch of contiguous events have this attributes set to N, then the next batch has it set to N+1 etc.
I want to break the stream into windows of events with the same value of X and then do some computations on each separately.
So I define a GlobalWindow and a custom Trigger where in onElement method I check the attribute of any given element against the saved value of the current X (from state variable) and if they differ I conclude that we've accumulated all the events with X=CURRENT and it's time to do computation and increase the X value in the state.
The problem with this approach is that the element from the next logical batch (with X=CURRENT+1) has been already consumed but it's not a part of the previous batch.
Is there a way to put it back somehow into the stream so that it is properly accounted for the next batch?
Or maybe my approach is entirely wrong and there's an easier way to achieve what I need?
Thank you.
I think you are on a right track.
Trigger specifies when a window can be processed and results for a window can be emitted.
The WindowAssigner is the part which says to which window element will be assigned. So I would say you also need to provide a custom implementation of WindowAssigner that will assign same window to all elements with equal value of X.
A more idiomatic way to do this with Flink would be to use stream.keyBy(X).window(...). The keyBy(X) takes care of grouping elements by their particular value for X. You then apply any sort of window you like. In your case a SessionWindow may be a good choice. It will fire for each key after that key hasn't been seen for some configurable period of time.
This approach will be much more robust with regard to unordered data which you must always assume in a stream processing system.
What is the equivalent of the following for a C-mex s function? That is, how do I set discrete sample time of a block to the top level fixed step size in C?
My problem is, I could not find a way to "get" the top level fixed step size parameter in C-mex.
function setup(block)
block.SampleTimes = [str2double(get_param(bdroot, 'FixedStep')) 0];
Use ssGetFixedStepSize to get the base rate of the model. You may also want to ssSetErrorStatus if the that call returns 0, because that means your model is not configured with a FixedStep solver.
If, for some reason, you really want to go about fetching the information similar to what you have in the question, then you might be able to get access to it if you dig through the SimStruct pointer's fields. To do this, breakpoint in the mex file using a debugger and watch that variable.
Another option would be a few mexCallMATLAB calls to get the information you want.
I have this code
n_userobject inv_userobject[]
For i = 1 to dw_1.Rowcount()
inv_userobject[i] = create n_userobject
.
.
.
NEXT
dw_1.rowcount() returns only 210 rows. Its so odd that in the range of 170 up, the application stop and crashes on inv_userobject[i] = create n_userobject.
My question, is there any limit on array or userobject declaration using arrays?
I already try destroying it after the loop so as to check if that will be a possible solution, but it is still crashing.
Or how can i be able to somehow refresh the userobject?
Or is there anyone out there encounter this?
Thanks for all your help.
First, your memory problem. You're definitely not running into an array limit. If I was to take a guess, one of the instance variables in n_userobject isn't being cleaned up properly (i.e. pointing to a class that isn't being destroyed when the parent class is destroyed) or pointing to a class that similarly doesn't clean itself up. If you've got PB Enterprise, I'd do a profiling trace with a smaller loop and see what is being garbage collected (there's a utility called CDMatch that really helps this process).
Secondly, let's face it, you're just doing this to avoid writing a reset method. Even if you get this functional, it will never be as efficient as writing your own reset method and reusing the same instance over again. Yes, it's another method you'll have to maintain whenever the instance variable list changes or the defaults change, but you'll easily gain that back in performance.
Good luck,
Terry.
I'm assuming the crash you're facing is at the PBVM level, and not a regular PB exception (which you can catch in your code). If I'm wrong, please add the exception details.
A loop of 170-210 iterations really isn't a large one. However, crashes within loops are usually the result of resource exhaustion. What we usually do in long loops is call GarbageCollect() occasionally. How often should it be called depends on what your code does - using it frequently could allow the use of less memory, but it will slow down the run. Read this for more.
If this doesn't help, make sure the error does not come from some non-PB code (imported DLL or so). You can check the stack trace during the crash to see the exception's origin.
Lastly, if you're supported by Sybase (or a local representative), you can send them a crash dump. They can analyze it, and see if it's a bug in PB, and if so, let you know when it was (or will be) fixed.
What I would normally do with a DataWindow is to create an object that processes the data in a row and call it for each row.
the only suggestion i have for this is to remove the rowcount from the for (For i = 1 to dw_1.Rowcount()) this will cause the code to recount the rows every time it uses one. get the count into a variable and then use the variable. it should run a bit better and be far more easy to debug.