if I put a debuger from starting line one of this code and step through i dont get anything
event after the line
xmlData = reader.ReadToEnd();
but if I have debugger on the last line of this code.. where the brace closes, I get everything. i dont know if this only the debuger acting crazy, or a real thing
using (StreamReader reader = new StreamReader(context.Request.InputStream))
{
xmlData = reader.ReadToEnd();
}
Can anyone tell me whats going on. cause sometimes i am not able to get any data from streamreader, even though the data is sent correctly.
Thanks
The reader isn't going to perform the actual "read" until the ReadToEnd method is called. What are you trying to do?
If you put a breakpoint on a line the break occurs before that line gets executed, so it's no surprise that you don't get any data.
But I suspect what you mean is that you place a breakpoint and then step through the code slowly until you reach the end and then check the contents of the variable and find that they are empty.
One cause could be a timing issue. It could be that the service you are reading from has timed out.
Another cause could be a race-condition in your code.
One other unexpected thing that can catch people out is that watches can cause side-effects and stepping through the code causes the watches to be re-evaluated. This can change the state of your program depending on where you put the break-point. You should be careful not to set up a watch on a property that has a side-effect when evaluated.
Related
There isn't much documentation around it.
http://msdn.microsoft.com/en-us/library/system.net.http.httpcontent.readasbytearrayasync(v=vs.118).aspx
If it does not guarantee that the whole Content how do I know when to stop reading?
You don't tell it when to stop reading. It returns a Task<byte[]>. So, after some amount of time, it will either
finish reading the entire body and then give it to you as a single byte[], or
encounter a problem and throw an exception.
If no exception is thrown, it has successfully read the entire body as a byte[].
I am having some trouble with while loops in C#. This happens let's say once per week.
I am looping through a SQL Server data reader and I read simple strings, doubles etc ... I don't understand why this happens once in a while. If there were a problem in my code then its performance should be ALWAYS poor.
To be more specific, when this happens, when I set a breakpoint, the thread breaks after 3 or 4 seconds. And the weirdest thing is that if I press F5 or if I "step-by-step" the loop, it takes less time !
That's really weird and it makes me crazy.
I am wondering if someone ever encountered this type of weird deal.
Thanks in advance for your replies !
PS : The while loop is executed by a particular thread (not the main one).
PS 2 : here is my code
reader = DBConnect.GetInstance.ExecuteReader(request.ToString(), out connection, timeOut);
while (reader.Read())
{
SourceInst sourceInst = new SourceInst();
sourceInst.Load(reader);
sourceInstList.Add(sourceInst);
}
Your database performance is likely varying, thus causing your issues. The SqlDataReader provides a stream to your database and does not buffer in memory. Your assumption that the "query is executed before looping" is incorrect. The stream remains open and you're reading one record at a time from the data source via cursor with this loop. Therefore, as your DB performance fluctuates, so does your loop's performance. It does not load and buffer all records into memory prior to the loop - you can do that if you like but I don't recommend it in terms of memory usage.
There is huge amount of code in my project which already debugged 50% of it.
Every time I try to debug it I have to manually set breakpoints after unwanted piece of code to skip it.
Is there a way to tell debugger not to debug that part of code ?
Any extension for this ?
Let's face debugger is on line 1500.
Method1(){
Line 1500 CODE
Line 1501 CODE
...
Line 1726 CODE
Line 1727 CODE
...
Line 2200 CODE
}
I won't need to debug lines between 1727 and 2200.
NOTE : It's not just one piece. Otherwise I would be fine with manual breakpoints
Don't know why it's not in the answer but you can set next statement by CTRL+SHIFT+F10 or dragging the yellow arrow to wanted line and code before next statement will not be executed.
Found it here
If the code in question is encapsulated in a method, you can skip the method by applying the DebuggerStepThroughAttribute on it.
Other than that, setting breakpoints is how to do it.
So, extract this code into a method and apply the attribute to it ;)
You can also click on the line you want to skip to and hit Ctrl+F10 (Run to Cursor). It will jump directly to that line.
Is it possible to automatically return from a function using a Breakpoint/Tracepoint?
I don't want to drag the execution point or set it with CTRL+SHIFT+F10 every time the breakpoint is hit.
I tried "printing" the following "messages" When Hit, but the executions continue without change.
{return;}
{return null;}
Note that I need to return from the function without actually changing code.
To clarify what a Tracepoint is: "A tracepoint is a breakpoint with a custom action associated with it. When a tracepoint is hit, the debugger performs the specified tracepoint action instead of, or in addition to, breaking program execution." From MSDN.
If you don't know what I mean with "printing messages", you might want to read this AltDevBlogADay post about Tracepoints. It's good.
In Visual Studio you could just drag the arrow, that indicates the current code line while debugging, to the end of the function.
Okay, after a bit of digging around you can do this - but it's not going to work in all cases.
Beware, this uses macros and can't be guaranteed to work with inline delegates; or with methods that actually need to return something. It automates the process described by #juergen d and #Erno when a breakpoint is hit; using very simple heuristics to find where the end of the current function is.
You first need to add this macro to your macros environment (open with ALT+F11 in VS). This code is probably not as good as it could be as I've just rushed it out :)
Sub ExitStack()
'get the last-hit breakpoint
Dim breakPoint As EnvDTE.Breakpoint
breakPoint = DTE.Debugger.BreakpointLastHit()
'if the currently open file is the same as where the breakpoint is set
'(could search and open it, but the debugger *should* already have done that)
If (DTE.ActiveDocument.FullName = breakPoint.File) Then
Dim selection As EnvDTE.TextSelection = DTE.ActiveDocument.Selection
Dim editPoint As EnvDTE.EditPoint
'move the cursor to where the breakpoint is actually defined
selection.MoveToLineAndOffset(breakPoint.FileLine, breakPoint.FileColumn)
Dim codeElement As EnvDTE.CodeElement
codeElement = DTE.ActiveDocument.ProjectItem.FileCodeModel.CodeElementFromPoint(selection.ActivePoint, vsCMElement.vsCMElementFunction)
'if a function is found, move the cursor to the last character of it
If Not (codeElement Is Nothing) Then
Dim lastLine As EnvDTE.TextPoint
lastLine = codeElement.GetEndPoint()
selection.MoveToPoint(lastLine)
selection.StartOfLine(vsStartOfLineOptions.vsStartOfLineOptionsFirstText)
'execute the SetNextStatement command.
'Has to be done via ExecuteCommand
DTE.ExecuteCommand("Debug.SetNextStatement")
End If
End If
End Sub
With that in place, now you can set your breakpoint - right click on it and hit the When hit... menu option (this only works in VS2010 I believe). ScottGu describes this in this blog post.
From the dialog, find the ExitStack macro that you've just pasted in.
Run the code with the debugger attached and when the breakpoint is hit the rest of the function's code should be skipped. This should obey other debugger tricks - like conditions etc.
Note - I used this SO to solve a problem I was having; originally I was invoking the debugger's SetNextStatement method directly and it didn't work
I have no idea how methods that should return will behave - in theory they should return whatever the return value local is at the time, but in some cases the fact is this simply won't work!
Equally if the breakpoint is in a try/catch block then it won't work - because the try/catch has to be exited before you can set the next statement to somewhere outside of it.
Two options:
If you want the function to complete its execution and break after returning to the caller. Press "Step Out" (Shift-F11)
If you want to skip the execution of several lines, drag the yellow marker to the next line you want to execute. Remember, dragging the marker to a location might cause an order of execution that can never happen when running without interfering so the result might be completely wrong.
Yes, you can do this directly using a tracepoint.
Find the address of the return statement at the bottom of the function by breaking on it once, and then looking at the EIP register either in the Registers window or add a Watch for "#eip".
Add a tracepoint to the line you want to jump from. Remember that the jump will occur before anything on the line is executed. The content of the tracepoint should be {#eip = address} using the address from step 1.
Profit!
See also https://stackoverflow.com/a/14695736/301729
There's trouble using the System.IO.MemoryStream class.
After creating it, like so:
var memory = new MemoryStream();
it then sets the length of some bytes to write into it.
var length = 181;
memory.SetLength( length);
Then in the debugger, the memory shows the Length and
Position BOTH set to 181. In separate simply test program
it property shows Position still at zero after SetLength().
Furthermore, if I change the Position property to 0 using
the debugger or by adding a line of code, it ignores
and still shows 181 as the position property. Thus it
behaves as if immutable.
However, again in a simple unit test, this works as expected.
At first, this appeared to be a threading issue as
if MemoryStream isn't thread safe. But in the debugger,
I froze all other threads before calling any of this code.
And it still fails as above.
Well, this is the most bizarre. Any ideas what to try?
I don't see the same thing as you. If I create a console application with the following code in Main:
var x = new MemoryStream();
x.SetLength(181);
..and trace past the call to SetLength, the debugger shows Length equal to 181 and Position equal to 0. You must have something else affecting your stream object.
Actually, figured out the problem. First clue was that it only happened in the debugger.
The cause was the the ToString() method was overridden.
It was reading the memory and displaying it in the debugger. That was reading from the memory and therefore modifying the Position.
Problem solved.
Thanks.