Why is mysql_library_end() so slow?

Why is mysql_library_end() soooooo sloooooow?

Under certain conditions it seems mysql_library_end() takes about 5 seconds to complete. Under other scenarios it only takes milliseconds. The latter being the expected, in all honesty.

Why, you ask?

I cannot really tell you why because I haven't dug into the source, but in my case the root cause turned out to be missing call(s) to mysql_thread_end() prior to thread exit from every(!) thread that had initialized a MYSQL struct. Fix that, and v\oila, milliseconds execution from mysql_library_end().

Let's hear it for Recuva!

A friend of mine lost all his family recordings off his Sony HDD camera. Major crisis!

A quick probe resulted in estimates of up to 10K USD to recover the lost video commercially. A quick google search resulted in Recuva being a likely candidate for a fix. Luckily the owner kept his wits, did not take any additional video. 10 minutes later every video sequence was back on disk, and camera back with its (now) very happy owner :D

So, lets hear it for Recuva!

Empty SxS <assembly> tag from VS2008

Symptoms
VS2008 sometimes manages to embed empty manifest into the binaries it builds. Normally this will give you some (at first) strange SxS error when you attempt to run your newly built binary.

Investigation
Using mt.exe we can check out the embedded manifest in the binary

mt.exe -inputresource:myapp.exe -out:foo

Output
In the failing case resulting in this short blurp in foo:

<!--?xml version="1.0" encoding="UTF-8" standalone="yes"?-->

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestversion="1.0"></assembly>

Expected output
You would, however, expect the embedded manifest to look something like the following

<!--?xml version="1.0" encoding="UTF-8" standalone="yes"?-->

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestversion="1.0">

  <trustinfo xmlns="urn:schemas-microsoft-com:asm.v3">

    <security>

      <requestedprivileges>

        <requestedexecutionlevel level="asInvoker" uiaccess="false"></requestedexecutionlevel>

      </requestedprivileges>

    </security>

  </trustinfo>

  <dependency>

    <dependentassembly>

      <assemblyidentity type="win32" name="Microsoft.VC90.CRT" version="9.0.nnnnn.mmmmm" processorarchitecture="x86" publickeytoken="1fc8b3b9a1e18e3b"></assemblyidentity>

    </dependentassembly>

  </dependency>

</assembly>

Examination
This seems to happen only when building files on a networked drive (long story short - I need to). Typically this means your build folders will be on the same networked drive too. As a result, so will the myapp.embed.manifest file that we try to embed.

There's various reasons if you read around on the net, but it all relates to

1. Incremental linking
2. and a FAT32 optimization in VS2008 gone haywire
3. with BIND_TO_CURRENT_CRT
4. when project files are on a networked drive

I haven't investigated if not using BIND_TO_CURRENT_CRT makes a difference or not, but it might.

Options
There's a few options to avoid this, not all of which may be applicable nor desirable

1. Don't do incremental linking
Will only work for smaller projects.

2. Place cmake files on local disk
Might not be desirable, for various reasons. Dependencies to other projects would be one.

3. Manually embed the correct manifest
Having cmake do a POST_BUILD step, where it runs the cmake equivalent of

mt.exe -verbose  -manifest myapp.embed.manifest  -outputresource:myapp.exe

is really the only safe option IMHO.

So help VS2008 along the way and manually embed your manifest, and you hopefully won't be bothered by that SxS error again...

_access() doesn't work!?

HELP!

The _access() CRT call does not work on Windows - at least not in the way you'd expect coming from unix or linux. The underscored function found in the Windows C runtime library appears to be a Windows equivalent of the Posix function access() reading the MSDN docs.

But appearances can be deceiving.

The unix and linux variants will throw EACCES when accessing a directory/folder where you have no read access. The windows _access() does not. Help! In fact, _access() only proves usable for checking existence of a given path, and nothing else.

How, then, do you get a proper access() function on Windows? Turns out CreateFile() will do what we need:

DWORD dwAccess = GENERIC_READ; // or GENERIC_WRITE, or both |'d
hFile = CreateFile(fname,
              dwAccess,
             FILE_SHARE_READ|FILE_SHARE_WRITE,       // attempt to open with shared read/write access
             NULL,                                   // no security needed for probe
             OPEN_EXISTING,                          // check existing files and folders only
             FILE_ATTRIBUTE_NORMAL | FILE_FLAG_BACKUP_SEMANTICS,  //both needed for directory probe
             NULL);                                  // template file not needed for probe

if (hFile == INVALID_HANDLE_VALUE){
 // do whatever you need to handle EACCES
}
CloseHandle(hFile);
...

Hope this can save you a few cycles...

That dreaded cygwin "Device or Resource busy"...

If you've ever attempted to do any serious work on a Windows box configured with cygwin and a sshd, you've probably already come across the dreaded error message as you attempt to remove a file or folder

"Device or Resource busy"

If, not you probably will - sooner or later. You can't rm the files or folders, your compile is stuck as it can't write objs to disk - or whatever else your file access scenario may be.

SysInternals Handle to the rescue!

Handle will merrily show you what process is holding a handle to the specified file or folder. Once the perpetrator is located, taskkill /PID n, makes for the easy solution.

Simple, yet extremely effective trick for the toolbox...

(In all fairness, the latest 1.7.7 cygwin is a lot better than the previous versions :))

EMC2 on Ubuntu 10.04

A while back I upgraded my HobbyCNC controller laptop to the latest 2.4 release of EMC2 which now also comes with Ubuntu 10.04 on its LiveCD.

I did need a reinstall of the system, but its now smoother than ever. EMC2 on 10.04 is a true joy to work with. Added bonus is the modern operating system with no-hassle wifi for grabbing your NC files off the home wifi network while in the workshop. The LPT pcmcia card I use still works out of the box.

EMC is a definite two thumbs up in my book!

Who needs backup...?

Most Important Files (TM)
Like me, you likely have your Most Important Files (TM) backed up to a USB disk. I mean, just to be on the safe side. All the photos of the kids as they grow up, all those hobby related project files, and just about everything else you want kept safe. And you have that USB disk hooked up to your home network to boot. Neat.

Enter the brand spanking new laptop... Decrapify and dual, or rather multi, boot it. Move the most recent projects to the new SSD equipped iron wonder. I'll do the rest later.

... a year later
Yeah, right you will.

One day the missus goes "Honey, what's that sound?"
What sound? Oh... Err... No proble... Wait... Did I forge... NO!

My ext3 formatted WD 500Gb MyBook, hooked up to the Synology USBStation, had decided to take a walk down amnesia and bad sector lane. The MyBook was now officially a MyBrick. On the early side of MTBF for the MyBrick guts too, if I dare guess.

A quick peek at the WD community site wasn't getting my hopes up. People are obviously experiencing some real pain with the MyBooks in the end. Not surprisingly disks finally give in - and I was truly caught in the middle of such carnage.

Voiding the warranty
My disk spun up and then stopped at random times. Similar problems on the WD community site was tagged as the disk controller possibly overheating. Being November and -15C outside it was worth a try giving the disk a big chill. Disk good as dead already, after all. Voided the warranty, dismantled the disk from the MyBrick and put it in the open window to cool down.

Tried a couple of free Windows ext3 solutions without luck, and Solaris was (sadly) not playing nice either. Last resort would have been a disk-rescue company and 1000 EUR less in the bank.

Enter Ubuntu 10.04. As the disk spun up, it auto-mounted and contained folders magically appeared. For a very brief moment, at least. Then the disk shut itself down again.

Trail and (bad sector) error
But, new hope. Next disk boot I was able to drag a couple of folders across before the disk shut down again. It worked best if I kept the disk tempered at freezing point, 0C, on the window sill. Slightly tilted on its back, while standing on one foot, with ... You get the point. But it would still stop randomly as it encountered a multitude of different disk errors - all visible in the syslog.

Long story short, I had to reboot the disk some 60+ times to rescue the real important stuff. But I did manage to save my Most Important Files (TM). Merging and skipping files in half saved folders got it back piece by piece.

To RAID, or not to RAID
I actually survived my USB disk crash with my most precious files intact. Am I felling lucky - you bet!
Needless to say I now own a RAID capable NAS - and have backup of my NAS too. Still considering if my ISPs online secure vault service is worth its pricetag.

I'm not advocating you do the same to your crashed USB disk though - whatever make or model. Your problem could be something completely different.

Who needs backup...? I do!