Bad code

- (void) syncInsideWithEvent:(NSEvent *) event { NSPoint point; unsigned int i; point = [self convertPoint:[event locationInWindow] fromView:nil]; for( i = 0; i < N_AREAS; i++) inside_[ i] = NSPointInRect( point, area_[ i]); [self setNeedsDisplay:YES]; } - (void) mouseEntered:(NSEvent *) event { [self syncInsideWithEvent:event]; } - (void) mouseExited:(NSEvent *) event { [self syncInsideWithEvent:event]; }

Better code

- (void) syncInsideWithEvent:(NSEvent *) event invert:(BOOL) invert { NSTrackingArea *hit; NSTrackingArea *area; unsigned int i; hit = [event trackingArea]; for( i = 0; i < N_AREAS; i++) { area = [[self trackingAreas] objectAtIndex:i]; inside_[ i] = (area == hit) ^ invert; } [self setNeedsDisplay:YES]; } - (void) mouseEntered:(NSEvent *) event { [self syncInsideWithEvent:event invert:NO]; } - (void) mouseExited:(NSEvent *) event { [self syncInsideWithEvent:event invert:YES]; }

Here are the releasenotes of the unpublished versions.

Version 2.12

1. Changed hash algorithm of mulleSybaseRowDictionary optimization done in 2.7 for even better performance

Version 2.11

1. Reverted a supposedly harmless change in datetime handling since there were troubles in GMT apparently.

Version 2.10

1. Use slower but more compatible code to produce the inital SELECT statement for text/image writes
2. Experimental fix for writetext, when size is evenly divisible by 512

Version 2.9

1. I am really pedantic on +formatValue not being nil. It shouldn't happen when using MulleEOF and you should be passing in [EONull null] anyway
2. Removed a leak involving error messages
3. Fixed a special Sybase type handling of LONGCHAR types
4. Avoided a leak when returning factory produced values

Version 2.8

1. You may pass in "nil" as a value for -[EOAdaptor fetchedValueForValue:attribute:]
2. Finally in version 2.8 "expressionClass" will not be overridden, but "defaultExpressionClass", which is correct.
3. If an image attibute has value null, the adaptor will not write a serialized [EONull null] into the DB.
4. Image/text is written with a simpler qualifier, that is just qualifying the primary key.
5. -[MulleSybaseSQLExpression primaryKeyConstraintStatementsForEntityGroup]produces proper SQL code now
6. Versioning information should be correct (thx to patrick@onestep.co.uk for noting that).
7. Fixed Void and In/out parameters sql generation to produce syntactically correct SQL
8. JDBC compatibility port number hack
9. Fixed creation of primary key constraints generation (or rather their declaration, the statement issued is not a true constraint, which I might fix with MulleEOF 2.0)
10. If _debug flag is set, the adaptor now writes the number of bytes read (along with the SQL) in completeFetch

With no clue in the console log and no stack trace (see picture) I was stumped.

Obviously the crash occurs at 0x986ceed7, where you see the red instruction pointer arrow.

Recovering the Stacktrace

Move the instruction pointer to a ret instruction. In the screenshot the address of a known ret instruction is marked green. If you see a different hexadecimal number in your disassembly there, by all means use that. Now go into the gdb debugger console to recover the stack trace:

(gdb) set $eip = 0x986cef35
(gdb) stepi
(gdb) where
#0  0x00000000 in ?? ()
#1  0x9842e5a4 in _NSDescriptionWithLocaleFunc ()
#2  0x92b04322 in _CFStringAppendFormatAndArgumentsAux ()
#3  0x92b036a9 in _CFStringCreateWithFormatAndArgumentsAux ()
#4  0x92babf2e in _CFLogvEx ()
#5  0x984bf7e8 in NSLogv ()
#6  0x984bf757 in NSLog ()
...

Voilà! Or Viola as it's commonly misspelled. ]]> http://www.mulle-kybernetik.com/weblog/2010/07/exc_bad_access_and_no_stack_tr.html http://www.mulle-kybernetik.com/weblog/2010/07/exc_bad_access_and_no_stack_tr.html Wed, 14 Jul 2010 17:25:20 +0100 those guitar videos here is an Xcode Project, that crashes in the Xcode debugger but not stand alone. I bet you can't debug that!

The expected output of the debugger is:

Running...
memory_pressure: 0memory_pressure: 02010-07-13 21:51:44.114 MoreTroubleInXcode[13281:a0f] I don't blame you.
Program received signal: "SIGABRT".
sharedlibrary apply-load-rules all
Cannot access memory at address 0x0
Cannot access memory at address 0x0
(gdb)

]]>http://www.mulle-kybernetik.com/weblog/2010/07/betcha_cant_debug_that.htmlhttp://www.mulle-kybernetik.com/weblog/2010/07/betcha_cant_debug_that.htmlTue, 13 Jul 2010 20:43:10 +0100

MoreTroubleInXcode.zip

(In Xcode use the "Run" menu, choose "Run with Performance Tool" and select "Leaks"). What this project is doing, is overloading a category in Foundation with a method, that is itself stored in a Framework. In a condensed form it looks like this.

SomethingBadHappened.zip

// defined in a framework @implementation NSObject( NSUnpublishedEOFDebug) - (void) addObject:(id) obj toBothSidesOfRelationshipWithKey:(NSString *) key { NSLog( @"%@ %s: %@ %@", self, __PRETTY_FUNCTION__, obj, key); NSLog( @"Denied!"); } @end

// defined in a tool, linking to the framework int main (int argc, const char * argv[]) { [@"foo" addObject:@"bar" toBothSidesOfRelationshipWithKey:@"baz"]; }

Normal run
+[NSObject( NSUnpublishedEOFDebug) load] foo -[NSObject(NSUnpublishedEOFDebug) addObject:toBothSidesOfRelationshipWithKey:]: bar baz Denied!

Instruments run

+[NSObject( NSUnpublishedEOFDebug) load] *** WARNING: -[NSObject(NSKeyValueCoding) takeValue:forKey:] is deprecated. It will be removed in a future release and should no longer be used. *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<NSCFString 0x2024> takeValue:forKey:]: attempt to assign value to unknown key: 'baz'. This class does not have an instance variable of the name baz or _baz, nor a method of the name setBaz, or _setBaz' *** Call stack at first throw: ( 0 CoreFoundation 0x9440abba __raiseError + 410 1 libobjc.A.dylib 0x94f4d509 objc_exception_throw + 56 2 CoreFoundation 0x944559f1 -[NSException raise] + 17 3 Foundation 0x9833a179 _raiseKeyValueException + 234 4 SomethingBadHappened 0x00001ef7 main + 125 5 SomethingBadHappened 0x00001e71 start + 53 ) <End of Run>

Some Thoughts

• Does not crash with Shark
• Yes, Foundation still has some old EOF methods contained in a category called NSUnpublishedEOF.
• If the category is not part of the test framework, but part of the tool. There is no such problem.
• Since, the test framework is dependent on Foundation, Foundation must be loaded first.
• It's as if by a accident Foundation was loaded again, and it's categories override the test framework categories.

So here are the results of two experiments. I wrote some code, that measured the number of releases on NSObject based objects. I then dropped that into the Apple developer examples Sketch and TextEdit. I ran both for a short while I did some manipulations like loading files, editing, copy/pasting et.c and then on Quit, my code collected and printed the statistics data.

Sketch	TextEdit
Download Sketch.txt	Download TextEdit.txt
total object count = 26065 1 14016 0.537733 2 9598 0.368233 3 1090 0.041819 4 412 0.015807 5 145 0.005563 6 46 0.001765 7 67 0.002570 8 44 0.001688 9 236 0.009054 10 36 0.001381	total object count = 13652 1 7056 0,516847 2 4420 0,323762 3 1033 0,075667 4 241 0,017653 5 167 0,012233 6 11 0,000806 7 128 0,009376 8 62 0,004541 9 165 0,012086 10 38 0,002783

So for example for Sketch, there were 1090 objects that got 3 releases before they dealloced. (This implies they were retained twice). So because 26065 objects existed during this run of Sketch, the probability that an object would die with 3 releases is 0.041819.

What it means

Let's redo the math for Sketch, with the new numbers, collapsing the releases from 6 to the maximum release count into 6 to keep it simple and recognizable:

# releases (n)	percentage	factor
1	53%	0.53
2	37%	0.37
3	4%	0.04
4	2%	0.02
5	1%	0.01
6	3%	0.03

= factor( n) * tM * n = 0.53 * 1 + 0.37 * 2 + 0.04 * 3 + 0.02 * 4 + 0.01 * 5 + 0.03 * 6 = 0.53 + 0.74 + 0.12 + 0.08 + 0.05 + 0.18 = 1.7

= factor( n) * (tS * n + tM * (n - 1)) = factor( n) * (4/3 * n - 1) = 0.53*0.33+0.37*1.66+0.04*3+0.02*4.33+0.01*5.66+0.03*7 = 0.17 + 0.61 + 0.12 + 0.087 + 0.057 + 0.21 = 1,25

Final Words

Looking at the original "old" code, what is underlayed with the bluish tint, is the actual "algorithmic" part. Let's call this part M for multithreaded and lets name the time spent executing this part of the method tM.

- (void) release
{
   if( MulleAtomicDecrement( &refCountMinusOne_) == -1) // M
      [self dealloc];
}

- (void) release
{
   if( ! refCountMinusOne_)  // S 
   {
      [self dealloc];
      return;
   }

   if( MulleAtomicDecrement( &refCountMinusOne_) == -1) // M
      [self dealloc];
}

Simple Functions

This shall constitute the lifetime of the object and it's lifetime is measured in releases (or n). Therefore the lifetime of this object is 1. In this case the "old" code spends tM time and the "new" code tS time.

If on the other hand the object had been retained and released once in between (p = [[Foo new] retain]; [p release]; [p release]), there are now two releases. The lifetime for this instance is therefore 2 and the "old" code spends tM + tM, whereas the "new" code spends tS + tM + tS. Continuing this sequence we get the following table for a few retain/release cycles

# releases (n)	old	new
1	tM	tS
2	tM + tM	tS + tS + tM
3	tM + tM + tM	tS + tS + tM + tS + tM
4	tM + tM + tM + tM	tS + tS + tM + tS + tM + tS + tM

It should be easy to see, that this can be generalized to (shortening number of releases to n):

old( n) = tM * n

new( n) = tS * n + tM * (n - 1)

With a little further math, we can put tS and tM as well as n into relation.

old( n) = new( n)
tM * n = tS * n + tM * (n - 1)
tM * n = tS * n + tM * n - tM
    0 = tS * n - tM
    tM = tS * n
    tS = tM / n
     n = tM / tS

Probabilities

# releases (n)	percentage	factor
1	20%	0.2
2	25%	0.25
3	20%	0.2
4	20%	0.2
5	10%	0.1
6	5%	0.05

Then the average time spent for "old" will work out to,

sum_old( 1, n) := factor( n) * old( n)

Assuming 1 for tM, then this would work out to

factor( n) * old( n) = factor( n) * tM * n = factor( n) * 1 * n = factor( n) * n = 0.2 * 1 + 0.25 * 2 + 0.2 * 3 + 0.2 * 4 + 0.1 * 5 + 0.05 * 6 = 0.2 + 0.5 + 0.6 + 0.8 + 0.5 + 0.30 = 2.9

The average time spent on "new" is likewise

sum_new( 1, n) := factor( n) * new( n)

factor( n) * new( n) = factor( n) * (tS * n + tM * (n - 1)) = factor( n) * (1/3 tM * n + tM * (n - 1)) = factor( n) * tM (1/3 * n + (n - 1)) = factor( n) * tM ( 4/3 n - 1) = factor( n) * (4/3 * n - 1) = 0.2*0.33+0.25*1.66+0.2*3+0.2*4.33+0.10*5.66+0.05*7 = 0.067 + 0.417 + 0.6 + 0.867 + 0.567 + 0.35 = 2.55

What to take home

Stuff to do

• find out the release statistics for a common Cocoa application
• measure tM and tS for MulleAtomic

Stuff to remember

• the possible change of tM by the preceeding execution of tS is reflected only in tS for simplicity

Atomic Increment and Decrement

Luckily the -retain and -release only needs to increment and decrement a variable safely. An increment or decrement is just such a read, modify, write operation that is a perfect match for an atomic operation.

- (id) retain
{
   MulleAtomicIncrement( &refCountMinusOne_);
   return( self);
}


- (void) release
{
   if( MulleAtomicDecrement( &refCountMinusOne_) == -1)
      [self dealloc];
}

So let me show the code first and then explain it. While -retain's implementation stays as is, release is changed to:

- (void) release
{
   if( ! refCountMinusOne_)  // single-threaded and done ?
   {
      [self dealloc];
      return;
   }

   // still multi-threaded, so do it safely
   if( MulleAtomicDecrement( &refCountMinusOne_) == -1)
      [self dealloc];
}

The first question of course would be "is this threadsafe ?". Assuming that a read to refCountMinusOne_ is atomic, whenever another thread holds claim to the object, the value of referenceCountMinusOne_ must be 1 or larger, since the currently executing thread also holds claim to at least one reference. Reading a 0 (an actual reference count of 1) in -release implies that the object is owned now solely by a single thread (the current thread).

The second question is, "why would this be better ?". That's something that needs to be tested on the given hardware, but my perception on atomic operations is, that they usually cause inter-CPU communication and synchronization overhead. Something that I expect to become of worse effect as core numbers increase. At least in my old article, there was a non-negligable difference.
Avoiding atomic operations should therefore be a win.

So here's a scenario where this could be useful: Assume you have a subclass of NSArray, say MulleMutableArray, which allows you to initialize it with objects that are already retained, say -initWithRetainedObjects:count:. Now fill this array with objects, that have been created with +new. If you then release this array, all its items will be sent a -release message and you would never have executed an atomic instruction.
This could also be useful for objects, that are immediately added to NSAutoreleasePools having never be retained.

Negative aspects

• could fail on hardware, where int reads are non-atomic, like f.e. old 68000 multi-CPU (ha!) hardware - if I remember - where the databus was 16 bit and int size was 32 bit.
• will slow down "normal" code, that retains/releases. But on the bright side refCountMinusOne_ will be in the cache then pretty much guaranteed
• it's only a statistical advantage for certain scenarios

Was am Ende doch mal wieder erstaunlich kompliziert war, war die Anpassung der Farbe. Ausgedruckt habe ich letztlich auf EPSON Photo Quality Glossy Paper (S041126) - hatte ich noch von meinem Tintendruckertagen übrig - was nochmal einen ganz anderen Farbton produziert als normales Papier. Das krasseste jedoch war, wie sich die Farben durch Export und Import ändern. Im Original Graffle File (Colorsync ausgeschaltet) hat das Grün einen HSV Wert von 157/42/77. Im exportierten PDF ist es dann 158/29/73. Woran das jetzt liegt ?

Und mit dem Colorswatch von Apple hatte ich auch diverse Probleme. Letztendlich liegt alles wohl daran, daß manche Farben gerätabhängig und manche gerätunabhängig sind und die Programme sich damit gegenseitig verwirren. Das ist leider den Farben aber nicht anzusehen. So war das ganze mit viel Fummelei verbunden.

Zu guter letzt die Dateien. Wenn's geht lieber aus dem OmniGraffle ausdrucken und die Druckoptionen beachten. Mit dem OKI C5600 und dem EPSON Papier wird es (IMO) perfekt: MulleWhiteWaterSchilder.zip ]]> http://www.mulle-kybernetik.com/weblog/2010/04/schilder_fr_die_plastikberge_d.html http://www.mulle-kybernetik.com/weblog/2010/04/schilder_fr_die_plastikberge_d.html Sun, 18 Apr 2010 12:11:52 +0100 As soon as it was available in Germany I bought a Sheeva Plug Computer (ca. EUR 100) and a 1 TB Imation external USB disk (ca. EUR 100). My plan was to use this a fileserver, mainly as a DAAP iTunes Music server.

The Imation disk is great. It's covered with an absorber material, and I only hear it when I put my ear on it. It's also supposed to use very little energy.
The Sheeva Plug is not so great. The USB connections have too little friction, so it is extremely easy to lose the connection. I already had to format the USB disk twice, because it became unusable, when the USB cabled didn't connect properly any more... Also I think, it could be a little smaller. It's quite a beefy plug.

There are a lot of guides out there, that cover what to do with the Sheeva, once you get it. For a fileserver like mine, you only need three packages: avahi-daemon for Zeroconf, mt-daapd for Daap/iTunes and samba for filesharing. I also wanted netatalk for completeness sake.

I just want to write down a few notes, that I didn't see covered elsewhere on the web. There are a lot of good guides out there.

• netatalk - gave me some weird address family errors, but when I turned off the ATALKD daemon and just use AFPD daemon (see /etc/defult/netatalk/. It worked OK. I don't really use AFP now, I use samba, it seems so much faster.
• hostname - append a .local to the name you come up with. Zeroconf will then be able to properly resolve it.
• fstab - try to replace as much as possible of the /var hierarchy with tmpfs mounts. You will lose persistent logs, but that should reduce writes to the flash memory of the plug.

1. Edited /etc/fstab to read rootfs / rootfs ro 00 instead of rootfs / rootfs rw 0 0, hoping that this would just work
2. Rebooted
3. Checked with mount that it worked, it didn't (rootfs on / type rootfs (rw))
4. Decided to revert /etc/fstab to avoid confusion later in life
5. Noticed about three times in a row that saving the changed file didn't work.
6. Examined fstab file permissions and my user id (root)
7. Failed to see any reason, why it shouldn't work.
8. Abandoned this problem and tried to figure out some other aesthetic problem in the boot process
9. Figured out that I needed strings for that
10. Tried apt-get install strings, knowing that it wouldn't work, which it didn't. Dimly rememberd something about "bin-utils"...
11. Gave up on this, but noticed a warning that apt-get gave about not being able to use a read-only /var/lib/dpkg/lock.
12. Figured, that probably /var/lib/dpkg was missing and needed creation
13. Noticed, that this wasn't the case.
14. Experienced a rare moment, that I wouldn't call lucid, but nevertheless ... The root filesystem was indeed mounted read only, and mount had lied to me!
15. Moaned as I realized, that to install anything on the root file system I had to edit fstab and reboot. But everything on the root file system is read only now.
16. Dealt with the pain, by writing this blog entry
17. Rememberd the remount option mount -o remount,rw / ;)

( for i in `find /Developer/SDKs/MacOSX10.4u.sdk/ -name "*.h" -print` ; do file=`basename $i`; echo "$file" "$i"; done | awk '{ files[ $1] = $2 } END { for ( x in files) print files[ x] }' | xargs egrep -H "AVAILABLE_MAC_OS_X_VERSION_10_._AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_." ) | egrep -v "#define|#ifdef|#ifndef|\ \*\ .*AVA" | sed 's/.*\(AVAILABLE_.*_10_.\).*/\1/' | sort | uniq -c | sed 's/AVAILABLE_MAC_OS_X_VERSION_10_\(.*\)_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_\(.*\)/\1 \2/'

which exposes that the JavaVM.framework is apparently broken in the 10.6 SDK, but who uses Java anyway ;)
egrep: /Developer/SDKs/MacOSX10.6.sdk//System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jvmdi.h: No such file or directory
egrep: /Developer/SDKs/MacOSX10.6.sdk//System/Library/Frameworks/JavaVM.framework/Versions/A/Headers/jvmpi.h: No such file or directory

Anway here are the results:

How to read this chart. On the left side is the released version. The bars show the number of symbols deprecated of previous OS X versions. So for example the top entry 10.1, shows that it deprecates less than 10 function from 10.0. Then 10.3 deprecates a few symbols from 10.0 and 10.2 and so on. Further interpretation of the data is left to the reader.

What is kind of interesting is to compare the raw numbers for the various SDKs. I checked 10.4.u.sdk, 10.5.sdk and 10.6.sdk. The horizontal axis has the version that deprecates, the vertical axis has the version that suffers deprecation:

10.4u.sdk 10.1 10.2 10.3 10.4 10.5 10.6 10.0 2 5 31 1119 82 10.1 1 3 24 10.2 20 10.3 12 10.4 10.5	10.5.sdk 10.1 10.2 10.3 10.4 10.5 10.6 10.0 2 6 38 1107 682 10.1 1 37 37 10.2 9 22 19 10.3 14 32 10.4 7 10.5
10.6.sdk 10.1 10.2 10.3 10.4 10.5 10.6 10.0 2 5 37 1082 640 97 10.1 1 18 3 2 10.2 9 21 12 3 10.3 18 19 106 10.4 7 13 10.5 8

Some quick observations:

• 10.4u.sdk seems to be broken, as it has deprecations from 10.5 already
• since deprecations seem to disappear over time, this could mean, that either symbols were really removed, or that some symbols were wrongly deprecated

The methodology used here isn't perfect, because I am not checking all headers. But I hate scrapping the whole entry ;)

]]> http://www.mulle-kybernetik.com/weblog/2010/01/deprecation_deprecation_deprec_1.html http://www.mulle-kybernetik.com/weblog/2010/01/deprecation_deprecation_deprec_1.html Wed, 06 Jan 2010 18:39:51 +0100 foo.m:17: warning: 'NSLookupSymbolInImage' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/usr/include/mach-o/dyld.h:182) When I look into the header I find this:

/*
 * The following dyld API's are deprecated as of Mac OS X 10.5.  They are either  
 * no longer necessary or are superceeded by dlopen and friends in .
 * dlopen/dlsym/dlclose have been available since Mac OS X 10.3 and work with 
 * dylibs and bundles.  
 *
 *    NSAddImage                           -> dlopen
 *    NSLookupSymbolInImage                -> dlsym
 *    NSCreateObjectFileImageFromFile      -> dlopen
 *    NSDestroyObjectFileImage             -> dlclose
 *    NSLinkModule                         -> not needed when dlopen used
 *    NSUnLinkModule                       -> not needed when dlclose used
 *    NSLookupSymbolInModule               -> dlsym
 *    _dyld_image_containing_address       -> dladdr
 *    NSLinkEditError                      -> dlerror
 *
 */

extern NSSymbol NSLookupSymbolInModule(NSModule module, const char* symbolName)
AVAILABLE_MAC_OS_X_VERSION_10_1_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5;

What bothers me, that one of the ideas behind Foundation is, that it should isolate me from the OS layer and abstract to a common denominator, that remains stable. Yet here, the Foundation functions are deprecated and I am suposed to use dyld directly, although Foundation still could (and probably does) do the work using dyld.

I don't get this. ]]> http://www.mulle-kybernetik.com/weblog/2010/01/deprecation_deprecation_deprec.html http://www.mulle-kybernetik.com/weblog/2010/01/deprecation_deprecation_deprec.html Wed, 06 Jan 2010 18:11:47 +0100 Start AddressResult 0x34200000no crash 0x00f50000no crash 0x35210000no crash 0x35200000crash 0x75200000no crash So it it crashes with 0x35200000, well that I already did know.

Isolating the bug

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

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    

More fishing around

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........}...

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 more nop and the crash is gone

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)

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)