Tiburon Preview: Vista Wait Chain Traversal
I see that several of my co-workers have started blogging about new features in Tiburon, the upcoming release of Delphi and C++Builder. If you haven’t already, check out what Allen, Nick, Chris, and Seppy are saying. For the Tiburon release cycle, since much of the debugger had previously been Unicode-enabled, I’ve been working on mostly non-debugger things, including being heavily involved in the "Unicodification" of the other parts of the IDE. That said, those of us on the debugger team were still able to include a few new features in Tiburon. This article will describe one of the new features.
In Tiburon, we’ve added support for Vista Wait Chain Traversal. Wait Chain Traversal is made possible by new APIs included in Windows Vista and Windows Server 2008, and as such, this new debugger feature is only available if you are running on one of those OSes. For reference, the MSDN link that describes this feature is http://msdn.microsoft.com/en-us/library/ms681622.aspx.
This feature allows you to get detailed information about thread deadlocks that occur in your program. This can make it much easier to debug problems that traditionally have been very hard to debug. Not all types of thread deadlocks can be debugged using Wait Chain Traversal. As mentioned in the above referenced MSDN article:
WCT currently supports the following synchronization primitives:
- ALPC
- COM
- Critical sections
- Mutexes
- SendMessage
- Wait operations on processes and threads
To give a sense of how this feature is implemented in Tiburon, I’ve included the following screenshot:
You’ll see that in the Thread Status view, a new column, titled "Wait Chain" is shown. This column only shows up if you’re running on an OS that supports Wait Chain Traversal. In the screenshot, a program that is deadlocked has been paused in the debugger. Let’s take a look at what the new column in the thread view is telling us:
- The main thread is blocked waiting on Thread. In this case the main thread has called WaitForSingleObject on a thread handle. The thread being waited on is the thread with a "Threaad Id" of 3792 (the third thread in the list)
- The thread being waited on is, itself, blocked. In this case it is waiting for a SendMessage call to return. The message has been sent to a window that is owned by thread 2792 (the second thread in the list)
- That thread (2792) in turn is waiting to get access to a CriticalSection. Basically, the message loop for this window, in response to the message sent by thread 3792, has asked for a CriticalSection. However, as you can see, that CriticalSection is currently owned by thread 3792.
So basically, we have two threads (1284 and 2792) that are waiting for a third thread (or for a resource owned by that thread). That thread in turn is also blocked, waiting for something on one of the other threads. This leads to the deadlock. The intention is that with the extra information about each thread involved in the deadlock, it will be much easier to debug and fix the problem leading to the deadlock. This is a welcome addition to the OS and in turn to Delphi and C++Builder.
One final note: Although the above screen shot shows this feature using a C++Builder test case, Wait Chain Traversal also works with native Delphi programs.
Share This | Email this page to a friend
Posted by Chris Hesik on July 21st, 2008 under CodeGear Debugger | 13 Comments »The Delphi and C++Builder QA Manager is blogging!
Although it’s not new news, I just found out that our Quality Assurance Manager, Chris Pattinson has been blogging. He’s got several good posts, giving some insight into the QA processes here at CodeGear. I didn’t know that he’s been blogging, since his posts haven’t been part of the main aggregated CodeGear blog feed (http://blogs.codegear.com/). I imagine many in his target audience also did not know he’s been blogging. I just went down to his office and gently reminded him to make sure he includes any future posts in the main feed.
Anyway, I suggest checking out his posts, and I know he’d love to hear feedback and comments from customers regarding our QA processes. Let’s see if we can get his FeedBack numbers higher than zero on any of his posts!
Welcome (albeit belatedly) Chris!
Share This | Email this page to a friend
Posted by Chris Hesik on May 24th, 2007 under Uncategorized | 1 Comment »C++Builder: Debugging application startup
Earlier today, a question posted on the C++Builder IDE newsgroup was brought to my attention.
An excerpt of the newsgroup posting follows:
I have a Windows app that has suddenly started crashing on me **before** it
gets to WinMain, making it difficult for me to debug.
The event log shows the thread starting and exiting before it hits my
breakpoint on WinMain.
Can anyone suggest how I can track down the cause of the problem.
Good Question! This reminded me of a subtle feature in the C++Builder debugger that can help you debug problems that occur during application startup. The C++Builder debugger will behave differently depending on how you initiate your debug session.
In the following table, I outline how different debugger Run Menu commands operate, when used to initiate a debug session:
| Run Menu Command | Keystroke (default keymapping) | Action |
|---|---|---|
| Run | F9 | The application runs under the debugger’s control until the first breakpoint, exception, etc. is encountered or until termination. |
| Step Over | F8 | The application runs and stops at the program entrypoint, typically main or WinMain |
| Trace Into | F7 | The application is loaded into the debugger, but it doesn’t actually run. The process is loaded, but no actual code has been executed. You will almost certainly be looking at the CPU view at this point. |
| Trace to Next Source Line | Shift-F7 | The application runs and stops at the first source line that is executed. This could be one of several places. It could be main or WinMain, in which case this behaves the same as Run | Step Over. If your program has global objects whose types have constructors, this could be the constructor for the first global object. If your application is a VCL application, and you are building with debug versions of the VCL libraries, this could be initialization section of one the source units in the Delphi RTL or VCL. |
To illustrate, take a look at the simple console app shown in the following screenshot (which coincidently is taken using a pre-release build of the upcoming C++Builder 2007 release):
The entire source code for this illustration is shown above in the IDE. Using this sample, you can see the differences between the different methods of initiating a debug session.
If you use Run | Run (F9), the program will run until it hits the breakpoint set on the return statement in main.
If you use Run | Step Over (F8), the program will run and stop at the entrypoint of main.
If you use Run | Trace Into (F7), the program will be loaded by the debugger, but no code will execute. It will be sitting at the true program entrypoint, and you’ll be shown the CPU view (since there is no source code available for the entry point).
If you use Run | Trace to Next Source Line (Shift-F7), the program will run and stop on the first executable source line encountered. In this case, that will be the MyClass::MyClass constructor (which is called to construct the myInstance global variable).
By using either F7 or Shift-F7, you can essentially debug all of your program code that is executed before the main program entrypoint of main or WinMain. You should be able to use this technique in all versions of C++Builder (in writing this post, I’ve verified it in BCB1, BCB6 and C++Builder2007).
Share This | Email this page to a friend
Posted by Chris Hesik on May 24th, 2007 under CodeGear Debugger | 1 Comment »Set Next Statement menu item in Delphi’s Code Editor
In my “Debugger Enhancements since Delphi 7” post, I received a comment that it was not clear what I meant with the item “Set Next Statement menu item in the editor“.
To clarify, this feature is a new menu item on the code editor’s local popup menu. Under normal circumstances, this menu item appears on the “Debug” submenu of the editor’s local menu. If you’ve enabled the Rearrange editor local menu on run option on the Tools | Options | Debugger options page, then, while you are debugging, this menu item will appear directly on the editor’s local menu (and not on a Debug submenu) along with the other debugger items.
This menu item lets you change the next source line that will be executed, effectively letting you alter the behavior of your program at runtime. Before this menu item was added, you had to drop into the CPU view to change the next statement to be executed. You could do this in the CPU view using the New EIP menu item on the disassembly pane’s local menu or by directly changing the value of the EIP register in the Registers pane. Now, with this new menu item, you can accomplish the same thing in the code editor. To use this menu item, simply right click on the source statement that you want to be executed next and select the Set Next Statement menu item. Then when you Run or Step using the debugger, it will continue execution from that point.
The editor menu item is roughly equivalent to the menu item in the CPU view — the major difference is that when you use it in the editor, the debugger must first figure out which instruction corresponds to the source code statement you’ve selected. This is simply a matter of getting the address of the first instruction and setting the EIP register to that address. If you need to set the EIP to an address that does not correspond to the first instruction of the source code statement, then you will still need to use the CPU view to accomplish this.
Being able to change the next instruction executed is a powerful feature of a debugger; however, you can easily shoot yourself in the foot by doing this. It is important to note that using this menu item does not cause your program to run until the statement is reached. If you want to do that, you should use the Run to Cursor or Run to Current commands in the editor or CPU view, respectively (both of which can be executed using the F4 keystroke in the default keymapping). Instead, all that happens is the debugger sets the next statment or instruction to be executed. It does not change any other program data, so it is very easy to cause your program to crash using these commands (for example, if you use these commands to skip code that sets up data required later in program execution). Because of the inherent danger of this command, the IDE will prompt you for confirmation if you use the “Set Next Statement“ command in the editor on a source code line that is not part of the current method being debugged.
There are a couple of situations where I use the Set Next Statement and New EIP commands. A common one is where I’ve inadvertently stepped over a method that I meant to step into. Rather than re-run the program, in many cases, it is safe to set the Next Statement back to the method call that I wanted to step into. After doing this, I can then use Step Into to step into the function. Note, that this basically means that the method will get executed twice — once when I stepped over it, and once again when I reset the EIP and then step into it. If the code is not intended to be executed twice, then, of course, problems may arise, but in many situations, it may be perfectly safe to do this.
Another situation where I use this is when I want to step through a method multiple times. Sometimes it takes quite a few steps to get your application to its failure point. In these situations, it might be easier to reset the EIP to be able to further examine code that has already executed, rather than start the program over again and repeat the steps required to reproduce the failure. Again, as long as the code is safe to execute more than once, you should be able to use this functionality over and over to repeatedly step through a method without having to repeat the steps required to get to that point.
These are just two cases where Set Next Statement and New EIP are useful. There are plenty of others as well, and once you’ve used them to help debug your program, they can become indispensable tools in efficiently tracking down problems in your code.
Share This | Email this page to a friend
Posted by Chris Hesik on April 30th, 2007 under CodeGear Debugger | 3 Comments »Debugger Enhancements since Delphi 7
In the spirit of Nick’s Since Delphi 7 — On Steroids and Steve’s VCL and RTL enhancements since Delphi 7 (D7), I’d like to provide a similar list for Debugger Enhancements (and other changes) which appear in Delphi 2007 that have been added in the various releases since the Delphi 7 release. This is just a quick, non-exhaustive, bullet list, and does not include any features that do not apply to the Delphi Win32 personality. It also does not include bug fixes. If you’d like more details on any of these, feel free to leave a comment and I’ll be happy to expand on a feature in a future blog post.
Breakpoints and Breakpoint List View:
Call Stack view:
- Better, more complete stack traces — stack frames with no debug info are now shown
- Tighter integration with the Locals view:
- – can now view locals for a given stack frame using the local menu
- – double clicking an item now automatically shows that frame’s locals in the Locals view
- Option on local menu to show Fully Qualified names in call stack
- Glyphs shown to indicate whether or not a frame has debug info
- Ability to toggle a breakpoint on the point of return for a given stack frame
Watch view:
Local Variables view:
Thread Status view:
- Name and path of symbol table file is now shown in separate column
- Module load order now shown in a separate column
- Ability to sort modules by module name, module path, base address, symbol table name, or load order
- Modules view now lives in the editor view
Event Log view:
- New Event log option allows you to specify if the event log should automatically scroll newly-added items into view
CPU view:
- Full CPU view now lives as an editor tab
- Individual panes in CPU view can be opened separately as independent dockable views
- Open up to 4 separate Memory panes to view different locations of memory (or the same location in different display formats)
- Multi-selection in disassembly pane allows you to highlight and copy to clipboard any contiguous instructions
- New local menu item in the disassembly pane: Show Addresses
- New local menu item in the disassembly pane: Show Opcodes
- New local menu item in all panes: Copy
- New Display formats in Memory pane: UTF8 and MultiByte
- Disassembly pane now supports disassembling SSE/PNI instructions
FPU View:
- FPU view now has a new pane that shows SSE registers
- FPU view is now a dockable view
Inspector View:
- Debug Inspectors are now dockable views
Editor View:
Evaluator tooltips:
- Now supports expandable evaluation allowing you to drill down into your program’s data structures
- Tooltips go transparent when Ctrl key is pressed
Run Menu:
- Run without debugging menu item
- Load Process menu item provides separate UI for loading an arbitrary process into the debugger (previously, the Run | Parameters dialog was overlodaded to support this)
- Detach from Program allows you to end the current debugging session without terminating the application being debugged (supported under XP and later)
Debugger Options:
- The Debugger options are now part of the Tools | Options dialog rather than a separate Tools | Debugger Options dialog.
Exception handling:
- The Exception Notification dialog now allows you to decide whether you want the debugger to stop on the exception. This is implemented via "Break" and "Continue" buttons that appear on the dialog.
- The Exception Notification dialog now allows you to tell the debugger to ingore a particualr exception type. This is implemented via an "Ignore this exception type" checkbox that appears on the dialog.
- The "Stop on Delphi Exceptions" option is now called "Notify on Language exceptions".
- There is now a toolbar button that can be added to an IDE toolbar that allows you to quickly enabledisable the state of the "Notify on language exceptions" checkbox
Project Options:
- You can now control the environment block for the debugged process using the Environment Block page in either the Run | Parameters, Project | Options, or Run | Load Process dialogs
- You can now control the symbol tables loaded for the debugged process using the Symbol Tables page in either the Run | Parameters, Project | Options, or Run | Load Process dialogs
- You can now control the debug source path for the debugged process using either the Run | Parameters, Project | Options, or Run | Load Process dialogs (this option moved from the Project | Options | Directories/Conditionals page)
Better thread support:
Other:
- All views are unicode enabled, providing the ability to see unicode data in your program
- Many ToolsAPI enhancements related to debugger support.
Share This | Email this page to a friend
Posted by Chris Hesik on April 13th, 2007 under CodeGear Debugger | 11 Comments »The Delphi 2007 Debugger and DEP/NX
As Mike points out in this blog post, the compiler in Delphi 2007 now supports ASLR and NX. In addition to the compiler support, the debugger in Delphi 2007 is now also able to run on a machine with DEP enabled. DEP is the “set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from running on a system“. The hardware side of DEP uses the NX (no-execute page protection)processor feature as part of its implementation.
Perviously, there were problems with using the Delphi debugger on a machine with DEP enabled. The QualityCentral item for this issue is 32047. As the QC report indicates, these problems were corrected with Delphi 2007. If you previously disabled DEP on your machine in order to use the Delphi debugger, with Delphi 2007, it should be safe (and probably advisable) to turn it back on.
Share This | Email this page to a friend
Posted by Chris Hesik on April 6th, 2007 under CodeGear Debugger | 1 Comment »Developer Bowl 2007
I haven’t seen anyone else mention it yet, but last night at the SD West conference, the annual Developer Bowl was held. The Developer Bowl is basically an IT industry trivia contest which pits local silicon valley companies against each other.
Some of the questions asked were pretty esoteric. I’m certainly glad I was in the audience and not up on stage having to answer the questions. There seemed to be three general categories of questions: 1) IT history questions 2) Programming Language trivia, and 3) “Who said it?” style questions, where a quote was given and the teams had to guess who said that quote.
The rules (or “policies”, as they were called duing the event) were:
- Each round lasts 13 minutes.
- Each question is worth 10 points.
- One person must be selected to answer for the group.
- You have 10 seconds to answer each question.
- If a team answers the question wrong, the other team gets to answer the question.
- If you buzz before the entire question is read, the host will not finish reading the question.
If the question is answered incorrectly, the other team will be read the full question
and have 10 seconds to answer the question. - Winner of the first round meets the winner of the second round in the Finals.
Last night, the participants were Google, Yahoo, IBM and CodeGear (not a bad group for CodeGear to be associated with). CodeGear’s team was comprised of David I, Michael, Allen, and Ken Chan (they all did a great job, by the way!) . In round one, it was Google vs. Yahoo. In round two, it was CodeGear vs. IBM.
Google defeated Yahoo in the first round. In the second round, the CodeGear team defeated IBM (Go CodeGear!). In the finals, however, our team lost to Google — the Google team was really quick on the buzzer and they definitely knew their stuff. DavidI had a great quote in the middle of the final round: “Of course they’re winning, they have a search engine on their side!”
Although we didn’t end up winning, it was a fun event and it gave CodeGear some great exposure among the attendees. I was wearing a CodeGear t-shirt, and I had a couple people who hadn’t heard about our status as a separate entity ask me about the company. I also overheard DavidI and Michael talking to attendees about our company, explaining who and what we are.
One final note, we ran into a former Borland employee at the event, and it turns out he has just accepted an offer to come back and work with us at CodeGear. That is definitely great news. By the way, we have plenty of other openings, if you are interested.
Share This | Email this page to a friend
Posted by Chris Hesik on March 23rd, 2007 under Uncategorized | 1 Comment »Where are the Desktop State Files in Delphi 2007?
A few days ago, Nick posted an article, explaining where the examples are located in Delphi 2007. The examples are not the only things to have changed locations in Delphi 2007 (though they may be the most visible). As Nick explains, these changes were necessary to make Delphi a better citizen under Windows Vista.
In the same vein, I wanted to point out another set of files that have changed locations in Delphi 2007 — the Desktop State Files (*.dst).
The Desktop State files are the data files that are associated with the Save Desktop feature in the IDE. This is the following combo box that appears on Delphi’s main window that allows you to switch among different desktop layouts, save desktop layouts and set the desktop to be used when debugging:
Three stock desktop state files ship with Delphi — “Default Layout.dst“, “Debug Layout.dst“ and “Classic Undocked.dst“. These three stock dekstop layouts get installed into Delphi’s bin folder. In previous versions of Delphi, the desktop state files stayed in the bin folder, and any new desktop states that you created were also kept in the bin folder. However, since the bin folder lives (by default) under the “Program Files“ folder, these files need to get moved to a location that is writable to the standard user under Vista (since users can modify and save these layouts to fit their preferences).
To accomplish this, the first time a given user runs Delphi 2007, the stock desktop layout files are copied from the bin folder into the current user’s Delphi application data folder. The actual folder varies by operating system and, but it is typically “C:\Documents and Settings\USERNAME\Application Data\Borland\BDS\5.0“ on WindowsXP and “C:\Users\USERNAME\AppData\Roaming\Borland\BDS\5.0“ on Windows Vista. The desktop layouts are then loaded from the application data folder rather than from the bin folder.
Any time you make changes to a desktop layout and save them, you are only modifying your local copies. The versions in the bin folder remain untouched. If you create a new desktop layout, the corresponding .dst file is also created in your application data folder. In addition to making the IDE a better Vista citizen, this change also provides an easy mechanism to revert to the installed versions of the stock desktop state files. If you’ve made changes to any of the three stock desktop state files, you can simply delete the desktop state file (using either the UI in the IDE or by manually deleting the .dst file from your application data folder), and the next time the IDE starts, the unmodified stock version of the desktop state file will be recopied from the bin folder into you application data folder.
Share This | Email this page to a friend
Posted by Chris Hesik on March 22nd, 2007 under Uncategorized | 3 Comments »Drag ‘n’ Drop in the Delphi Debugger
One of the things that I showed during my CodeRage session (replays are currently available here), is the ability to drag and drop text from the editor to the debugger’s Watch view in order to create a new watch. To be honest, I wasn’t even intending to show that as a feature since it’s not new in Delphi 2007 (if I remember correctly, this was introduced in Delphi 6) — I was just using drag and drop to quickly add a new watch. Since then, I’ve seen and heard comments from several people who did not realize the debugger supported this.
As mentioned during my session, if you are currently debugging, you do not need to do anything special to drag text out of the editor into one of the debugger views. If you are not debugging, then you’ll need to hold the Alt key down when you start the mouse-drag operation. If you do not hold the Alt key down, then the editor will think you are dragging code around to reposition it within the current file.
Although I only showed dragging text into the Watch view, there are several other debugger views that support dragging text into them from the code editor.
- In the EvaluateModify dialog, you can drag text into the Expression field to quickly evaluate a new expression.
- If you have a Debug Inspector open, you can change the expression being inspected by dragging text into either the list of members shown or into the drop down combo box near the top of the Inspector.
- In any of the CPU Stack or Memory views, you can drag text anywhere within the view. If the text you drag represents an expression that has a valid data address, then that expression’s address will be shown in the view.
Share This | Email this page to a friend
Posted by Chris Hesik on March 19th, 2007 under CodeGear Debugger | 2 Comments »Delphi 2007: Really Cool Software Delivery
I’ve heard us call the new installer technology “Instantaneous Software Delivery (ISD)” or “Electronic Software Delivery (ESD)”. I think I’ll call it “Really Cool Software Delivery”. Whatever it’s called, Michael talks about it here.
Being on the Delphi 2007 R&D team, I tend not to use the Delphi Installer that often. For various reasons, an installed build doesn’t co-exist well on a machine where you’ve checked out and built the Delphi sources. During this release cycle, however, I’ve used the installer more than in the past due to the fact that we’ve been using VMs quite a bit. That makes it easy to keep an installed build around for testing purposes. That said, during the development cycle, when I’ve wanted an installed build on my VM, I’ve just installed it from one of CodeGear’s internal network servers. Doing that simulates a DVD install, since all the bits needed are available in the delivery folder.
However, now that we’ve signed off on Delphi 2007, releasing it to manufacturing, I wanted to update my home computer with the latest and greatest Delphi. Sure, I could have burned a DVD at work and brought it home (though I would have had to wait until Monday to do so, since I work from home a couple days a week, Friday being one of them). Or I could have logged in to the CodeGear network from my home computer and installed from there. Instead, I wanted to see what all the hype regarding ESD was about. So, I just copied down a nice, small, compact setup.exe and ran it from my home computer. When I ran it, this small, compact setup.exe connected to the appropriate place on the net and started installing, first all the prerequisites (as my home computer had not yet had the pleasure of installing the .NET 2.0 framework and SDK), and then the freshly minted gold bits of Delphi 2007.
All in all, it was a fast easy way to get Delphi 2007 installed. I’ve used a similar delivery mechanism when purchasing software from other vendors who support it, and it’s always a great feeling to get your new software instantaneously. I think those of you who don’t like to wait patiently for the UPS/FedEx/DHL/etc. man to show up with your new toy (I know I don’t) are going to love this new delivery mechanism.
Now that I’ve got the newest Delphi version on my home computer, I can finally see what all the hype is about 
Share This | Email this page to a friend
Posted by Chris Hesik on March 16th, 2007 under Uncategorized | 5 Comments »Server Response from: dnrh1.codegear.com
RSS Feed