Generics and Delphi enumerated types without RTTI

Some Delphi types do not have RTTI. This is no fun. This happens when, and I quote:

whereas enumerated constants with a specific value, such as the following, do not have RTTI:
type SomeEnum = (e1 = 1, e2 = 2, e3 = 3);

In normal use, this will go unnoticed, and not cause you any grief, until you throw these enumerated types into a generic construct (or have any other need to use RTTI). As soon as you do that, you’ll start getting the unhelpful and misleading “Invalid Class Typecast” exception. (No it’s not a Class!)

To avoid this problem, you must wander into the dark world of pointer casting, because once you are pointing at some data, Delphi no longer cares what its actual type is.

Here’s an example of how to convert a Variant value into a generic type, including support for RTTI-free enums, in a reasonably type-safe way. This is part of a TNullable record type, which mimics, in some ways, the .NET Nullable type. The workings of this type are not all that important for the example, however. This example works with RTTI types, and with one byte non-RTTI enumerated types &mdash you’d need to extend it to support larger enumerated types. While I could reduce the number of steps in the edge case by spelunking directly into the Variant TVarData, that would not serve to clarify the murk.

constructor TNullable<T>.Create(AValue: Variant);
type
  PT = ^T;
var
  v: Byte;
begin
  if VarIsEmpty(AValue) or VarIsNull(AValue) then
    Clear
  else if (TypeInfo(T) = nil) and
    (SizeOf(T) = 1) and
    (VarType(AValue) = varByte) then
  begin
    { Assuming an enum type without typeinfo, have to
      do some cruel pointer magics here to avoid type
      cast errors, so am very careful to validate
      first! }
    v := AValue;
    FValue := PT(@v)^;
  end
  else
    Create(TValue.FromVariant(AValue).AsType<T>);
end;

So what is going on here? Well, first if we are passed Null or “Empty” variant values, then we just clear our TNullable value.

Otherwise we test if (a) we have no RTTI for our generic, and (b) it’s one byte in size, and (c) our variant is also a Byte value. If all these prerequisites are met, we perform the casting, in which we hark back to the ancient incantations with a pointer typecast, taking the address of the value and dereferencing it, fooling the compiler along the way. (Ha ha!)

Finally, we find a modern TValue incantation suffices to wreak the type change for civilised types such as Integer or String.

Testing for design time in Delphi, in an initialization section

Sometimes it can be handy to test for design-time in a component unit when the component package is first loaded, e.g. within an initialization section, rather than when a component is created or registered. We use this to validate that runtime units that interoperate with a component are linked into a project, and raise an error as early as possible if they are not.

With Delphi’s RTTI, this is fairly straightforward, I believe:

function IsDesignTime: Boolean;
begin
  Result := TRttiContext.Create.FindType('ToolsAPI.IBorlandIDEServices') <> nil;
end;

Is there anything wrong with this?

Even charset geeks can be fooled by character spoofing

I was preparing a new git repository today for a website, on my Windows machine, and moving a bunch of existing files over for addition.  When I ran git add ., I ran into a weird error:

C:\tavultesoft\website\help.keyman.com> git add .
fatal: unable to stat 'desktop/docs/desktop_images/usage-none.PNG': No such file or directory

How could a file be there — and not there?  I fired up Explorer to find the file and there it was, looked fine.  I’d just copied there, so of course it was there!

usage.png seems to be there just fine

For a moment, I scratched my head, trying to figure out what could be wrong.  The file looked fine.  It was in alphabetical order, so it seemed that the letters were of the correct script.

Being merely a bear of little brain, it took me some time to realise that I could just examine the character codepoints in the filename.  When this finally sunk in, I quickly pulled out my handy charident tool and copied the filename text to the clipboard:

usage-none-selection

And pasted it into the Character Identifier:

usage-none-charident

With a quick scan of the Unicode code points, I quickly noticed that, sure enough, the letter ‘g‘ (highlighted) was not what was expected.  It turns out that U+0261 is LATIN SMALL LETTER SCRIPT G, not quite what was anticipated (U+0067 LATIN SMALL LETTER G).  And in the Windows 8.1 fonts used in Explorer, the ‘ɡ‘ and ‘g‘ characters look identical!

g-g
I checked some of the surrounding files as well.  And looking at usage-help.PNG, I could see no problems with it:

usage-help-charident

So why did git get so confused?  OK, so git is a tool ported from the another world (“Linux”).  It doesn’t quite grok Windows character set conventions for filenames.  This is kinda what it saw when looking at the file (yes, that’s from a dir command):

usa[]e

But then somewhere in the process, a normalisation was done on the original filename, converting ɡ to g, and thus it found a mismatch, and reported a missing usage-none.PNG.

Windows does a similar compatibility normalisation and so confuses the user with seemingly sensible sort orders.  But it doesn’t prevent you from creating two files with visually identical names, thus:

double-usage-none

I’m sure there’s a security issue there somewhere…

Camping at Freycinet

On Sunday, I finally took Hannah camping, as I had promised quite some time ago.  The weather was great and off we went, a Dad and Daughter camping trip!  We ate fish and chips in Swansea, had a coffee and cake (dad had coffee, daughter had cake!) at Tombolo’s in Coles Bay, and then started walking over the Wineglass Bay Lookout, and down to Wineglass Bay.  Wineglass Bay Beach seemed to last forever, but we eventually arrived at our camp spot, at the far end of the beach, which was warm, and still, and deserted.  It was beautiful, as we ate our pasta for dinner and then explored after dinner, finding amazing views, and shells and bones.  Wallabies were interested, and none too shy, of us and our packs and things.

Camping overnight went well, and the following morning, we walked back out, and back over the Wineglass Bay Lookout.  To pass the time as we climbed, Hannah gave me a Five Things Story to tell.  This is a little tradition we have, where one of us gives the other five random things, and we have to construct a story out of it.  Here’s the story for the climb:

Five Things: Little girl, man, spy agency, secret spy lamp, magical talking hairbrush

Daniel Higginbottom was, to all appearances, a very ordinary man.  He drove a boring brown car, ate boring breakfast cereal, and worked as an accountant in the Department of the Treasury in the Kingdom.  But as we shall see, things aren’t always quite what they seem.  Not even to Daniel.

One morning, Daniel arose, got dressed, ate his breakfast, and drove his ordinary brown car down to his office, where he parked in his usual spot under the building, and took the lift up to his office.  And here’s where we discover the first thing.  For while Daniel appeared to work in the Department of the Treasury, in actual fact, his job was definitely interesting.  Because Daniel was a spy!

On this fine morning, Daniel walked into the Spy Master’s office, to which he had been summoned the instant he arrived in the building.

“Daniel, my man, I have a new mission for you!  Do you wish to accept it?”

“What?  How can I decide if I will accept it unless I know what it is?”

“Well, I could tell you, but then if you didn’t accept, I’d have to kill you,” his boss replied.

“Uh, well, in that case, I accept!” said Daniel.

“Good man!  I knew I could count on you!” cried the Spy Master.  “Now, in the neighbouring kingdom, there is a princess who has a priceless magical talking hairbrush.  We require you to obtain this hairbrush and return it to our kingdom.  Any questions?”

“None so far,” said Daniel, who as you can probably tell by now was a very confident fellow.

“Very well.  We have prepared your usual Spy Gadgets, and one new one: this tube of toothpaste which I am passing you now appears to be completely normal, until you press it just so” – and the Spy Master pressed it, just so – “and then it turns into a Secret Spy Lamp.”  And so it did.

“Excellent!” said Daniel enthusiastically.  He turned and walked out of the office, collecting his Spy Kit on the way, and made his way back down to the car park.  I should mention at this point that he was now known as Fred Smith, Agent Extraordinaire.  And there was no way that Fred Smith, Agent Extraordinaire could possibly drive a boring brown car.  No, he drove a bright red sports car.

And so “Fred” drove his bright red sports car all the way to the neighbouring kingdom.  He had no trouble making his way to the capital, and as soon as he arrived, he saw the posters announcing that there was to be a Ball at the King’s Castle-Palace the following evening, to celebrate the eighth birthday of the princess.  “Excellent!” thought our intrepid agent.  Now he just needed to get an invitation.

He drove around the beautiful little city that surrounded the palace-castle up on the mount, until he found a couturier, where a steady stream of young ladies entered and exited, getting last minute changes made to their ball gowns.  He watched and waited for a bit until he spotted a young lady that he decided would be his target.

He approached her and introduced himself.  Then he asked about all the people going into the milliners’ store, and she explained about the Ball.

“Oh wow!” said Fred-Daniel.  “I’ve always wanted to go to a Ball!”

“That’s amazing!” exclaimed the young lady. “It just so happens I have a spare invitation.  Would you like it?”

“Would I ever?” responded Fred, enthusiastically as ever.  “Boy,” he thought to himself, “this mission is a walk in the park.  Twenty minutes in and I’ve already got a way into the Palace!”  And then he tried his next card: “would you like a lift home in my bright red sports car?”

“That would be lovely,” said the young lady.  (And here, may I add, if an enthusiastic young man ever offers *you* a lift home, especially if he is driving in a bright red sports car, I would highly recommend you *don’t* accept!)

A few minutes later, the young lady said, “please drop me at this corner.”  They stopped, and she continued, “I’d really like to introduce you at the Ball – would you like to pick me up from this corner tomorrow evening, at 5pm?”

“Certainly!” said Daniel-Fred.  “How much easier could this mission get?” he thought.

So Agent Fred made his way to his hotel, where he slept and then breakfasted somewhat in the manner of his alter ego, that is, boringly, and prepared for the Ball that evening.  Near 5 o’clock, all dressed up in his finest clothes, he made his way to the corner, where sure enough, the young lady was waiting!

They drove together up the hill to the castle, a windy road clinging to the edge of the cliff, passing every now and then houses perched on the very edge of the precipice.  Finally, they arrived at the palace gates, and the young lady leaned over and said, “Madelina Brompton, and guest.”  (So now we finally know her name.)  The palace guard seemed to think this was just fine, and opened the gate, and in they drove.

They followed the line of cars carrying guests to the Ball, until Madelina told Fred to park in her own parking spot, before they reached the front door.  As soon as the car pulled to a stop, four men leaped out of a door and surrounded the car!  Daniel-Fred looked at Madelina with astonishment, as she now sat there holding a gun, pointing at him.  “Out of the car, please, Mr Smith, or should I say Mr Higginbottom!” she asked.

Daniel certainly felt confused.  How had she cracked his secret identity?  But he didn’t have much time to think about that, as he was hustled down the stairs and into a dark cell.  As the door slammed, he started to feel a bit sorry for himself, until he remembered his toothpaste tube.  They hadn’t taken that from him, at least.  He could have clean teeth … no, wait, he could see!  He pressed the toothpaste tube just so, and it lit up, just so.  He explored his cell carefully, and finally found down in one corner, some writing scratched on the wall: “the way lies beneath.”

This seemed too good to be true, but Daniel was enthusiastic and confident, even despite this minor setback in his plans, so he set to testing all the flagstones until he found one that lifted up.  And indeed there was a passage out from his cell from this flagstone.  Without hesitation, he dived down the passage, and shortly thereafter found himself in the sewer tunnel under the Palace.

A few minutes later, he found himself outside the Palace walls, the Palace high above him on the cliff face.  But Daniel was on familiar ground again: he knew how he could get into the Palace, and instantly started to climb his way up the cliff face to the windows shining out into the night, high above him.  Surely there would be an open window somewhere, and he wouldn’t have to climb all the way to the roof!

And there was, above and to the right, an open window.  Carefully but smoothly he climbed up the wall, swinging himself from handhold to handhold, just like any secret agent would.  He reached the window very quickly indeed, considering how high the cliff was, and how high the walls reached above the cliff, and swung himself inside, behind the curtain, and caught his breath.

He felt like gasping for breath, and his heart hammered in his chest, but he could hear someone talking in the room, on the phone it sounded like, so he worked hard to make no noise at all.  The person’s voice sounded somewhat familiar, and he listened as she spoke: “… yes … no problem at all … he did seem rather the confident sort … oh no, I’m sure he has escaped from that cell now … any moment now I’m sure he’ll be climbing in my window and I’ll be ready …”

Daniel froze.  But only for a second, and then he dove back out the window, and clung grimly to the wall, waiting and straining to hear the rest of the conversation.

“ … just a second …” and, yes, it was Madelina Brompton who pulled the curtains back and looked around while Daniel pushed himself against the wall and tried his hardest to keep out of sight in the shadows.  She let the curtains swing open and went back to the telephone “ … no, no sign of him … he mustn’t be as good as we thought …” and here Daniel grinned to himself in grim glee – at least here he had outwitted her!  Madelina finished her conversation and Daniel heard the door close.  He waited a minute, and then hauled himself back into the room.

Daniel pondered.  What was going on?  How did Madelina know about him?  Did she know about his mission?  Had someone given him away?

But the room was now deserted, and Daniel quickly cracked the door open and looked down the hallway.  It shouldn’t be hard from here to make his way to the Princess’s suite, he thought.  And it wasn’t.  The hallways seemed to be deserted, although he could hear in the distance the sounds of a Grand Ball.

Daniel looked at his clothes regretfully.  They certainly weren’t spick and span now, ready for a Ball, after having clambered through a secret passage, slithered down a sewer, and climbed up a wall.  Despite that, they were surprisingly clean!

Without a lot of trouble, and without being spotted, he found the Princess’s suite, and eased his way in the door.  And there, sitting on a dressing table, visible through the open door of the dressing room, was a hairbrush.  No doubt, the very hairbrush he had been tasked to collect!

He quickly strode across the room, walked into the dressing room, reached for the hairbrush, and felt someone looking at him.  He turned, and there sitting in the corner of the dressing room, was Madelina Brompton!

“Welcome, Daniel!” she said.  Daniel swung around to leave, but someone was now standing in the doorway.  His Spy Master was standing in the doorway.  Daniel’s world was falling.  What was going on?  Now, the young princess arrived in the doorway too!

The Spy Master looked at him.  “Daniel,” he said, “you’ve been too over-confident recently, and we wanted to teach you a little lesson.  You fell for the basic trick of trusting a stranger!  And see where it got you!”

“What I think is funny,” said the princess, “is that you just believed that my hairbrush was magical and could talk!  That’s just crazy!”

“But I can talk!” said her hairbrush.

THE END

After the lookout, we made our way to the carpark, deposited our big packs, and immediately started the climb of Mt Amos. We knew we had only 3 hours to get to the top and back, and it certainly was a challenging climb! But we made it! And got back to the car park, only 2 hours and 50 minutes later.

We took lots of photos. Here are some of the best holiday photos (the scenery photos are later):

[AFG_gallery id=’1′]

Hannah and Dad Trip – Holiday Photos, a set on Flickr.

Then we drove back, stopping in Swansea for fish and chips, and a quick sorbet at Kate’s Berry Farm, before driving all the way back to Hobart, to the telling of another Five Things Story.

Five Things: king, queen, ballerina, diamond, boy
Once upon a time, in the far-off Kingdom of Knott, there lived a kindly King and Queen. They loved their Kingdom, and looked after it, and the pride of their hearts and in fact the pride of the entire Kingdom was the stupendous diamond that was on display in the most important ballroom in their palace!

This diamond sat on a velvet cushion in a glass display case in the ballroom. The King would sometimes lie awake at night, worrying that the diamond might be stolen, but he had protected the diamond as best as he knew how, with the Palace Guards, a secret camera, and even the glass case itself was bulletproof! All would come from far around to gaze upon the magnificence of the diamond. The King and Queen would often stop, on their way to bed, just to admire it!

Now, the Kingdom of Knott (not the Kingdom of Not, nor even of Nott, or Knot, but Knott) was going to have a magnificent celebration. And the highlight of the celebration would be the solo ballet performance by none other than the most famous star of ballet, Madame Tutu! The whole Kingdom waited for the day to arrive.

All but one, that is. Young Jack was not really looking forward to the day to arrive. Jack worked as a servant in the Palace, in the kitchens, and he was the least important person in the whole palace. His usual job was to peel the potatoes for the all the meals and banquets, and to be bossed around by everyone else from the Head Cook on down to the Scullery Maids.

But Jack was also a nice boy and didn’t complain or really even mind that much! All the same, the Grand Banquet on the day of celebration would involve a lot of potatoes so he was dreading that a bit! Of course, the king and queen had no idea that he even existed, because they would never go into the kitchens.

The day before the celebration finally arrived. Madame Tutu arrived, in pomp and state, dressed in resplendent gown and trailing feathers and jewels. She was immediately taken to see the diamond, and it was hard to tell which outshone the other – the ballet dancer, or the jewel! After mutual admiration (if a diamond can admire…) Madame Tutu retired to her suite to prepare for the big day.

Downstairs, Jack peeled potatoes. Lots and lots and lots of potatoes! In fact the pile looked so large, it didn’t seem like he’d ever finish it. But finally, after midnight, he finished peeling the last potato, placing it on the huge pile next to him, ready for cooking, and climbed wearily into his bed, between the scullery door and the potato bin, pulling the old sacks that he used for blankets over his shoulders and instantly falling asleep.

Back upstairs, Madame Tutu’s bed didn’t have any sacks for blankets. No sir! In fact, she had silk, and cushions, and duvets, and a mattress ever so soft and large. But surprisingly enough, Madame Tutu was not in the bed. She was sitting at a table, looking at a large piece of paper. Paper that looked surprisingly like a floor plan. And in fact, it was a floor plan of the palace! What on earth was she up to? And then she picked up an instruction manual for a security camera. Why would she be interested in that?

With a satisfied smile, she placed the manual down on the table, and started to get changed. But not into pyjamas. She put on black tights, black top, and even small black shoes. She put on a black belt with little compartments on it, and a thin black rope looped up on it. She pulled black gloves over her hands, and finally pulled a black mask over her head! What was going on?

Madame Tutu opened her door, and stealthily crept down the stairs, into the servants’ wing, where she slipped past the sleeping boy Jack, and opened the scullery door. A chill breeze blew in and down Jack’s neck, and he woke up and opened one eye lazily. He saw a lady all dressed in black clothes quietly closing the door, and creeping back up the stairs.
Now Jack was curious, so he slipped out of bed and quietly followed her. And saw her stop just outside the grand ballroom, and unhook her rope and toss it over a beam far overhead. Then she quickly climbed up the rope and swung through a window up near the ceiling, into the ballroom itself! Jack could just see her, putting something on top of the security camera in the ballroom, before she swung back down into the ballroom and out of sight.

Jack quickly crept into the ballroom. This lady in black was certainly up to no good! He watched her pull out a diamond saw from her belt and cut a hole in the magnificent diamond’s display case. It may have been bulletproof, but it wasn’t sawproof! She pulled the cut piece of glass away with a sucker, and pulled a small rock out of her belt (her belt had a lot of useful things in it!) The lady (who we know as Madame Tutu) hefted the rock in her hand before gently, ever so gently, passing it through the hole in the display case, and smoothly, but quickly, replacing the diamond with the rock!

She placed the diamond in her belt and then Jack acted. He jumped out, grabbed her rope, and tripped her over with it! All of a sudden, the graceful, lithe lady in black didn’t seem so graceful as she fell over with a thud and uttered a whole lot of very unladylike words! She tried to fight but Jack had surprised her and managed to tie her up. Then he raised the alarm. How did he do that? Well, he just pulled the rock off the diamond’s cushion, and the diamond alarm system went off immediately!
The palace guard came charging in. He knew Jack, of course, and in fact Jack was his nephew. Then he saw the lady in black. Jack told him to look in her belt compartment, so he did, and discovered the diamond! The king and queen came running in, the king in his dressing gown, and with a night cap on, not looking at all like a king, and the queen in her dressing gown and hair rollers, not looking at all like a queen! They stared as the palace guard took off the lady’s mask, and all gasped as they realised it was none other than Madame Tutu! The palace guard told the king and queen that Jack had uncovered the plot, and the king was astonished, and asked Jack what he would like as a reward.

Jack was embarrassed. “Oh I don’t need anything,” he said, “I was just happy to save the diamond!”

“In that case,” replied the king, “I think I will give you a knighthood! But for now, off to bed!”

And with that Jack went back down to his bed, between the scullery door and the potato bin, pulling his sacks over his shoulders and eventually falling asleep again. Madame Tutu was taken down to a cell, where a much more uncomfortable bed than she had been expecting awaited her!

The next morning, Jack told the other servants what had happened, but they laughed at him and told him to go and clean the big pile of dishes. Only moments later, though, a huge stir went through the servants’ hall, as none other than the king made his way down the stairs and asked for Jack! Could it possibly be true? And it was, as the king took him upstairs, where servants fussed over him, and cut his hair, and his fingernails, and scrubbed him until he was pink, and generally pushed and pulled until Jack thought he might prefer scrubbing potatoes! They dressed him in clothes so fine that Jack didn’t know what to say, and was afraid to even look in case he tore or stained them.

Jack was led into the grand ballroom, where all the nobles of the kingdom waited for the ceremony to start. The royal herald stood and announced, “please welcome Madame Tutu, here for her solo ballet performance!” The king leaned over and whispered in his ear. “Um,” said the royal herald, at a loss for words, for once in his life, before he recovered, and said, “Due to unforseen circumstances, we shall be cancelling Madame Tutu’s performance and shall instead have a knighthood ceremony!”

The nobles all looked at each other and started whispering. What could be going on? The king called Jack forward, and in an official and pompous voice, explained: “Last night, Madame Tutu was caught red handed, attempting to steal our most precious and beloved jewel, the Royal Diamond of Knott! Caught red handed, that is, by none other than young Jack here, as he went far above and beyond his duties …” Here he paused and looked at Jack, and whispered, “Ah, what are your normal duties, Jack?”

“Peeling potatoes, Sire,” Jack whispered back.

“Oh… ah,” continued the king, and then decided to leave Jack’s duties unmentioned, “ … and he raised the alarm and rescued our kingdom from certain ignomy and disaster!” As you can tell, the king liked to use big and official sounding words in his speeches. “Thus we have ascertained that we must offer Jack no less than a knighthood for his services to the Kingdom!”

The nobles stood and applauded! Jack stood first on one leg, and then the other, and wished he could disappear into his shoes. But the king took out his sword, and laid it first on one shoulder, and then the other, and proclaimed, “I hereby name you Sir Jack, Most Honourable Knight of Knott!” (Does that sound complicated?)

From that day on, Jack’s life was never the same. In fact, it was much more complicated, even if he did sleep in a more comfortable bed, and occasionally he would think back to his simple life peeling potatoes. But of course, Jack grew up and served the Kingdom as a Knight, and finally ended up marrying the princess. But he never really did like eating potatoes all that much!

THE END

Do you want to know what happened to Madame Tutu? Well as I said, the king and queen were kindly, so they decided that her punishment should just be to peel potatoes, for the rest of her life!

I won’t try to relate Hannah’s Five Things stories, as I’d be sure to make mistakes. So perhaps I’ll ask her to write them up and add them to the story!

Scenery photos!

[AFG_gallery id=’2′]

Hannah and Dad Trip – Scenery, a set on Flickr.

(Edited, 11 Mar, a milliner is a hatmaker, duh)

Finding class instances in a Delphi process using WinDbg

Using WinDbg to debug Delphi processes can be both frustrating and rewarding. Frustrating, because even with the tools available to convert Delphi’s native .TDS symbol file format into .DBG or .PDB, we currently only get partial symbol information. But rewarding when you persist, because even though it may seem obscure and borderline irrational, once you get a handle on the way objects and Run Time Type Information (RTTI) are implemented with Delphi, you can accomplish a lot, quite easily.

For the post today, I’ve created a simple Delphi application which we will investigate in a couple of ways. If you want to follow along, you’ll need to build the application and convert the debug symbols generated by Delphi to .DBG format with map2dbg or tds2dbg. I’ll leave the finer details of that to you — it’s not very complicated. Actually, to save effort, I’ve uploaded both the source, and the debug symbols + dump + executable (24MB zip).

I’ve made reference to a few Delphi internal constants in this post. These are defined in System.pas, and I’m using the constants as defined for Delphi XE2. The values may be different in other versions of Delphi.

In the simple Delphi application, SpelunkSample, I will be debugging a simulated crash. You can choose to either attach WinDbg to the process while it is running, or to create a crash dump file using a tool such as procdump.exe and then working with the dump file. If you do choose to create a dump file, you should capture the full process memory dump, not just stack and thread information (use -ma flag with procdump.exe).

I’ll use procdump.exe. First, I use tds2dbg.exe to convert the symbols into a format that WinDbg groks:

Convert Delphi debug symbols
Convert Delphi debug symbols

Then I just fire up the SpelunkSample process and click the “Do Something” button.
Clicking "Do Something"
Clicking “Do Something”

Next, I use procdump to capture a dump of the process as it stands. This generates a rather large file, given that this is not much more than a “Hello World” application, but don’t stress, we are not going to be reading the whole dump file in hex (only parts of it).
Procdump to give us something to play with
Procdump to give us something to play with

Time to load the dump file up in Windbg.

I want to understand what is going wrong with the process (actually, nothing is going wrong, but bear with me). I figure it’s important to know which forms are currently instantiated. This is conceptually easy enough to do: Delphi provides the TScreen class, which is instantiated as a global singleton accessible via the Screen variable in Vcl.Forms.pas. If we load this up, we can see a member variable FForms: TList, which contains references to all the forms “on the screen”.

TScreen = class(TComponent)
private
  FFonts: TStrings;
  FImes: TStrings;
  FDefaultIme: string;
  FDefaultKbLayout: HKL;
  FPixelsPerInch: Integer;
  FCursor: TCursor;
  FCursorCount: Integer;
  FForms: TList;
  FCustomForms: TList;
  ...

But how to find this object in a 60 megabyte dump file? In fact, there are two good methods: use Delphi’s RTTI and track back; and use the global screen variable and track forward. I’ll examine them both, because they both come in handy in different situations.

Finding objects using Delphi’s RTTI

Using Delphi’s Run Time Type Information (RTTI), we can find the name of the class in memory and then track back from that. This information is in the process image, which is mapped into memory at a specific address (by default, 00400000 for Delphi apps, although you can change this in Linker options). So let’s find out where this is mapped:

0:000> lmv m SpelunkSample
start    end        module name
00400000 00b27000   SpelunkSample   (deferred)             
    Image path: C:\Users\mcdurdin\Documents\SpelunkSample\Win32\Debug\SpelunkSample.exe
    Image name: SpelunkSample.exe
    Timestamp:        Tue Dec 10 09:19:01 2013 (52A641D5)
    CheckSum:         0071B348
    ImageSize:        00727000
    File version:     1.0.0.0
    Product version:  1.0.0.0
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0409.04e4
    ProductVersion:   1.0.0.0
    FileVersion:      1.0.0.0

Now we can search this memory for a specific ASCII string, the class name TScreen. When searching through memory, it’s important to be aware that this is just raw memory. So false positives are not uncommon. If you are unlucky, then the data you are searching for could be repeated many times through the dump, making this task virtually impossible. In practice, however, I’ve found that this rarely happens.

With that in mind, let’s do using the s -a command:

0:000> s -a 0400000 00b27000 "TScreen"
004f8f81  54 53 63 72 65 65 6e 36-00 90 5b 50 00 06 43 72  TScreen6..[P..Cr
004f9302  54 53 63 72 65 65 6e e4-8b 4f 00 f8 06 44 00 02  TScreen..O...D..
00a8e926  54 53 63 72 65 65 6e 40-24 62 63 74 72 24 71 71  TScreen@$bctr$qq
00a8ea80  54 53 63 72 65 65 6e 40-24 62 64 74 72 24 71 71  TScreen@$bdtr$qq
00a8ea9f  54 53 63 72 65 65 6e 40-47 65 74 48 65 69 67 68  TScreen@GetHeigh
00a8eac2  54 53 63 72 65 65 6e 40-47 65 74 57 69 64 74 68  TScreen@GetWidth
00a8eae4  54 53 63 72 65 65 6e 40-47 65 74 44 65 73 6b 74  TScreen@GetDeskt
00a8eb0b  54 53 63 72 65 65 6e 40-47 65 74 44 65 73 6b 74  TScreen@GetDeskt
00a8eb33  54 53 63 72 65 65 6e 40-47 65 74 44 65 73 6b 74  TScreen@GetDeskt
00a8eb5d  54 53 63 72 65 65 6e 40-47 65 74 44 65 73 6b 74  TScreen@GetDeskt
00a8eb86  54 53 63 72 65 65 6e 40-47 65 74 4d 6f 6e 69 74  TScreen@GetMonit

00ada300  54 53 63 72 65 65 6e 40-43 6c 65 61 72 4d 6f 6e  TScreen@ClearMon
00ada32b  54 53 63 72 65 65 6e 40-47 65 74 4d 6f 6e 69 74  TScreen@GetMonit
00ada354  54 53 63 72 65 65 6e 40-47 65 74 50 72 69 6d 61  TScreen@GetPrima

Whoa, that’s a lot of data. Looking at the results though, there are two distinct ranges of memory: 004F#### and 00A#####. Those in the 00A##### range are actually Delphi’s native debug symbols, mapped into memory. So I can ignore those. To keep myself sane, and make the debug console easier to review, I’ll rerun the search for a smaller range:

0:000> s -a 0400000 00a80000 "TScreen"
004f8f81  54 53 63 72 65 65 6e 36-00 90 5b 50 00 06 43 72  TScreen6..[P..Cr
004f9302  54 53 63 72 65 65 6e e4-8b 4f 00 f8 06 44 00 02  TScreen..O...D..

Now, these two references are close together, and I will tell you that the first one is the one we want. Generally speaking, the first one is in the class metadata, and the second one is not important today. Now that we have that "TScreen" string found in memory, we need to go back 1 byte. Why? Because "TScreen" is a Delphi ShortString, which is a string up to 255 bytes long, implemented as a length:byte followed by data (ANSI chars). And then we search for a pointer to that memory location with the s -d command:

0:000> s -d 0400000 00a80000 004f8f80
004f8bac  004f8f80 000000bc 0043ff28 00404ff4  ..O.....(.C..O@.

Only one reference, nearby in memory, which is expected — the class metadata is generally stored nearby the class implementation. Now this is where it gets a little brain-bending. This pointer is stored in Delphi’s class metadata, as I said. But most this metadata is actually stored in memory before the class itself. Looking at System.pas, in Delphi XE2 we have the following metadata for x86:

  vmtSelfPtr           = -88;
  vmtIntfTable         = -84;
  vmtAutoTable         = -80;
  vmtInitTable         = -76;
  vmtTypeInfo          = -72;
  vmtFieldTable        = -68;
  vmtMethodTable       = -64;
  vmtDynamicTable      = -60;
  vmtClassName         = -56;
  vmtInstanceSize      = -52;
  vmtParent            = -48;
  vmtEquals            = -44 deprecated 'Use VMTOFFSET in asm code';
  vmtGetHashCode       = -40 deprecated 'Use VMTOFFSET in asm code';
  vmtToString          = -36 deprecated 'Use VMTOFFSET in asm code';
  vmtSafeCallException = -32 deprecated 'Use VMTOFFSET in asm code';
  vmtAfterConstruction = -28 deprecated 'Use VMTOFFSET in asm code';
  vmtBeforeDestruction = -24 deprecated 'Use VMTOFFSET in asm code';
  vmtDispatch          = -20 deprecated 'Use VMTOFFSET in asm code';
  vmtDefaultHandler    = -16 deprecated 'Use VMTOFFSET in asm code';
  vmtNewInstance       = -12 deprecated 'Use VMTOFFSET in asm code';
  vmtFreeInstance      = -8 deprecated 'Use VMTOFFSET in asm code';
  vmtDestroy           = -4 deprecated 'Use VMTOFFSET in asm code';

Ignore that deprecated noise — it’s the constants that we want to know about. So the vmtClassName is at offset -56 (-38 hex). In other words, to find the class itself, we need to look 56 bytes ahead of the address of that pointer that we just found. That is, 004f8bac + 38h = 004f8be4. Now, if I use the dds (display words and symbols) command, we can see pointers to the implementation of each of the class’s member functions:

0:000> dds 004f8bac + 38
004f8be4  00445574 SpelunkSample!System.Classes.TPersistent.AssignTo
004f8be8  004515f8 SpelunkSample!System.Classes.TComponent.DefineProperties
004f8bec  004454a4 SpelunkSample!System.Classes.TPersistent.Assign
004f8bf0  004516f0 SpelunkSample!System.Classes.TComponent.Loaded
004f8bf4  00451598 SpelunkSample!System.Classes.TComponent.Notification
004f8bf8  00451700 SpelunkSample!System.Classes.TComponent.ReadState
004f8bfc  004520ac SpelunkSample!System.Classes.TComponent.CanObserve
004f8c00  004520b0 SpelunkSample!System.Classes.TComponent.ObserverAdded
004f8c04  00451f24 SpelunkSample!System.Classes.TComponent.GetObservers
004f8c08  00451b48 SpelunkSample!System.Classes.TComponent.SetName
004f8c0c  00452194 SpelunkSample!System.Classes.TComponent.UpdateRegistry
004f8c10  00451710 SpelunkSample!System.Classes.TComponent.ValidateRename
004f8c14  00451708 SpelunkSample!System.Classes.TComponent.WriteState
004f8c18  0045219c SpelunkSample!System.Classes.TComponent.QueryInterface
004f8c1c  00505b90 SpelunkSample!Vcl.Forms.TScreen.Create
004f8c20  00452070 SpelunkSample!System.Classes.TComponent.UpdateAction
004f8c24  0000000e
004f8c28  00010000
004f8c2c  12880000
004f8c30  00400040 SpelunkSample+0x40
004f8c34  00000000
004f8c38  00000000
004f8c3c  1800001d
004f8c40  3800439d
004f8c44  06000000
004f8c48  6e6f4646
004f8c4c  00027374
004f8c50  439d1800
004f8c54  00003c00
004f8c58  49460500
004f8c5c  0273656d
004f8c60  12880000

Huh. That’s interesting, but it’s a sidetrack; we can see TScreen.Create which suggests we are looking at the right thing. There’s a whole lot more buried in there but it’s not for this post. Let’s go back to where we were.

How do we take that class address and find instances of the class? I’m sure you can see where we are going. But here’s where things change slightly: we are looking in allocated memory now, not just the process image. So our search has to broaden. Rather than go into the complexities of memory allocation, I’m going to go brute force and look across a much larger range of memory, using the L? search parameter (which allows us to search more than 256MB of data at once):

0:000> s -d 00400000 L?F000000 004f8be4
004f8b8c  004f8be4 00000000 00000000 004f8c24  ..O.........$.O.
0247b370  004f8be4 00000000 00000000 00000000  ..O.............

Only two references. Why two and not one, given that we know that TScreen is a singleton? Well, because Delphi helpfully defines a vmtSelf metadata member, at offset -88 (and if we do the math, we see that 004f8be4 - 004f8b8c = 58h = 88d). So let’s look at the second one. That’s our TScreen instance in memory.

In this case, there was only one instance. But you can sometimes pickup objects that have been freed but where the memory has not been reused. There’s no hard and fast way (that I am aware of) of identifying these cases — but using the second method of finding a Delphi object, described below, can help to differentiate.

I’ll come back to how we use this object memory shortly. But first, here’s another way of getting to the same address.

Finding a Delphi object by variable or reference

As we don’t have full debug symbol information at this time, it can be difficult to find variables in memory. For global variables, however, we know that the location is fixed at compile time, and so we can use the disassembler in WinDbg to locate the address relatively simply. First, look in the source for a reference to the Screen global variable. I’ve found it in the FindGlobalComponent function (ironically, that function is doing programatically what we are doing via the long and labourious manual method):

function FindGlobalComponent(const Name: string): TComponent;
var
  I: Integer;
begin
  for I := 0 to Screen.FormCount - 1 do
  begin
    ...

So, disassemble the first few lines of the function. Depending on the conversion tool you used, the symbol format may vary (x spelunksample!*substring* can help in finding symbols).

0:000> u SpelunkSample!Vcl.Forms.FindGlobalComponent
SpelunkSample!Vcl.Forms.FindGlobalComponent:
004fcda8 53              push    ebx
004fcda9 56              push    esi
004fcdaa 57              push    edi
004fcdab 55              push    ebp
004fcdac 8be8            mov     ebp,eax
004fcdae a100435200      mov     eax,dword ptr [SpelunkSample!Spelunksample.initialization+0xb1ac (00524300)]
004fcdb3 e81c910000      call    SpelunkSample!Vcl.Forms.TScreen.GetFormCount (00505ed4)
004fcdb8 8bf0            mov     esi,eax

The highlighted address there corresponds to the Screen variable. The initialization+0xb1ac rubbish suggests missing symbol information, because (a) it doesn’t make much sense to be pointing to the “initialization” code, and (b) the offset is so large. And in fact, that is the case, we don’t have symbols for global variables at this time (one day).

But because we know this, we also know that 00524300 is the address of the Screen variable. The variable, which is a pointer, not the object itself! But because it’s a pointer, it’s easy to get to what it’s pointing to!

0:000> dd 00524300 L1
00524300  0247b370

Look familiar? Yep, it’s the same address as we found the RTTI way, and somewhat more quickly too. But now on to finding the list of forms!

Examining object members

Let’s dump that TScreen instance out and annotate its members. The symbols below I’ve manually added to the data, by looking at the implementation of TComponent and TScreen. I’ve also deleted some misleading annotations that Windbg added.

0:000> dds poi(00524300)
0247b370  004f8be4 TScreen
0247b374  00000000 TComponent.FOwner
0247b378  00000000 TComponent.FName
0247b37c  00000000 TComponent.FTag
0247b380  00000000 TComponent.FComponents
0247b384  00000000 TComponent.FFreeNotifies
0247b388  00000000 TComponent.FDesignInfo
0247b38c  00000000 TComponent.FComponentState
0247b390  00000000 TComponent.FVCLComObject
0247b394  00000000 TComponent.FObservers
0247b398  00000001 TComponent.FComponentStyle
0247b39c  00000000 TComponent.FSortedComponents
0247b3a0  0043fec8 
0247b3a4  0043fed8 
0247b3a8  00000000 TScreen.FFonts
0247b3ac  024b4e10 TScreen.FImes
0247b3b0  00000000 TScreen.FDefaultIme
0247b3b4  04090c09 TScreen.FDefaultKbLayout
0247b3b8  00000060 TScreen.FPixelsPerInch
0247b3bc  00000000 TScreen.FCursor
0247b3c0  00000000 TScreen.FCursorCount
0247b3c4  02489da8 TScreen.FForms
0247b3c8  02489dc0 ...

How did I map that? It’s not that hard — just look at the class definitions in the Delphi source. You do need to watch out for two things: packing, and padding. x86 processors expect variables to be aligned on a boundary of their size, so a 4 byte DWORD will be aligned on a 4 byte boundary. Conversely, a boolean only takes a byte of memory, and multiple booleans can be packed into a single DWORD. Delphi does not do any ‘intelligent’ reordering of object members (which makes life a lot simpler), so this means we can just map pretty much one-to-one. The TComponent object has the following member variables (TPersistent and TObject don’t have any member variables):

  TComponent = class(TPersistent, IInterface, IInterfaceComponentReference)
  private
    FOwner: TComponent;
    FName: TComponentName;
    FTag: NativeInt;
    FComponents: TList;
    FFreeNotifies: TList;
    FDesignInfo: Longint;
    FComponentState: TComponentState;
    FVCLComObject: Pointer;
    FObservers: TObservers;
    ...
    FComponentStyle: TComponentStyle;
    ...
    FSortedComponents: TList;

And TScreen has the following (we’re only interested in the members up to and including FForms):

  TScreen = class(TComponent)
  private
    FFonts: TStrings;
    FImes: TStrings;
    FDefaultIme: string;
    FDefaultKbLayout: HKL;
    FPixelsPerInch: Integer;
    FCursor: TCursor;
    FCursorCount: Integer;
    FForms: TList;
    ...

Let’s look at 02489da8, the FForms TList object. The first member variable of TList is FList: TPointerList. Knowing what we do about the object structure, we can:

0:000>dd 02489da8 L4
02489da8  004369e8 02482da8 00000001 00000004

It can be helpful to do a sanity check here and make sure that we haven’t gone down the wrong rabbit hole. Let’s check that this is actually a TList (poi deferences a pointer, but you should be able to figure the rest out given the discussion above):

0:000> da poi(004369e8-38)+1
00436b19  "TList'"

And yes, it is a TList, so we haven’t dereferenced the wrong pointer. All too easy to do in the dark cave that is assembly-language debugging. Back to the lead. We can see from the definition of TList:

  TList = class(TObject)
  private
    FList: TPointerList;
    FCount: Integer;
    FCapacity: Integer;
    ...

That we have a pointer to 02482da8 which is our list of form pointers, and a count of 00000001 form. Sounds good. Take a quick peek at that form:

0:000> dd poi(02482da8) L1
02444320  005112b4
0:000> da poi(poi(poi(02482da8))-38)+1
0051148e  "TSpelunkSampleForm."

Yes, it’s our form! But what is with that poi poi poi? Well, I could have dug down each layer one step at a time, but this is a shortcut, in one swell foop dereferencing the variable, first to the object, then dereferencing to the class, then back 38h bytes and dereferencing to the class name, and plus one byte for that ShortString hiccup. Saves time, and once familiar you can turn it into a WinDbg macro. But it’s helpful to be familiar with the structure first!

Your challenge

Your challenge now is to list each of the TMyObject instances currently allocated. I’ve added a little spice: one of them has been freed but some of the data may still be in the dump. So you may find it is not enough to just use RTTI to find the data — recall that the search may find false positives and freed instances. You should find that searching for RTTI and also disassembling functions that refer to member variables in the form are useful. Good luck!

Hint: If you are struggling to find member variable offsets to find the list, the following three lines of code from FormCreate may help (edx ends up pointing to the form instance):

0051168f e87438efff      call    SpelunkSample!System.TObject.Create (00404f08)
00511694 8b55fc          mov     edx,dword ptr [ebp-4]
00511697 898294030000    mov     dword ptr [edx+394h],eax

Rant: Why can’t Microsoft provide actually useful titles on their updates?

Windows Updates have improved dramatically over the last few years.  With Windows 7, the integrated updates install smoothly and without much fuss (apart from the occasional EULA or Internet Explorer Upgrade to throw a spanner in the works).

There’s just one thing.  In general, the update titles are useless.  Completely useless. “Security Update for Windows 7”? Why else would I be running Windows Update?

update-2

Furthermore, the detailed description is also useless — it doesn’t actually provide any details!  It’s even more ambiguous than the title! “A security issue has been identified in a Microsoft software product that could affect your system.”

update-1

Let’s look at what’s wrong with “Update for Windows 7 for x64-based Systems (KB2830477)”:

  • It doesn’t tell us what the update actually provides
  • We already know it’s for Windows 7 — that’s in the group title.
  • We don’t need to know it’s for x64-based Systems — Windows Update won’t serve us updates for the wrong system type

We couldn’t we see “Update for RemoteApp and Desktop Connections features is available for Windows (KB2830477)”, instead? So which sleeve did I pull that descriptive and useful title from?

Well, the thing is, Microsoft already do know exactly what the update is providing.  They have even taken the time to write a succinct title for the update: it’s the title of the Knowledge Base article associated with the update, and it’s even linked to from the update. For example, instead of “Update for Windows 7 (KB2852386)”, we could have “Update: Disk Cleanup Wizard addon lets users delete outdated Windows updates on Windows 7 SP1 (KB2852386)”

Now it’s even worse when using WSUS — you now have to trawl through hundreds of nearly identically titled updates, with only a KB article number to differentiate.  So easy to accidentally approve the wrong update.  Why, Microsoft, why?  Is it so you don’t scare consumers who don’t understand what the update provides?  They just press the big “Automatic Updates” button anyway!

update-4

Admittedly, Microsoft have taken a big step in the right direction with Visual Studio updates: the description for Visual Studio updates generally gives you some information about what is being updated:

update-3

But even that could be improved. We’ve got a lot of repeated information: “Visual Studio 2010” is referenced 4 times: in the group title, in the update title, in the update title in the preview pane, and in the description of the update, again in the preview pane! Surely we don’t need to know that 4 times! And why don’t we go with a title of “Update fixes coded UI test issues for Visual Studio 2010 SP1 in IE9 or IE10 when KB 2870699 is installed (KB2890573)”. Sure it’s a little bit long, but it’s better than “Update for Microsoft Visual Studio 2010 Service Pack 1 (KB2890573)”.

So in conclusion, may I ask you, Microsoft, please, fix these update titles? Just start giving us titles that mean something? And if you are feeling particularly generous, you could even update the description of the update to add more meaning, not less!

The farce of security challenge questions (yes, ANZ, I’m talking about you!)

My bank has decided that I have to have some security challenge questions, and gave me a fixed set of questions to add answers to.

They had some simple instructions: “Keep them secret and don’t disclose them to anyone.  Don’t write down or record them anywhere.”  And added a little threat as icing on the cake: “If you don’t follow these instructions, you may be liable for any loss arising from an unauthorised transaction.”

Security Questions 1 Security Questions 2 Security Questions 3If I actually attempt to give honest answers to the questions, any determined and reasonably intelligent hacker could find the answers to all the questions that I actually know the answer to, within a minute or two, online, tops.

So what if I opt to use 1-Password or another password management tool to generate secure and random “password” style answers to these questions?  These would not be readily memorisable and so I’d have to save them in the tool.  But according to their little threat, I can’t do that!  That’s called recording the answers to the questions and I could be liable if an unauthorised transfer occurs.

The real problem with questions like this is that too much of this information is recorded online, already.  It adds a layer of complexity to the security model, without actually improving security much, if at all.

Then another question arises.  If an acquaintance does happen to ask me where I got married, am I now liable to ANZ if I tell them?  It sounds ridiculous but lawyers be lawyers.  Mind you, given that I have no way of not agreeing to the terms, perhaps it’s unenforceable.  The whole thing is really badly thought out.

Update 9:46am: Blizzard and insecurity questions: My father’s middle name is vR2Ut1VNj is a really good read for more detail!

Hobart 10,000 Day 1, 2013 Report

8am at sea level we gathered, 11 riders in all.  The hills loomed above us, but we were not daunted.  Climb them we would, and nothing would stop us.  And when we had climbed them, we would descend to the depths of the valleys, and again we would ascend their lofty heights.

‘Twas a pleasant dream.  And yet we prevailed.  Eight and nine tenths of us completed the course, a 2600m extravaganza of climbing following a tortuous and tangled route around the foothills of Mount Wellington.  One tenth of a rider?  Well, Dan descended the mountain in the support vehicle.  But he did complete all the climbing that was on the menu.  The other Dan pled broken ribs in his early abandon.  And one other rider — his name now lost to my ken — pled afternoon criterium.

Our organisers had fled.  Barry had a touch of the man flu.  And Mark seemed to think it would be more fun to play with awesome slag-destroying remote control robots!

Mark's Slag Destroying Robot
Mark’s Slag Destroying Robot

But we knew we could make it on our own.

The full route, annotated

IMG_5641

The morning started with a warm up on Napoleon St.

Napoleon St, 100m @ 16.1%. So short Mesmeride has trouble drawing it!

Then Lynton Ave.

Lynton Ave, 200m @ 12.5%

And Washington St.

Washington St. 400m @ 11.7%. But what a finish!
Washington St
Washington St

Followed closely by Hillborough Rd.

Hillborough Rd, 700m @ 13.6%

Lots of steep climbs.  Even Sam was forced to swap into the little ring on some of those hills.  After Hillborough Dan farewelled us, as we made our way to Waterworks, and then huffed and puffed our way to the top.

Waterworks, 1200m @ 11.8%

IMG_9239

A welcome break was had there, as our intrepid and trusty support driver Stephen awaited with food and drink.  Made the day so much better!

Back down the hill.  A good sensible gradient this time, Huon Rd.

Huon Rd, 4.5km @ 6%

But back to the silly climbs with Old Farm Rd shortly thereafter!

Old Farm Rd, 1.8km @ 8.9%

That was the last of the crazy short steep climbs.  Now we just had 2 climbs left: Strickland and Longley – Wellington.

IMG_9293

Strickland we cruised, slightly quicker than I thought we would be able to.

Strickland, 3.0km @ 5.6%

But when we arrived at Longley, another rider noticed that I had broken a spoke on my rear wheel.  Yay!  A quick text message to our support driver, and he turned up within mere seconds, we had the wheel swapped out and ready to ride in moments.  So it seemed.

Longley Wheel Replacement
Longley Wheel Replacement

Up and up again!  Longley – Neika.  Neika – Fern Tree turnoff.

Neika, 5.6km @ 5.2%

And Fern Tree to the summit of Mt Wellington.  At this point, my legs were telling me ‘enough’!  I dropped back from the front group, and found a more comfortable pace with Chris, and we made our way to the top at a much more survivable pace.  Kudos to all the riders — Tim, Piers, Sam, and others — who finished with PRs up the final climb!

Mt Wellington, 11.2km @ 7.2%

IMG_9300

The weather was good, still but not hot.  Cloudy, just a fraction too cold on the descents, but not overly unpleasant.  The company was excellent!  Our support driver was great, and appreciated by all!

Sam did climb Wellington in the Big Ring. Kudos!

IMG_9340

And the hills?  Well, I was not quite defeated but I was surely sore at the end.  My Wellington time was certainly not impressive, and while my heart and lungs were ready to give, my legs were not! And the next morning I could barely move, groaning my way out of bed and around the house.  The forecast rain, sleet, hail and wind, together with my evident lack of form, were enough motive for me to pull out of day 2 🙁  I hope they had a good day!

Updated 5 Nov 2013: Photos added to the story. Full set of photos by our support driver Stephen are now available on Flickr

Delphi’s TJSONString.ToString is broken, and how to fix it

As per several QC reports, Data.DBXJSON.TJSONString.ToString is still very broken. Which means, for all intents and purposes, TJSONAnything.ToString is also broken. Fortunately, you can just use TJSONAnything.ToBytes for a happy JSON outcome.

The following function will take any Delphi JSON object and convert it to a string:

function JSONToString(obj: TJSONAncestor): string;
var
  bytes: TBytes;
  len: Integer;
begin
  SetLength(bytes, obj.EstimatedByteSize);
  len := obj.ToBytes(bytes, 0);
  Result := TEncoding.ANSI.GetString(bytes, 0, len);
end;

Because TJSONString.ToBytes escapes all characters outside U+0020-U+007F, we can assume that the end result is 7-bit clean, so we can use TEncoding.ANSI.  You could instead stream the TBytes to a file or do other groovy things with it.

Debugging a stalled Delphi process with Windbg and memory searches

Today I’ve got a process on my machine that is supposed to be exiting, but it has hung. Let’s load it up in Windbg and find what’s up. The program in question was built in Delphi XE2, and symbols were generated by our internal tds2dbg tool (but there are other tools online which create similar .dbg files). As usual, I am writing this up for my own benefit as much as anyone else’s, but if I put it on my blog, it forces me to put in enough detail that even I can understand it when I come back to it!

Looking at the main thread, we can see unit finalizations are currently being called, but the specific unit finalization section and functions which are being called are not immediately visible in the call stack, between InterlockedCompareExchange and FinalizeUnits:

0:000> kb
ChildEBP RetAddr  Args to Child              
0018ff3c 0040908c 0018ff78 0040909a 0018ff5c audit4_patient!System.Sysutils.InterlockedCompareExchange+0x5 [C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\source\rtl\sys\InterlockedAPIs.inc @ 23]
0018ff5c 004094b2 0018ff88 00000000 00000000 audit4_patient!System.FinalizeUnits+0x40 [C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\source\rtl\sys\System.pas @ 17473]
0018ff88 74b7336a 7efde000 0018ffd4 76f99f72 audit4_patient!System..Halt0+0xa2 [C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\source\rtl\sys\System.pas @ 18599]
0018ff94 76f99f72 7efde000 35648d3c 00000000 kernel32!BaseThreadInitThunk+0xe
0018ffd4 76f99f45 01a5216c 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 01a5216c 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b

So, the simplest way to find out where we were was to step out of the InterlockedCompareExchange call. I found myself in System.SysUtils.DoneMonitorSupport (specifically, the CleanEventList subprocedure):

0:000> p
eax=01a8ee70 ebx=01a8ee70 ecx=01a8ee70 edx=00000001 esi=00000020 edi=01a26e80
eip=0042dcb1 esp=0018ff20 ebp=0018ff3c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200202
audit4_patient!CleanEventList+0xd:
0042dcb1 33c9            xor     ecx,ecx

After a little more spelunking, and a review of the Delphi source around this function, I found that this was a part of the System.TMonitor support. Specifically, there was a locked TMonitor somewhere that had not been destroyed. I stepped through a loop that was spinning, waiting for the object to be unlocked so its handle could be destroyed, and found a reference to the data in question here:

0:000> p
eax=00000001 ebx=01a8ee70 ecx=01a8ee70 edx=00000001 esi=00000020 edi=01a26e80
eip=0042dcaf esp=0018ff20 ebp=0018ff3c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200202
audit4_patient!CleanEventList+0xb:
0042dcaf 8bc3            mov     eax,ebx

Looking at the record pointed to by ebx, we had a reference to an event handle handy:

0:000> dd ebx L2
01a8ee70  00000001 00000928

  TSyncEventItem = record
    Lock: Integer;
    Event: Pointer;
  end;

Although Event is a Pointer, internally it’s just cast from an event handle. So I guess that we can probably find another reference to that handle somewhere in memory, corresponding to a TMonitor record:

  TMonitor = record
  strict private
    // ... snip ...
    var
      FLockCount: Integer;
      FRecursionCount: Integer;
      FOwningThread: TThreadID;
      FLockEvent: Pointer;
      FSpinCount: Integer;
      FWaitQueue: PWaitingThread;
      FQueueLock: TSpinLock;

And if we search for that event handle:

0:000> s -[w]d 00400000 L?F000000 00000928
01a8ee74  00000928 00000000 0000092c 00000000  (.......,.......
07649334  00000928 002c0127 0012ccb6 0000002e  (...'.,.........
0764aa14  00000928 01200125 004b8472 000037ce  (...%. .r.K..7..
07651e24  00000928 05f60125 01101abc 00000e86  (...%...........
08a47544  00000928 00000000 00000000 00000000  (...............

Now one of these should correspond to a TMonitor record. The first entry (01a8ee74) is just part of our TSyncEventItem record, and the next three don’t make sense given that the FSpinCount (the next value in the memory dump) would be invalid. So let’s look at the last one. Counting quickly on all my fingers and toes, I establish that that makes 08a47538 the start of the TMonitor record. And… so we search for a pointer to that.

0:000> s -[w]d 00400000 L?F5687000 08a47538
076b1d24  08a47538 08aa3e40 076b1db1 0122fe50  8u..@>....k.P.".

Just one! But here it gets a little tricky, because the PMonitor pointer is in a ‘hidden’ field at the end of the object. So we need to locate the start of the object.

0:000> dd 076b1d00
076b1d00  0122fe50 00000000 00000000 076b1df1
076b1d10  0122fe50 00000000 00000000 076b0ce0
076b1d20  004015c8 08a47538 08aa3e40 076b1db1
076b1d30  0122fe50 00000000 00000000 076b1d51
... snip ...

I’m just stabbing in the dark here, but that 004015c8 that’s just four bytes back smells suspiciously like an object class pointer. Let’s see:

0:000> da poi(4015c8-38)+1
004016d7  "TObject&"

Ta da! That all fits. A TObject has no data members, so the next 4 bytes should be the TMonitor (search for hfMonitorOffset in the Delphi source to learn more). So we have a TObject being used as a TMonitor lock reference. (Learn about that poi(address-38)+1 magic). But what other naughty object is hanging about, using this TObject as its lock?

0:000> s -[w]d 00400000 L?F5687000 076b1d20
098194b0  076b1d20 00000000 00000000 09819449   .k.........I...

Just one. Let’s trawl back in memory just a little bit and have a look at this one.

0:000> dd 09819480  
09819480  00f0f0f0 00ffffff 00000000 09819641
09819490  00447b7c 00000000 00000000 00000000
098194a0  00000000 098150c0 00448338 098195c8
098194b0  076b1d20 00000000 00000000 09819449
... snip ...

0:000> da poi(00448338-38)+1
004483c0  "TThreadList&"

And what does a TThreadList look like?

  TThreadList = class
  private
    FList: TList;
    FLock: TObject;
    FDuplicates: TDuplicates;

Yes, that definitely looks hopeful! That FLock is pointing to our lock TObject… I believe that’s called a Quality Match.

This is still a little bit too generic for me, though. TThreadList is a standard Delphi class used by the bucketload. Let’s try and identify who is using this list and leaving it lying about. First, we’ll quickly have a look at that TThreadList.FList to see if it has anything of interest — that’s the first data member in the object == object+4.

0:000> dd poi(098194ac)
098195c8  00447b7c 00000000 00000000 00000000
... snip ...
0:000> da poi(447b7c-38)+1
00447cad  "TList'"

Yep, it’s a TList. Just making sure. It’s empty, what a shame (TList.FCount is the second data member in the object == 00000000, as is the list pointer itself).

So how else can we find the usage of that TThreadList? Is it TThreadList referenced anywhere then? Break out the search tool again!

0:000> s -[w]d 00400000 L?F5687000 098194a8
076d3410  098194a8 00000000 09819580 00000000  ................

Yes. Just once, again. Again, we scroll back in memory to find the base of that object.

0:000> dd 076d33c0  
076d33c0  08abfe60 00000000 00000000 076d4c39
076d33d0  01616964 0000091c 00001850 00000100
076d33e0  00000001 00000000 00000000 00000000
076d33f0  076d33d0 00000000 01616d38 076d33d0
076d3400  00000000 00000000 00000000 00000000
076d3410  098194a8 00000000 09819580 00000000
076d3420  00000000 076d2ea9 0075e518 00000000
076d3430  00401ecc 00000000 00000000 00000000

There was a false positive at 076d33f8, but then magic happened at 076d33d0:

0:000> da poi(01616964-38)+1
016169e8  "TAnatomyDiagramTileLoaderThread&"

Wow! Something real! Let’s dissect this a bit. Looking at the definition of TThread, we have the following data:

076d33d0  01616964  class pointer TAnatomyDiagramTileLoaderThread
076d33d4  0000091c  TThread.FHandle
076d33d8  00001850  TThread.FThreadID
076d33dc  00000100  TThread.FCreateSuspended, .FTerminated, .FSuspended, .FFreeOnTerminate (watch that endianness!)
076d33e0  00000001  TThread.FFinished
076d33e4  00000000  TThread.FReturnValue
076d33e8  00000000  TThread.FOnTerminate.Code
076d33ec  00000000  TThread.FOnTerminate.Data
076d33f0  076d33d0  TThread.FSynchronize.TThread (= Self)
076d33f4  00000000  padding
076d33f8  01616d38  TThread.FSynchronize.FMethod.Code (= last Synchronize target method)
076d33fc  076d33d0  TThread.FSynchronize.FMethod.Data (= Self)
076d3400  00000000  TThread.FSynchronize.FProcedure
076d3404  00000000  TThread.FSynchronize.FProcedure
076d3408  00000000  TThread.FFatalException
076d340c  00000000  TThread.FExternalThread

Then, into TAnatomyDiagramTileLoaderThread:

076d3410  098194a8  TAnatomyDiagramTileLoaderThread.FTiles: TThreadList

So… we can tell that the thread has exited (FFinished == 1), and verify that by looking at running threads, looking for thread id 1850:

0:000> ~
.  0  Id: 1c98.1408 Suspend: 1 Teb: 7efdd000 Unfrozen
   1  Id: 1c98.16c8 Suspend: 1 Teb: 7efda000 Unfrozen
   2  Id: 1c98.11a0 Suspend: 1 Teb: 7ee1c000 Unfrozen
   3  Id: 1c98.1bbc Suspend: 1 Teb: 7ee19000 Unfrozen
   4  Id: 1c98.10dc Suspend: 1 Teb: 7ee04000 Unfrozen
   5  Id: 1c98.12f0 Suspend: 1 Teb: 7edfb000 Unfrozen
   6  Id: 1c98.1d38 Suspend: 1 Teb: 7efaf000 Unfrozen
   7  Id: 1c98.1770 Suspend: 1 Teb: 7edec000 Unfrozen
   8  Id: 1c98.1044 Suspend: 1 Teb: 7ede3000 Unfrozen
   9  Id: 1c98.bf4 Suspend: 1 Teb: 7ede0000 Unfrozen
  10  Id: 1c98.b3c Suspend: 1 Teb: 7efd7000 Unfrozen

Furthermore, the handle is invalid:

0:000> !handle 91c
Could not duplicate handle 91c, error 6

That suggests that the object has already been destroyed. But that the TThreadList hasn’t.

And sure enough, when I looked at the destructor for TAnatomyDiagramTileLoadThread, we clear the TThreadList, but we never free it!

Now, another way we could have caught this was to turn on leak detection. But leak detection is not always perfect, especially when you get some libraries that *cough* have a lot of false positives. And of course while we could have switched on heap leak detection, that involves rebuilding and restarting the process and losing the context along the way, with no guarantee we’ll be able to reproduce it again!

While this approach does feel a little tedious, and we did have some luck in this instance with freed objects not being overwritten, and the values we were searching for being relatively unique, it does nevertheless feel pretty deterministic, which must be better than the old “try-it-and-hope” debugging technique.