Unidev Tech Blog

Author Archive

While debugging a program that had dumped core on HP-UX, I noticed some oddities in the stack trace the required a bit of further investigation. As the code I was looking at is client code, I cannot share it online. This post shows analysis done under CentOS Linux of a trivial program I constructed with the same issue.

For those of you who have not used GDB to analyze a core dump, it’s simple to do. Simply invoke GDB with the following syntax:

    gdb /path/to/executable core.file

Once you’re inside of GDB, you can use the commands on the stack frame, just as you would for any other program you were debugging; you can perform a backtrace to get the stack, navigate up and down through the stack frames, and print variables to the screen.

It was while looking through the backtrace and stack frames, I noticed something was wrong – the stack frames seemed corrupted after as it went further down:

     gdb> bt

This had me stumped for a little while. The memory location for the stack frames starting with #7 was simply nonsense – it was nowhere near the location for the other stack frames and was well out of the range of memory that I had on the box. After looking through source code (see Code Listing 1) and variables for what seemed like hours, the underlying problem suddenly came to me. In the checkLinesForErrors function,  the program was appending an error message. The input file causing the program to crash had about 10 errors in it. The error message was about 60 bytes long. The error buffer could only hold 400 bytes.

The problem was the strcat function was overflowing the error buffer.  Since this had been allocated further up the stack and was being passed down, the overflow went downward, overwriting into the next stack frame. The program had crashed after this overflow occurred – it dumped core because the memory references by one of the C++ strings had been overwritten, which caused a segmentation fault when one of those pointers was being accessed.

In fact, after detecting this, I started looking at the stack frame memory addresses and they looked a little peculiar. If you convert them to their ASCII equivalents, they become part of the error message that was being written to the buffer. For example, the stack frame 8’s address is “0×6863206563617073” is “hc ecaps” when converted to ASCII, and  “space ch” when that string is reversed. This is part of the ERROR_MESSAGE string that was appended into errorBuffer.

The fix was quite easy – add a length variable and some bounds checking as shown in code listing 2. One gotcha in the fix was subtracting the 1 byte for the null character, since the buffer is a C-Style String. It turned out that this error had around for quite a while, but went undetected because a typical run of this program would only append one or two records to this error message.

To sum things up, buffer overflows can be hard to detect. This was especially true in this case when looking through the core file. If you’re looking one that it appears that the data for the stack frames makes absolutely no sense, a buffer overflow like this one could be the cause of the problem.

Code Listing 1 – Original Code:

#define ERROR_MESSAGE “The specified line is not valid: It contains whitespace characters. “

bool checkDataFile(vector<string> dataLines)

{

char errorBuffer[400];

errorBuffer[0]=’\0′;

int errorCount;

if (!processDataFileLines(dataLines, errorBuffer))

{

cerr << “Errors occurred in processing” << endl;

cerr << errorBuffer << endl;

return false;

}

return true;

}

bool processDataFileLines(vector<string> dataLines, char * errorBuffer)

{

int errorCount = 0;

bool rc = checkLinesForErrors(dataLines, errorBuffer);

return rc;

}

bool checkLinesForErrors(vector<string> dataLines, char * errorBuffer)

{

int errorCount = 0;

for (unsigned int i=0; i<dataLines.size(); i++)

{

if (dataLines[i].find_first_of(” \r\n\t”)!=string::npos)

{

strcat(errorBuffer, ERROR_MESSAGE);

errorCount++;

}

}

return (errorCount == 0);

}

Code Listing 2 – Corrected Code:

bool checkDataFile(vector<string> dataLines)

{

char errorBuffer[400];

errorBuffer[0]=’\0′;

int errorCount;

processDataFileLines(dataLines, errorBuffer, sizeof(errorBuffer)-1);

if (!processDataFileLines(dataLines, errorBuffer, sizeof(errorBuffer)-1))

{

cerr << “Errors occurred in processing” << endl;

cerr << errorBuffer << endl;

return false;

}

return true;

}

bool processDataFileLines(vector<string> dataLines, char * errorBuffer, unsigned int errorBufferLength)

{

int errorCount = 0;

bool rc = checkLinesForErrors(dataLines, errorBuffer, errorBufferLength);

return rc;

}

bool checkLinesForErrors(vector<string> dataLines, char * errorBuffer, unsigned int errorBufferLength)

{

const char * message_prefix=foo;

int errorCount = 0;

for (unsigned int i=0; i<dataLines.size(); i++)

{

if (dataLines[i].find_first_of(” \r\n\t”)!=string::npos)

{

strncat(errorBuffer, ERROR_MESSAGE, errorBufferLength – strlen(errorBuffer));

errorCount++;

}

}

return (errorCount == 0);

}

It’s easy to say mobile development is continuing to grow every day with no signs of slowing down. Creating ways for users to access all the features a company has to offer are continuously sought after. With Sencha Touch and PhoneGap, it’s become much easier for developers to create powerful and intuitive applications, for users that can be deployed via the web as well as distributed on the iOS App store or Android Marketplace. The purpose of this blog post is to provide a brief, easy to understand explanation about what each technology does, and how they can work together to create a powerhouse of new elements.

Sencha Touch is a web framework that uses a combination of HTML5, CSS3, and JavaScript to create rich and formable web pages. The combination of these elements brings numerous capabilities that a standard web page cannot. Features include the familiar touch events tap, double tap, pinch, swipe and more. Through your choice of AJAX, JSONP, or YQL accessing sources and storing local data has created more possibilities for web apps. If a news site created a mobile app using Sencha Touch, a user could visit the page from their home internet access, have the articles of the day stored locally, and throughout the day could read their favorite articles without the need of a Wi-Fi network or phone provider’ internet service. One of the great things about Sencha Touch for developers is the code is written once and can be accessed on multiple platforms. Whether it’s a smartphone or tablet, Sencha touch is compatible with any device operating on iOS 3+, Android 2.1+, and Blackberry 6+. The entire library is less than 120kb, making it lightweight, and hardware concerns are less of an issue.

PhoneGap follows the same basic ideas as Sencha Touch. It uses technologies developers are already familiar with and makes them easily distributable to multiple platforms. Once your app is built with web-standards, encapsulate your code in PhoneGap. This allows access to a device’s native API. Depending on the device this could include accessing the camera, geo-location, notifications, and accelerometer, just to name a few. At this point the app has been built, wrapped in PhoneGap to use the fancy gadgets included on your device, and now acts as a native application. The next step available is to submit it to the iOS App Store, or the Android Market. This can significantly increase the number of potential users to the product or service provided.

By themselves Sencha Touch and PhoneGap are two powerful frameworks at a developer’s disposal. A great feature is they can be used hand-in-hand with one another. Where one may be lacking, the other makes up for. Sencha Touch is a fantastic tool for creating web apps but it doesn’t give you access to device functions like the camera and notifications. Because this tool runs as a browser and not as an application, it doesn’t allow you to submit what you’ve created to an applications marketplace. This is where PhoneGap comes into the picture. PhoneGap can be used to encapsulate a Sencha Touch Application allowing your Sencha app to gain access to your devices feature as well as allow your creation to be published to your desired app marketplaces.

Sencha Touch and PhoneGap are tools that have the potential to open the doors for new mobile possibilities that will meet and exceed client expectations.

Optimizing for the iPhone “Retina Display” and Other High Resolution Devices

The iPhone 4 and new iPhone 4s come featured with Apple’s “Retina Display”. This is a 3.5 inch screen with a resolution of 960×640 at 326 pixel per inch. Compared to its predecessor, the iPhone 3GS, this display is a very significant improvement. Once you get used to the Retina Display older devices will no longer cut it. The pixelation of graphics with lower ppi devices stick out like a sore thumb leaving high resolution users dissatisfied. Here we’ll show you how to target these devices and optimize to bring users the best quality in web graphics.

Below are identical logos being viewed on the iPhone 4 with Retina Display. It’s quite obvious which of the two below has been optimized for the high resolution devices. As mobile application and websites become more and more common using high resolution graphics it is something developers today need to consider when developing applications and websites.

Identical logos being viewed on the iPhone 4 with Retina Display.

So how do we go about targeting a high ppi device?

When developing an application much of the work is done for us. Create and save two different versions of each graphic we want to optimize. One of them should be saved at 163ppi (iPhone 3GS) and the other should be twice the size and saved at 326 ppi. Applying the suffix “@2x” in the image title of the high ppi image will trigger iOS to use that particular image when a device with Retina Display is being used. An example of this naming convention would be “myimage.jpg” and “myimage@2x.jpg”.

Mobile Safari does not automatically recognize the “@2x” suffix so we have to target the mobile devices with high dpi and query an alternate stylesheet. The following code will do just that:

<link rel=”stylesheet” type=”text/css” media=”only screen and (-webkit-min-device-pixel-ratio: 2)” href=”retinaDisplay.css” />

If you had a 12×12 icon on your webpage in this stylesheet you would load the 24×24 version of the icon and specify its height and width to be 12×12. It is also possible to do this using just your image tag. For example:

<img src=”myImage24x24” width=”12” height=”12” />

The iPhone uses the name “Retina Display” for its new display because the classification of the images displayed by the device is so high the human eye is unable to differentiate its pixels. Beyond the percentage of resemblance of the human eye and the “Retinal Display”, the reality is that nobody has achieved anything closer to human vision prior to this. Apple has come up with an approach that has changed the way we see images on the iPhone.

Interested in Mobile Development? Contact Unidev.