I've hit against what I think is a race condition. What options do I have to debug it?
More details:
I have a Silverlight application which uses Telerik grid. The columns can be customised by the user by using a column chooser attached to the grid. In a particular case where the list of possible columns are created via the code, when I open the column chooser and close it, the data in the grid (all the rows) disappear!
Symptoms that I see which lead me to believe it is a race condition:
- If I put a break point at the columnchooser.close line, and when the break point is hit, just continue, the bug is not visible (all the gird rows remain visible)
- If I put a Thread.Sleep(1000) in the code just before columnchooser.close, again the bug disappears
- If I keep the "Threads" window in Visual Studio open while debugging, I see a thread momentarily appear and disappear in the Threads window just as I hit the breakpoint at columnchooser.close
So, I tried the following to figure out which threads are running at that point in time - but no joy:
System.Diagnostics.Process is not available in Silverlight, so I can't do System.Diagnostics.Process.Threads to get a list of the threads running programmatically.
I tried a break point with a "When hit" run Macros.Samples.VSDebugger.DumpStacks, but I couldn't figure out where it was dumping all the stack traces to.
Any help or ideas on what I can do to debug this issue?
Without the code this is necessarily vague, but have you looked into putting a lock on the columns or even the grid itself.
I'm not sure how this would actually work, but if (as you imply) the problem is due to the column chooser and the column creation code trying to access the grid at the same time then this might solve it.
Related
I have an application where items can be dragged and dropped between two lists. For this I use react-sortablejs (which uses sortablejs).
When I start my React application normally (in dev mode or deployed standalone) the drag and drop works as desired.
However, as soon as I embed the application in a SharePoint page (using webpart), the drag and drop feature starts to go haywire: the first drop works as desired, but all subsequent drops of the same item result in strange behavior, primarily duplication of the item.
After some debugging, it looks to me like the item remains in the old list and therefore an error occurs when the item is "pushed back" or a duplicate occurs because another item is pushed into the same list.
I therefore don't think that this is a problem of the library itself (also because I haven't found any similar error messages about this), but that it has something to do with SharePoint. I noticed in another context that classic context menus with absolute positioning also cause problems because event.pageX and event.pageY contain different values.
Anyway, at the moment I have no clue to get to the bottom of this problem, so I'm hoping that anyone might have had similar experiences before. Maybe this ticket will help someone else who runs into similar problems in the future.
My problem went away after setting forceFallack to true
I'm looking at improving developer experience when running graphics tests which spawn short-lived windows "like crazy". The windows need to be physically there, as otherwise data readback fails (i.e. the window cannot be hidden)
Needless to say, windows popping up at high frequency is unpleasant. I set out with the goal of finding a way to tell XCreateWindow to "create the window in the background", "not to steal focus" or something like that to no avail. The closest thing I could find is calling XSetInputFocus post-creation. Other than the fact that I couldn't make it work, I don't expect setting input focus to fully solve the issue anyway (as the windows would still pop up, just not without input focus, right?).
How is this done in X11?
P.S. The update notification on Ubuntu starts without popping to front, so this must be a possibility.
In the past I've tried and admitedly failed doing what you want to do. Nevertheless I've found a few "close-enough"-solutions that may be of interest.
XCreatePixmap might work out, but in my case didn't have a pixmap with desired properties (multisampling) so it "out the window" (haha)
To prevent some level of spaming you might be able to set XCreateWindow parent to a an exisiting window other than root, large enough to hold your tests and moved outside display. The parent window need be created, moved outside display and un-focused, but at least every window creation won't steal focus (I think) and spam on display.
Or you figure out a way to create additional displays, maybe using Xvbf. Didn't have admin access to corp dev env so didn't bother trying to install/configure, in addition to other obstacles, but it might just work for you.
I've got a complex WPF application with windows on multiple threads. Quite reproducibly, it happens that when I open and close a new window, the focus (activation) does not go back to the last activated window. Instead an (usually) older window gets activated. Since the workflow is "working in window A", "opening windows B, C from A", "working with B, C", "open window D from B", "close D", I'd need windows to return focus to B, but actually it goes to A.
I've already taken a look at stacktraces around the Window.Activated and Window.Deactivated events, but those come directly from the WPF infrastructure and do not show any clues. I've already tried Spy++, but its usefulness is ... limited.
How can I debug this further?
Update: The phenomenon vanished after I stopped blocking the thread of B for longer periods of time when creating D. It seems to be the case that the desktop window manager becomes confused, when threads block their message pump. I've plastered over the problem by pushing the message-pump blockers onto the Dispatcher with background priority before creating D. This seems to clear up any DWM confusion and windows activation doesn't act up anymore. I'd still be interested in pointers to a more in-depth solution/analysis.
You might not want to hear this but in these situations the next step I take is to examine the reference source for the the methods immediately in the stack of the relevant phenomenon. I don't know if you've use reference source before:
Microsoft Reference Source
Get this set up and then set up a breakpoint at the usual spot, say a focus event. Now look up the stack. You should be able to double-click and see source code for most of the stack frames. Of course it's a crap shoot but in any case better than looking at method names.
If you find you want to inspect some variables on the reference source side you'll find they don't work. Use this fix:
How to disable optimizations when debugging Reference Source
I know this is not very specific but this is what I would try next.
I have a WinForms data entry form that will have upwards of 1500 questions. I have the questions broken into sections, and each section will have an unkown number of questions. Each section is its own user control and has rows (2 panels, 2 labels, a textbox, and another user control) created and added dynamically for each question. The section controls are then added to the form.
My problem is that the process takes a lot of time, even with using TPL (Task Parallel Library). I would ultimately like to create/add the controls and allow the user to start entering data at the same time. The controls are going into a scrollable panel. While the user is entering data, that data will need processed on a local database...so more threading could be necessary.
I have tried working with TPL, which I am new to, by having all the controls added to a list during processing and then sorted and added to the form after the Parallel.ForEach was complete...takes about 20 seconds for over 1200 questions.
I also tried utilizing a BackgroundWorker component. Using the BWC seems to be the faster of the two, but there is a race condition for the ProgressChanged() eventhandler and not all controls get added...not to mention the way the form looks with all the rerendering.
Am i just using TPL wrong? What's the best way to go about this? Is there another way or do I just make the user stick out the wait?
Thanks
Am i just using TPL wrong? What's the best way to go about this? Is there another way or do I just make the user stick out the wait?
Most likely, you can use TPL, and get the same response time as BW, but a nicer API for this type of operation.
The trick here is to get a TaskScheduler setup for UI interaction, and then use the Task class to push the controls back onto the UI thread as they're ready. I have a blog post on this specific subject which shows how to get a TaskScheduler setup to use with UI threads.
However, I would recommend keeping these in memory and pushing them in batches, to avoid constantly re-rendering the UI. This is likely to be an issue no matter what you're doing.
That being said - I'd question your overall visual design here - if you're trying to display over 1200 questions to the user, some form of paging is probably a much nicer approach than a huge scrollable container. If you page these, you could load and process the first few (which is probably near instantaneous, since you mentioned you can process about 50 questions/second), and then continue loading the others after the first few questions have been displayed.
Check out following scenario:
A User control which contain two combo boxes...
First combo box contain list of States and Second combo box contain list of Cities. When you select a state the second combo box will contain list of cities using a LINQ query. When you select another state in first combo box the second combo box's items clear and refill. but when you want to open it DING DING! application gets HANG and your CPU will be 100% full!!!
unfortunately no Exception occurs during this operations and i don't know what to do!
NOTE: I am sure my LINQ operations and other operations work good and there is no infinite loop or dirty code or something else!
Any idea or such problem?
Break into the debugger and look at the call stacks of your threads. Are they executing in a loop or waiting on some synchronization? If you resume execution and break again a short time later, are they still executing in the same loop? If your application is pegging the CPU, then there is code somewhere in there that's doing a lot of work. You just need to figure out where that is.