Who halted the code
Today a bed time story involving un-initialized variable access and a weird coincidence.
Couple of weeks back I was kind of baffled with a weird issue I was facing with the .NET Compact Framework Jitter. We were making the Jitter work for Symbian OS (S60) emulator. The S60 emulator is a Windows process and hence we needed to bring up the i386 Jitter in our code base. After running some JITted code the application would stop executing with the message "Execution halted" in the stack trace.
Now obviously the user didn't halt anything and the program was a simple hello world.
After some debugging I found an interesting thing. For the debug build the Symbian C compiler memsets un-initialized variables to 0xcccc. This is fairly standard and is used to catch un-initialized variable access.
However, our Jit code had a bug such that in some scenario it was not emitting function call/returns correctly. So instead of returning we were executing arbitrary memory. But instead of some sort of access violation (or some thing equally bad) the execution was actually halting.
The reason was we started executing un-initialized data. Now this data is 0xcccc. The S60 debugger uses interrupt 3 (INT 3) for inserting breakpoints and the following line reveals the rest of the story
For i386 the instruction used for inserting breakpoint and the pattern used for un-initialized data matched and the debugger thought that it hit a breakpoint.
Comments
Anonymous
October 20, 2008
Are you guys going to release .NET Compact Framework for Symbian? It will really be very nice especially for Middle East market where Symbian is dominant mobile OS and its very hard to convince end users to switch their device for the app...Anonymous
October 20, 2008
we are not going to release .NET Compact per se. We are releasing Silver Light for Nokia S60 devices. Since Silver Light comes with a variant of .NET so yes. See press release http://www.nokia.com/A4136001?newsid=1197788Anonymous
October 22, 2008
A few years ago, when Internet Explorer crashed, Windows offered to start up Visual Studio to debug it instead of sending a dump to Microsoft. Of course I couldn't debug Internet Explorer, but just for the sake of curiosity, a few times I let Windows start up Visual Studio. I was mystified as to why Internet Explorer had breakpoint instructions compiled into it. Now I understand, it was probably executing uninitialized data, not compiled instructions. Maybe I had a lucky "break" instead of executing someone's exploit.