Nat!'s Web Journal: December 2009 Archives

SSD Fight: Samsung PM 800 256 GB vs Intel X-25M Postville

I am using the first version of the Intel X-25M in my MacBook and I am very happy with it. So now its time to upgrade the desktops. Since some time has passed since I bought my first SSD there are now actually alternatives to the X-25M on the market. The Samsung PM 800 seems to have the X-25M beat in every benchmark I have seen, except one, and that was random 4K block read/writes. In that benchmark the IBM was about 10 times faster than the Samsung.

IBM SSD

My suspicion was, that this particular benchmark would be of great importance, to my foremost interest, when it comes to disk speed, which is compiling. Unfortunately this aspect is rarely benchmarked. So here goes. So I ordered both and tried them in my MacBook.

	Samsung	Intel X-25M Postville	Intel X-25M (Generation 1)
GB/€	0,50	0,42	-
SL Installation time (min)	27	31	-
Xcode Installation time (m:s)	6:21	6:21	-
Build time (m:s)	2:40	2:42	2:41

What I did was I put each SSD into my MacBook, partioned it to one partition and installed Snow Leopard 10.6 from DVD on it. I measured how many minutes that took. Than I installed Xcode and checked the installer log for the time elapsed. Finally I used xcodebuild to built a decently sized software package. The I did a clean and then I measured it with time xcodebuild.

Samsung SSD

Conclusion: In my tests on the white MacBook there is no big difference between both SSDs, but the Samsung seems to be the all around better pick on first look. The Intel is going into my Windows system and the Samsung will go into my G5.

An advantage the IBM package has, it comes with a 2.5" to 3.5" adaptor.

Posted by Nat! on December 10, 2009 8:44 PM | Permalink | Comments (0)

How to move an Impulse account to another machine without knowing your password or email address

What if you lost your password to Impulse and what if you gave Impulse a fake email address during registration. Who could be so stupid ? But hypothetically... what could you do, if you wanted to migrate to another machine ?

Use regedit.exe, locate \HKEY_CURRENT_USER\Software\Stardock and export this folder onto a USB stick or some such.

On the new machine just doubleclick on the created registry export file and ignore the warnings.

It worked for me.

Posted by Nat! on December 11, 2009 6:09 PM | Permalink | Comments (0)

My best bug ever

This is obscure, but who said programming is always easy. Maybe more on this later, if I know whats going on. This is the disassembled code for -value:

0x35204c8a  <+0000>  push   %ebp
0x35204c8b  <+0001>  mov    %esp,%ebp
0x35204c8d  <+0003>  sub    $0x8,%esp
0x35204c90  <+0006>  mov    0x8(%ebp),%eax
0x35204c93  <+0009>  mov    0xc(%eax),%eax
0x35204c96  <+0012>  leave  
0x35204c97  <+0013>  ret

and this is -key:

0x35204ea6  <+0000>  push   %ebp
0x35204ea7  <+0001>  mov    %esp,%ebp
0x35204ea9  <+0003>  sub    $0x8,%esp
0x35204eac  <+0006>  mov    0x8(%ebp),%eax
0x35204eaf  <+0009>  mov    0x8(%eax),%eax
0x35204eb2  <+0012>  leave  
0x35204eb3  <+0013>  ret

I hightlighted the only difference in the assembly code between the two functions.

Stepping through the code, with the same object

There are breakpoints on 0x35204c90 and 0x35204eac -value works as expected but -key doesn't

(gdb) stepi
(gdb) p/x $eax
$16 = 0x30de9f0
(gdb) x/4 $eax
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0
(gdb) x/x $eip
0x35204c93 <-[xxx value]+9>:	0xc90c408b
(gdb) stepi
(gdb) p/x $eax
$17 = 0xd7dfa0
(gdb) c
Continuing.
(gdb) stepi
(gdb) p/x $eax
$18 = 0x30de9f0
(gdb) x/4x 0x30de9f0
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0
(gdb) x/x $eip
0x35204eaf <-[xxx key]+9>:	0xc908408b
(gdb) stepi
(gdb) p/x $eax
$19 = 0x20454c4c
(gdb) set $eip = 0x35204eaf
(gdb) set $eax = 0x30de9f0
(gdb) stepi
(gdb) p/x $eax
$20 = 0x20454c4c
(gdb) set $eip = 0x35204c93
(gdb) set $eax = 0x30de9f0
(gdb) stepi
(gdb) p/x $eax
$21 = 0xd7dfa0
(gdb) 
(gdb) x/4x 0x30de9f0
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0

There is nothing ommitted, there is no other thread of mine running. 0xc908408b in Visual Studio is also mov eax,dword ptr [eax+8].

Posted by Nat! on December 17, 2009 5:38 PM | Permalink | Comments (0)

Fishing for clues for "my best bug ever"

(gdb) x/128x 0x30de800
0x30de800: 0x508152eb 0x50899500 0x50899b14 0x508152de
0x30de810: 0x50898e84 0x50899b14 0x508152d1 0x5089caa9
0x30de820: 0x508986b8 0x50815269 0x508983f2 0x508986b8
0x30de830: 0x5081520b 0x55105c35 0x50899b14 0x508151fe
0x30de840: 0x508a46aa 0x508986b8 0x5081510f 0x00095555
0x30de850: 0x00d0dff0 0x010011c0 0x00000009 0x00000000
0x30de860: 0x00000004 0x00020000 0xa0912ba4 0x00000000
0x30de870: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de880: 0x00d0dff0 0x01001180 0x00000009 0x00000000
0x30de890: 0x00000004 0x00030000 0xa0912ba4 0x00000000
0x30de8a0: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de8b0: 0x00d609f0 0x00000009 0x03078710 0x15627a70
0x30de8c0: 0x00000001 0x030dfc30 0x00000000 0x00000000
0x30de8d0: 0x04a24dc0 0x00000002 0x00000014 0x00000019
0x30de8e0: 0x030decf0 0x00000000 0x00000000 0x00000000
0x30de8f0: 0x04a24a20 0x00000000 0x00000000 0x03240960
0x30de900: 0x030dea70 0x00000000 0x00000000 0x00000000
0x30de910: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de920: 0x00d0a590 0x01001384 0x00000083 0x00000083
0x30de930: 0x00000000 0x030de940 0x00000000 0x00000000
0x30de940: 0x454c4553 0x75205443 0x45422e30 0x5a54554e
0x30de950: 0x535f5245 0x4b454c45 0x4e4f4954 0x3075202c
0x30de960: 0x4d414e2e 0x75202c45 0x44492e30 0x53555a5f
0x30de970: 0x444e4154 0x3075202c 0x5f44492e 0x5453414d
0x30de980: 0x535f5245 0x4b454c45 0x4e4f4954 0x3075202c
0x30de990: 0x414c4b2e 0x2c455353 0x2e307520 0x5245554b
0x30de9a0: 0x2c4c455a 0x2e307520 0x4d4d554e 0x46205245
0x30de9b0: 0x204d4f52 0x5f544448 0x45424154 0x20454c4c
0x30de9c0: 0x00003075 0x00000000 0x00000000 0x00000000
0x30de9d0: 0x00d01af0 0x352f00d8 0x500afa60 0x00000000
0x30de9e0: 0x00000000 0x00000000 0x00000000 0x00000000
0x30de9f0: 0x35231f20 0x925c93a8 0x04a053c0 0x00d7dfa0

and

(gdb) set $eax = 0x30de9f4
(gdb) set $eip = 0x35204eaf
(gdb) stepi
(gdb) p/x $eax
$22 = 0x3075
(gdb) set $eax = 0x30de9ec
(gdb) set $eip = 0x35204eaf
(gdb) stepi
(gdb) p/x $eax
$23 = 0x45424154
(gdb)

hmm significant, I would say. It should be noted, that the address of the executable code and the memory address is somewhere in the middle of what I would expect a VM page to be, since these are supposed to be divisible by 4K as far as I know.

(gdb) x/64x 0x10000
0x10000: 0xffffff4c 0x8bb0148b 0xffff108d 0x18858bff
0x10010: 0xe8ffffff 0x00076f07 0x2785c646 0x01ffffff
0x10020: 0x858b0ceb 0xffffff10 0x0a74c085 0xb539f631
0x10030: 0xffffff50 0x858bc87f 0xffffff4c 0xe8240489
0x10040: 0x0011c3b6 0xff1c958b 0x9589ffff 0xffffff30
0x10050: 0xff2885c7 0x0000ffff 0x85c60000 0xffffff2f
0x10060: 0x1f8b8d00 0x890012c7 0xffff0c8d 0x7d838dff
0x10070: 0x8900120e 0xffff0885 0x83938dff 0x8900120e
0x10080: 0xffff0495 0x898b8dff 0x8900120e 0xffff008d
0x10090: 0x60858dff 0x89ffffff 0xfffefc85 0x8f938dff
0x100a0: 0x8900120e 0xfffef895 0x5c8d8dff 0x89ffffff
0x100b0: 0xfffef48d 0x0288e9ff 0x858b0000 0xffffff30
0x100c0: 0x00587880 0x0268840f 0xc0830000 0x20858948
0x100d0: 0xb9ffffff 0x00000007 0x0cb58bfc 0x89ffffff
0x100e0: 0xb8a6f3c7 0x00000000 0xb60f0a74 0xb60fff46
0x100f0: 0xc829ff4f 0x1d75c085 0x850c458b 0x2f840fc0
(gdb) set $eax = 0x100f0
(gdb) set $eip = 0x35204eaf
(gdb) stepi
(gdb) p/x $eax
$26 = 0xffffff30
(gdb) set $eax = 0x100f0
(gdb) set $eip = 0x35204c93
(gdb) stepi
(gdb) p/x $eax
$27 = 0x2f840fc0
(gdb) x/i 0x35204c93
0x35204c93 <-[xxx value]+9>:	mov    0xc(%eax),%eax
(gdb) x/i 0x35204eaf
0x35204eaf <-[xxx key]+9>:	mov    0x8(%eax),%eax
(gdb)

Just checking stuff with a different memory address and double checking the assembly code.

Try a different class in a different project with the same layout:

0x00001f0f  <+0006>  push   %ebp
0x00001f10  <+0007>  mov    %esp,%ebp
0x00001f12  <+0009>  sub    $0x8,%esp
0x00001f15  <+0012>  mov    0x8(%ebp),%eax
0x00001f18  <+0015>  mov    0x8(%eax),%eax
0x00001f1b  <+0018>  leave  
0x00001f1c  <+0019>  ret 
(gdb) stepi
(gdb) p/x $eax
$2 = 0x403f20
(gdb) x/4x $eax
0x403f20: 0x00003030 0x924e24f8 0x00002024 0x00002034
(gdb) stepi
(gdb) p/x $eax
$4 = 0x2024
(gdb)

Posted by Nat! on December 17, 2009 9:51 PM | Permalink | Comments (0)

Some more fishing around the evil elves conspiracy

I wrote another shorter program, that just did the same piece of code at the same place. To write this was harder than expected (see this cry for help) for some more details or check out the gruesome project SimpleBestBugVerify.

In any case, as was sort of expected, the bug doesn't manifest itself there at all.

Unfortunately I can't reproduce the bug in the original code currently, because as fate has it, the certificate for the VPN that carries the database connection just expired and now it's christmas and the guy responsible for it (Hey Oli! ;)) might not be able to fix it so quickly.

It's like evil elves are conspiring against me, but I am used to that.

Posted by Nat! on December 20, 2009 10:02 PM | Permalink | Comments (0)

The idiocy of too strong typing

While perusing the Xcode Users mailing list archives I found this beauty:

I'd like to write a quick function template to change a function pointer from type " return_type (*)(void) " to "return_type (*)(...)". I thought this would work:

template <typename RetT>
RetT (*convert_ptr(...)) ( RetT (*src)(void) ) { 
   typedef RetT (*rt)(...); 
  return reinterpret_cast(src); 
  //ERROR: "src" was not declared in this scope.
}

The whole code functionally is a big bag of nothing. It's all syntax. Spending time programming this stuff is about as worthwhile as reformatting TPS reports.

The C-solution is (or should be, if it hasn't been broken by some committee by now) convert_ptr = (void *) src , which means: I know what I am doing, don't bother me even with warnings, I have better things to do.

Posted by Nat! on December 22, 2009 6:15 PM | Permalink | Comments (0)

The plot thickens in the fight vs. the bug elves

The VPN is up again and I rearranged the code a little, and now I get a EXC_BAD_ACCESS in a completely different place:

0x35204e9f  <+0042>  mov    (%eax),%eax
0x35204ea1  <+0044>  mov    %eax,0x4(%esp)
0x35204ea5  <+0048>  mov    %edx,(%esp)
0x35204ea8  <+0051>  call   0x35236170 <dyld_stub_objc_msgSendSuper>
0x35204ead  <+0056>  lea    0x2c2a1(%ebx),%eax
0x35204eb3  <+0062>  mov    (%eax),%eax
0x35204eb5  <+0064>  cmp    %eax,0x14(%ebp)

compared to the original troublesome code

0x35204ea6  <+0000>  push   %ebp
0x35204ea7  <+0001>  mov    %esp,%ebp
0x35204ea9  <+0003>  sub    $0x8,%esp
0x35204eac  <+0006>  mov    0x8(%ebp),%eax
0x35204eaf  <+0009>  mov    0x8(%eax),%eax
0x35204eb2  <+0012>  leave  
0x35204eb3  <+0013>  ret

Is it really a different place ? Actually in terms of adresses it's almost but not quite identical. Yes that still makes no sense whatsoever to me.

More fishing around

Dump of the shared library binary at the appropriate place. (I have put in four nops 0x90, so I can easily identify it. (It stlll EXC_BAD_ACCESS crashes with the four nops)

00004ea0: 0489 1424 e8c7 1203 0090 9090 908d 83a5  ...$............
00004eb0: c202 008b 0039 4514 7411 8d83 a1c2 0200  .....9E.t.......
00004ec0: 8b00 3945 140f 85ff 0000 0083 7d18 000f  ..9E........}...

It's interesting to note, that the offset into the linker file, is the same as the offset into a virtual memory page. And here's the same memory seen by gdb post EXC_BAD_ACCESS crash:

0x35204ea0: 0x8904 0x2414 0xc7e8 0x0312 0x9000 0x9090 0x8d90 0xa583
0x35204eb0: 0x02c2 0x8b00 0x3900 0x1445 0x1174 0x838d 0xc2a1 0x0002
0x35204ec0: 0x008b 0x4539 0x0f14 0xff85 0x0000 0x8300 0x187d 0x0f00

One dump was made by emacs and the other with gdb and the endianness is different, but the instructions are identical.

One more nop and the crash is gone

So this is currently the code that gives the EXC_BAD_ACCESS at 0x35204eb3

0x35204ea9  <+0056>  nop    
0x35204eaa  <+0057>  nop    
0x35204eab  <+0058>  nop    
0x35204eac  <+0059>  nop    
0x35204ead  <+0060>  lea    0x2c2a5(%ebx),%eax
0x35204eb3  <+0066>  mov    (%eax),%eax
0x35204eb5  <+0068>  cmp    %eax,0x14(%ebp)

but if I put another nop there the crash is gone. Unfortunately as you can see, there is also a subtle shift of the code involved, which is due to the linker, which is out of my control (see: previous entry).

0x35204ea5  <+0056>  nop    
0x35204ea6  <+0057>  nop    
0x35204ea7  <+0058>  nop    
0x35204ea8  <+0059>  nop    
0x35204ea9  <+0060>  nop    
0x35204eaa  <+0061>  lea    0x2c2a9(%ebx),%eax
0x35204eb0  <+0067>  mov    (%eax),%eax
0x35204eb2  <+0069>  cmp    %eax,0x14(%ebp)

Posted by Nat! on December 22, 2009 9:46 PM | Permalink | Comments (0)

Nat! vs. evil code elves: Final fishings before christmas

Moving the framework to different start addresses:

Start Address	Result
0x34200000	no crash
0x00f50000	no crash
0x35210000	no crash
0x35200000	crash
0x75200000	no crash

So it it crashes with 0x35200000, well that I already did know.

Isolating the bug

I was able to isolate the bug eventually into a much much smaller project. Strangely enough, if I put the code into a .dylib then there is no problem, but if I use a .framework it crashes or fails. If I had tried a framework two days ago instead of a dylib, it would have saved me quite a bit of headache. Also I know now, that AppKit doesn't need to be present. A Foundation tool shows the same problem.

The same code does not crash on another computer.

Hilarious! After three days I know now much more about the bug, still, it seems to make no sense whatsoever. On a hunch I would say this has something to do with virtualization on the CPU in some way. It will be interesting to figure out, how to debug that.

As this is the last entry before christmas. Happy Christmas and New Years. More to come next year, if I don't die of old age in the mean time.

Final Note

I gave up on this. I assume this to have been a freak hardware problem.

Posted by Nat! on December 23, 2009 12:41 AM | Permalink | Comments (0)

Nat!'s Web Journal

December 2009 Archives

December 10, 2009

SSD Fight: Samsung PM 800 256 GB vs Intel X-25M Postville

December 11, 2009

How to move an Impulse account to another machine without knowing your password or email address

December 17, 2009

My best bug ever

Stepping through the code, with the same object

Fishing for clues for "my best bug ever"

December 20, 2009

Some more fishing around the evil elves conspiracy

December 22, 2009