I'm debugging a project using VS2012 ultimate, but encountered this problem very often now. usually it happens when i want to expand a collection type value(e.g, List<>, Dictionary<> and so on) to watch its value. It just failed to show the value and then hangs forever, the error message is like
"Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation." the only thing i could do is to restart the debugger.
can anybody give some help?
When you expand a value in the debugger to see its members, the debugger does somethings called a "func-eval" behind the scenes, which basically means it 'wakes up' one of the the threads in the debuggee and runs some code in it in order to display its result. This is usually either executing a property's getter or an object's .ToString() method.
Sometimes, the evaluation can take too long (often because a property getter gets stuck waiting on some lock that is held by another thread, in which case, you could keep waiting forever and it'll never return, because all threads except the thread that's doing the func-eval are paused by the debugger). In these cases, after a short while the debugger will decide to 'give up' and display the message you've encountered. You don't have to restart your app to try evaluating properties again - you can simply do another Step Over (F10).
As a more permanent solution, you can do one of two things:
Go into Tools->Options->Debugging->General and disable "Enable property evaluation and other implicit function calls". This will make the debugger's display a lot less useful as you will only be able to view fields, but it guarantees you will never get stuck and receive the timeout message.
Try to figure out which property in which object is the one that keeps timing-out. This can be a bit tricky, by try paying attention to which objects you are viewing when this happens - the timeout will usually occur just after you scroll down to the offending property. Once you know which property is at fault, either change it into a method, or put [DebuggerBrowsable(DebuggerBrowsableState.Never)] above it to prevent the debugger from displaying it.
Related
I need some help with selecting a value from a dropdown list. The dropdown is a WebElement, and the flow works well up to the point where the value should be selected.
My code is as follows:
.Browser("Browser").Page("PageName").WebElement("DropDownList").Click
.WebList("ListOfItems").Select(itemToSelect)
Note: itemToSelect is the name of the item that needs to be selected from the list, which is being passed as a parameter within the function.
When running the code, I get an unspecified error.
The weird thing is that before the error is thrown, I can see the value being selected from the list in the browser, as upon selecting it, some fields in the form change. Also, if I press "Skip" in the error message panel, the process goes on as if nothing happened.
I am certain the error comes from .WebList("ListOfItems").Select(itemToSelect) but I do not know what to do in order to fix it.
Try this code.It works for me.
StrAllItems = Split(Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetRoProperty("all items"),";")
For intCounter = Lbound(strAllItems) to Ubound(strAllItems)-1
If Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetItem(intCounter)= "SomeValue" Then
Browser("name:=.*").Page("title:=.*").WebList("name:=.*").Select (intCounter)
Exit For
End If
Next
Please let me know if this help.
If the test behaves correctly and you're just getting an superfluous error you can just ignore this specific error. It's best of course to understand where the error comes from, you should probably contact MicroFocus support but in the meantime you can turn off error handling for the offending line.
Browser("Browser").Page("PageName").WebElement("DropDownList").Click
On Error Resume Next ' turn off error handling
Browser("Browser").Page("PageName").WebList("ListOfItems").Select(itemToSelect)
On Error Goto 0 ' turn error handling back on
BTW, I changed your code a bit to make it valid, I assume this is what your code really looks like.
Possible timing issue: You might need to wait for the hole list to appear before you select the item.
Often, the item exists, but the app is still updating its GUI.
Whenever you access the GUI with UFT while the app is not idle (f.e. not ready for user input because it is still updating its HTML), you might get all kinds of strange results, including unexpected errors, hangs, instability.
So how do you wait for the list to be complete? I don't know, because it heavily depends on the way your app is refreshing its GUI. You need to explore that, and integrate some synchronization code that waits for the right condition to be met.
Unfortunately, this is a hell of a job sometimes.
A suitable workaround (and a good way to verify if my hyphothesis is correct) might be to insert a large delay between the first click and the list item selection click. (A quick way to do a similar thing is to single-step through the code.) If that does not generate any error or issues, you can be pretty sure it is what I describe, and you can experiment with lower delay durations to find a good value.
Thanks to everyone for your replies.
The issue turned out to be due to the object not being added well to the repository.
It was eventually fixed by adding it properly.
Currently, I see a recurring error:
2013-04-18 02:35:51.583 aaah[1713:1110f] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSArrayM: 0x1fc00dc0> was mutated while being enumerated.'
In the failing background queue (I see my queues state upon the moment of a crash by pressing Command + 5) I see:
0 _pthread_kill
1 pthread_kill
And I see assembly output which I completely don't understand.
I know how to resolve this kind of array enumeration errors - I just can't understand where/how I should seek for the piece of code causing my app to crash.
I have much multi-threaded code using AFNetworking and Core Data, so I can't just remember where the crucial section might be.
Also, this error occurs not always, but from time to time, so it is difficult just to use "isolation approach", isolating smaller and smaller pieces of code, to finally identify the buggy piece of code.
So the question is:
How can I extract some more useful information from this output, or Xcode can provide me with some more verbosity level, so I could know how to resolve this annoying piece of code.
Have you tried setting an exception breakpoint? Sometimes the debugger struggles with exception handling inside blocks but it might help.
In the breakpoints navigator (one of the tabs on the left side of the window) click the plus button at the bottom of the window and select add an exception breakpoint. Then hit done.
Now when you crash, the debugger should hopefully put you right before the instant the exception was raised.
See http://developer.apple.com/library/mac/#recipes/xcode_help-breakpoint_navigator/articles/adding_an_exception_breakpoint.html for more info.
Edit:
Based on the feedback provided in the comments, here's some more analysis:
The exception your application is raising means that you attempted to change a collection type (in this case, an NSMutableOrderedSet) inside of an enumeration block (in your case, most likely a for-loop). It looks like you're trying to remove objects in a set that you are looping over: [NSMutableOrderedSet removeObjectsInRange:inOrderedSet:]
To resolve this you should store the ranges you wish to remove and then do the actual removing once you're no longer iterating over the set. It's still going to be difficult since, as I understand it, you're not breaking inside of Objective-C code. You should look at the running threads in the panel on the left and look at what method they're currently in. That might give you a hint as to where your code is wrong.
We have a legacy PowerBuilder 12.1 Classic application with an Oracle 11g back end, and are experiencing performance issues in production that we cannot reproduce in our test environments.
The window in question has shared grid/freeform DataWindows and buttons to open other response windows, which when closed cause the grid to re-retrieve.
The grid has a very expensive query behind it, several columns receive their values from function calls with some very intense SQL within, however it still runs within a couple seconds, even in production.
The only consistency in when the errors occur is that it seems to be more likely if they attempt to navigate to the other windows quickly. The buttons that open said windows are assuming that a certain instance variable is set with the appropriate value from the row in focus in the grid. However, in this scenario, the instance variable has not yet been set, even though it looks like the row focus change has occurred. This is causing null reference exceptions that shouldn't be possible.
The end users' network connectivity is often sluggish, and their hardware isn't any less capable than ours. I want to blame the network, but I attempted to reproduce this myself in development by intentionally slowing down the SQL so that I could attempt to click a button, however everything happened as I expected: clicking the button didn't happen until after retrieve and all the other events finished.
My gut tells me that for some reason things aren't running synchronously when they should, and the only factor I can imagine is the speed of the SQL, whether from the query being slow, or the network being slow, but when I tried reproducing that effect things still happened in the proper sequence. The only suspect code is that the datawindow ancestor posts a user event called ue_post_rfc from rowfocuschanged, and this event does a Yield(). ue_post_rfc is where code goes instead of rowfocuschanged.
Is there any way Yield() would cause these problems, without manifesting itself in test environments, even when SQL is artificially slowed?
While your message may not give enough information to give you a recipe to solve your problem, it does give me a hint towards a common point of hard-to-diagnose failures that I see often in PowerBuilder systems.
The sequence of development events goes something like this
Developer develops code where there is a dependence on one event firing before another event, often a dependence through instance or global variables
This event sequence has been something the developer has observed, but isn't documented as a guaranteed sequence (like the AcceptText() sequence or the Update() sequence are documented)
I find this a lot with posted events, and I'm not talking about event and post-event where post-event is posted from event, but more like between post-ItemChanged and post-GetFocus
Something changes the sequence of events, breaking the code. Things that I've seen change non-guaranteed sequences of events include:
PowerBuilder version change
Operating system change
Hardware change
The application running with other applications taxing the system resources
Whoever is now in charge of solving this, has no clue what is going on or how to deal with it, so they start peppering the code with Yield() statements (I've literally seen comments beside a Yield() that said "I don't know why this works, but it solves problem X")
Note that Yield() allows any and all events in the message queue to be processed, while this developer really wants only one particular event to get through
Also note that the commonly-seen-in-my-career DO ... LOOP UNTIL (NOT Yield()) could loop infinitely on a heavily loaded system
Something happens to change the event sequence again
Now when the Yield() occurs, there is a different sequence of messages in the queue to be processed, and not the message the developer had wanted to be processed
Things start failing again
My advice to get rid of this problem (if this is your problem) is to either:
Get rid of the cross-event dependence
Get rid of event sequence assumptions
Manage the event sequence yourself
Good luck,
Terry
P.S. Here's a couple of quotes from your question that make me think of Yield() (not that I don't love the opportunity to jump all over Yield() grin)
The only consistency in when the errors occur is that it seems to be
more likely if they attempt to navigate to the other windows quickly.
Seen this when the user tries to initiate (let's say for example) two actions very quickly. If the script from the first action contains a Yield(), the script from the second action will both start and finish before the first action finishes. This can be true of any combination of user actions (e.g. button clicks, menu clicks, tabs, window closings... you coded with the possibility that the window isn't there anymore after the Yield() was done, right? If not, join the 99% of those that code Yield(), don't, and live dangerously) and system events (e.g. GetFocus, Deactivate, Timer)
My gut tells me that for some reason things aren't running
synchronously when they should
You're right. PowerBuilder (unless you force it) runs synchronously. However, if one event is starting before another finishes (see above), then you're going to get behaviours that look like asynchronous behaviours.
There's nothing definitive in what you've said, but you did ask about Yield(). The really kicker to nail this down is if you could reproduce this with a PBDEBUG trace; you'd see which event(s) is(are) surprising you. However, the amount that PBDEBUG slows things down affects event sequences and queuing, which may or may not be helpful.
im getting this error
but I have no idea why its happening. It stops happening when I restart visual studio, but after a while, it happens again. Its weird, since it happens just right after logging in. It makes me think that I left a connection open or there is something else going on. You guys have any idea of what could it be?
Hard to tell without knowing your project. But it may have to do with executing code in a setter, which is generally seen as an anti-pattern. (As an aside: the reason for that is that a setter suggests that you only change that little piece of the object's state, without side effects). An improvement would be to loop through ProjectList not sooner than when the ProjectExtensionList is addressed.
If setting the value for ProjectList is part of the materialization of its containing object (DashboardModel) the loop may cause a database read that has to wait for a connection that is involved in reading values for DashboardModels. If you defer the looping until when it is really necessary, at that point in time the DashboardModel object is in its final state and the connection should be available.
I read a description of how intellitrace in VS2010 Ultimate is like going back in time, in the execution of your application.
However, this sounds just like moving the line marker to a previous line (that yellow arrow in the breakpoints margin to the left of the code, when you are stepping through code).
Thanks
From Wikipedia:
Unlike the current debugger, that records only the currently-active stack, IntelliTrace records all events like prior function calls, method parameters, events, exceptions etc. This allows the code execution to be rewound in case a breakpoint wasn't set where the error occurred.
When you move the execution point back you run the same code again, but the variables might have different values. This is because running the code the first time may have changed some variables.
With Intellitrace you should be able to run the same code again with the same values as the first time. I have not tested it though.
The difference is that intellitrace keeps the history of each of those moments that it recorded. So unlike moving the line marker it is showing you the value of all the variables at that point in time. Similar to how a memory dump but for debugging.
It relies heavily on Tracing hence the name. Here is a good explanation of how it works. It's actually pretty cool.