by admin

UNIGINE’s Heaven Benchmark Releases Version 4.0

February 18, 2013 in News by admin

unigineUNIGINE Corp. has released a new, enhanced version 4.0 of Heaven Benchmark, the GPU intensive benchmark that gained massive popularity among overclockers and hardware manufacturers for hammering their graphics cards to the limits. This powerful tool can be effectively used to determine the stability of a GPU under extremely stressful conditions, as well as check the cooling system’s potential under maximum heat output. It provides completely unbiased results and generates true in-game rendering workloads across all platforms, such as Windows, Linux and Mac OS X.

For more information follow this link.

by admin

Stack unwinding (stack trace) with GCC

February 15, 2013 in Code Snippets, Tips & Tricks, Tutorial by admin

Via blog.bigpixel.ro:
I always liked the nice stack trace you get in some languages like java, c#, etc, with a nice clean trace of where the issue happent. Can we have this in C/C++ with gcc? Of course we can.

Let’s use the following code in which we try to display our stack trace (assumes you are building it with -g to enable debug symbols):

#include 

void dummy_function2()
{
	// here will call our back_trace function to
	// display the back_trace
}

void dummy_function1()
{
	dummy_function2 ();
}

int main(int argc, char **argv)
{
	dummy_function1 ();
}

On some platforms, gcc has a built-in function called __builtin_return_address. The info file says something like:

__builtin_return_address (LEVEL)’
This function returns the return address of the current function,
or of one of its callers. The LEVEL argument is number of frames
to scan up the call stack. A value of `0′ yields the return
address of the current function, a value of `1′ yields the return
address of the caller of the current function, and so forth.

The availability and useability of this buil-in depends on platform, compiler,etc.
Guarded with this knowledge , we can build our first (and crude) backtrace:

void show_backtrace()
{
	// get current address
	void* p = __builtin_return_address(0);
	printf("0x%x\n", p);

	// get callee address
	p = __builtin_return_address(1);
	printf("0x%x\n", p);

	// we cannot get more addresses as we don't have any
	// information about how many leves of calls we have
}

running this will display something like:

$ ./a.out
0x4007be
0x4007ce

As we expected, it display the last two functions called before calling our function to display the backtrace. We could get more in-detail backtrace if we know how many levels to ask, but unfortunatelly we don’t know from where this function will be called. In any case it will be called at least from main()which is called from libc initialization function, so getting back two levels of stack trace should be safe. It display the two return addresses, altough we don’t have enough information yet for displaying a nice file:line no pair, but hey,this is more than nothing. And anyway, we’ll fix that later.

Investigating a bit more in detail, seems like the standard library offers a function backtrace() and two other helper functions to allow backtrace. One backtrace using this function could look similar to:

#include 

void show_backtrace()
{
	void *array[10];
	size_t size;
	char **strings;
	int i;

	size = backtrace (array, 10);
	strings = backtrace_symbols ((void *const *)array, size);

	for (i = 0; i < size; i++)
	{
		printf ("%s\n", strings[i]);
	}

	free (strings);
}

running the code we get a listing like the following:

$ ./a.out
./a.out() [0x4006bd]
./a.out() [0x40071e]
./a.out() [0x40072e]
./a.out() [0x400749]
/lib/libc.so.6(__libc_start_main+0xfd) [0x7f542a471c4d]
./a.out() [0x4005e9]

It is more than we get from the previous attempt, as we get now the entire stack trace, and we don’t have to be carefull about how many levels we unwind.

Still, is far from a nice file:line style of stack trace provided by the other languages. Time to get serious about. A bit more search on internet reveals a nice library called unwind. (can be found here). From the homepage we get the following:

The primary goal of this project is to define a portable and efficient C programming interface (API) to determine the call-chain of a program. […]

Sounds good. Let’s have an another approach of stack trace using this time the unwind library:

#include

void show_backtrace (void)
{
	char name[256];
	unw_cursor_t cursor; unw_context_t uc;
	unw_word_t ip, sp, offp;

	unw_getcontext (&uc);
	unw_init_local (&cursor, &uc);

	while (unw_step(&cursor) > 0)
	{
		char file[256];
		int line = 0;

		name[0] = '\0';
		unw_get_proc_name (&cursor, name, 256, &offp);
		unw_get_reg (&cursor, UNW_REG_IP, &ip);
		unw_get_reg (&cursor, UNW_REG_SP, &sp);

		printf ("%s ip = %lx, sp = %lx\n", name, (long) ip, (long) sp);
	}
}

Running the code with this version of stack trace, we get an output which resembles to following:

$ ./a.out
dummy_function2 ip = 400b05, sp = 7fff56e21eb0
dummy_function1 ip = 400b15, sp = 7fff56e21ec0
main ip = 400b30, sp = 7fff56e21ed0
__libc_start_main ip = 7fd13578bc4d, sp = 7fff56e21ef0
_start ip = 400869, sp = 7fff56e21fb0

Now this looks quite useable, we have the function names, we have the instruction pointer address.

At this moment, half of the problem is solved, we have the list of functions through wich went the call, we have the addresses from where the call was made. All we need now is a way to convert this into a nice file:line type of strack trace. And from here things get dirty.

One way would be to use the readelf helper application, to retrieve the debug informations from the executable file and transform it in something which can be used easily:

$ readelf --debug-dump=decodedline  a.out

Decoded dump of debug contents of section .debug_line:

CU: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/unwind_test.c:
File name                            Line number    Starting address
unwind_test.c                                 79            0x400924

unwind_test.c                                 85            0x40092c
unwind_test.c                                 86            0x400940
unwind_test.c                                 88            0x400955
...

This starts to look interesting. Before the stack dump (maybe at application startup), we can execute the above command with popen and load the list of file:line:address values, then when while displaying the stack trace, we can lookup int this list to display a nice stack trace with function in file:line format. Still, there is lot of info to be loaded, specially if our application is quite large.

There is an easier approach. There is a little known utility called addr2line, who has exactly the functionality we are looking for: if you give him and executable file and a address, it will try to transform it into function:file:line trio.

addr2line translates addresses into file names and line numbers. Given
an address in an executable or an offset in a section of a relocatable
object, it uses the debugging information to figure out which file name
and line number are associated with it.

This will complete nicelly our stack unwinding. First, we need a way from getting the trio from addr2line. With the parameters as specifed bellow, the helper program will output first the name of function, or ?? if cannot resolve it and on the second line will display the file and line information in filename:lineno format (or ??:0 if cannot find the info). For this example we skip over the function name as we already have it from libunwind:

int getFileAndLine (unw_word_t addr, char *file, size_t flen, int *line)
{
	static char buf[256];
	char *p;

	// prepare command to be executed
	// our program need to be passed after the -e parameter
	sprintf (buf, "/usr/bin/addr2line -C -e ./a.out -f -i %lx", addr);
	FILE* f = popen (buf, "r");

	if (f == NULL)
	{
		perror (buf);
		return 0;
	}

	// get function name
	fgets (buf, 256, f);

	// get file and line
	fgets (buf, 256, f);

	if (buf[0] != '?')
	{
		int l;
		char *p = buf;

		// file name is until ':'
		while (*p != ':')
		{
			p++;
		}

		*p++ = 0;
		// after file name follows line number
		strcpy (file , buf);
		sscanf (p,"%d", line);
	}
	else
	{
		strcpy (file,"unkown");
		*line = 0;
	}

	pclose(f);
}

Now we need to modify our libunwind based stack winding to call this function and display the stack trace:

void show_backtrace (void)
{
	char name[256];
	unw_cursor_t cursor; unw_context_t uc;
	unw_word_t ip, sp, offp;

	unw_getcontext(&uc);
	unw_init_local(&cursor, &uc);

	while (unw_step(&cursor) > 0)
	{
		char file[256];
		int line = 0;

		name[0] = '\0';
		unw_get_proc_name(&cursor, name, 256, &offp);
		unw_get_reg(&cursor, UNW_REG_IP, &ip);
		unw_get_reg(&cursor, UNW_REG_SP, &sp);

		//printf ("%s ip = %lx, sp = %lx\n", name, (long) ip, (long) sp);
		getFileAndLine((long)ip, file, 256, &line);
		printf("%s in file %s line %d\n", name, file, line);
	}
}

Building again the application and running it, we’ll get the long awaited result:

$ ./a.out
dummy_function2 in file /[some path]/unwind_test.c line 141
dummy_function1 in file /[some path]/unwind_test.c line 146
main in file /[some path]/unwind_test.c line 151
__libc_start_main in file unkown line 0
_start in file unkown line 0
by admin

Samsung Galaxy Altius smartwatch screenshots leaked

February 15, 2013 in News, Rumors by admin

galaxy-altius-lg1 Screenshots purported to be from a forthcoming smartwatch from Samsung have emerged on a Korean messageboard. Spotted by Slashgear, the Samsung Galaxy Altius looks as though it will give users quick access to date and time, music playback controls, and email notifications. If accurate, the leak suggests that Samsung, like Apple, could well into the development of the next generation of wearable smart devices.

For more information and screenshots follow this link.

by admin

Qt 5 Port to Windows Runtime kick-started

February 15, 2013 in News by admin

qtFrom blog.qt.digia.com:

With Windows 8, Microsoft introduced a new platform, the Windows Runtime. On the desktop, the operating system provides 2 modes:

Classic mode: This mode shows the familiar Windows desktop known from Windows 7 (with the exception of the start menu), in which traditional applications using the Win32 API run. No modifications are required for Qt 4 or Qt 5-based applications to run in this mode.

Modern UI (formerly known as Metro mode): This is a new type of user interface intended for tablet and phone UIs on which Windows Store Apps run. These applications use a new API called Windows Runtime, which is based on the Component Object Model (COM). A similar API exists on Windows Phone 8.

Research work on how to port Qt 5 to use Windows Runtime was started by Andrew Knight from Digia and is visible in the winrt branch of the qtbase repository. Recently, further contributions by Kamil Trzciński were added to it (check out his blog). Now, with Qt 5.0 out of the door, we would like to kick off this platform port. This completes our cross-platform offering in addition to the ports for the widely used Android and iOS platforms.

For more information go here.

 

Android port of the Firebird Jdbc driver (Jaybird) 2.2.2 is released

February 15, 2013 in News by Adrian Marius

New version for Android Jaybird is released This is a port of the Firebird Jdbc driver (Jaybird)

You can check what is new in Jaybird 2.2.2 from the official announcement page

 

 

by admin

Accessing Your Webcam in HTML5

February 15, 2013 in Tutorial by admin

html5A nice tutorial from kirupa.com. Quoting from their article:

“Accessing your webcam via your browser used to involve a…pardon the profanity, a plugin. That’s right. In order to connect to a webcam and gain access to its video stream, you had to rely on something primarily created in Flash or Silverlight. While that approach certainly worked for browsers that supported plug-ins, it didn’t help for the increasing number of browsers that aim to be plugin-free. This inability to natively access the webcam without relying on 3rd party components was certainly a gap in the HTML development story. At least, that was the case until pretty recently.”

For the full article, follow this link.

 

by admin

Opera moves to WebKit

February 15, 2013 in News by admin

operaOpera Software today announced reaching the milestone of 300 million monthly users across all its browser products on phones, tablets, TVs and computers.

“300 million marks the first lap, but the race goes on,” says Lars Boilesen, CEO of Opera Software. “On the final stretch up to 300 million users, we have experienced the fastest acceleration in user growth we have ever seen. Now, we are shifting into the next gear to claim a bigger piece of the pie in the smartphone market.”

To provide a leading browser on Android and iOS, this year Opera will make a gradual transition to the WebKit engine, as well as Chromium, for most of its upcoming versions of browsers for smartphones and computers.

“The WebKit engine is already very good, and we aim to take part in making it even better. It supports the standards we care about, and it has the performance we need,” says CTO of Opera Software, Håkon Wium Lie. “It makes more sense to have our experts working with the open source communities to further improve WebKit and Chromium, rather than developing our own rendering engine further. Opera will contribute to the WebKit and Chromium projects, and we have already submitted our first set of patches: to improve multi-column layout.”

The first look at what Opera is bringing to the smartphone game as a result of this switch will be shown at Mobile World Congress in Barcelona this month, with a preview of its upcoming browser for Android.

For more information and source follow this link.

by admin

HP bids adieu to WebOS, Windows RT, and says hello to Android

February 15, 2013 in News by admin

android-200x150-200x150While HP still hasn’t made it official, sources are reporting that HP has decided that at least part of its tablet and smartphone future lies not with Windows or WebOS but with Google’s Android. Who’d thought it!?

Source: here.

 

by admin

Modern OpenGL tutorials

February 14, 2013 in Tutorial by admin

A series of articles about modern OpenGL on Mac, with a focus on making games can be found here. All the code is open source, and downloadable from github.

by admin

OGLplus 0.26.0 released

February 14, 2013 in News by admin

OGLplus is a header-only library which implements a thin object-oriented facade over the OpenGL® (version 3 and higher) C-language API. It provides wrappers which automate resource and object management and make the use of OpenGL in C++ safer and easier. It’s list of features include things like automatic resource management, type safety, error handling and diagnostics.

For download and more information about the library, follow this link.

 

Skip to toolbar