You are currently browsing the monthly archive for July 2010.

(Please visit new location of this post here at http://binaryjunction.com/.)

Olive Telecom, an Indian-based multinational company, launched India’s first 3.5G Pad, named OlivePad-VT100. The main features of OlivePad are:

For full post, please visit here at http://binaryjunction.com/.

It is needed frequently to analyze the cause of a crashed application. One way to do it is through the creating of core dump files that can be later analyzed to debug the issue. Core dump files are a snapshot of the memory area being used by the application at the time the crash occurred. Creation of core dump files may not be enabled by default, and may require some configuration. The instructions to enable the core dump files, I am going to describe here, are tested on Fedora Linux Distribution.

Enter following line at the command prompt:

$ulimit -c unlimited

Now check the output of the command “ulimit -c”, and it should show “unlimited” as follows.

$ulimit -c
unlimited

The above change, done in the way, will not be permanent. To make them permanent, edit file “/etc/security/limits.conf” (You must either be root user or must have “sudo” permission to edit this file.) and type the following line.

*      soft     core         unlimited

“*” means that this change is applicable for all users. However, to make this change for only a specific user, you should enter as follows:

<user-login-id>      soft     core         unlimited

The core dump files, generated after an application crashes, are stored in the directory from where the application was run. To place the core dump files in another location, the “sysctl” variable, named “kernel.core_pattern”, is used. The value of this variable can be checked as follows:

$sysctl -a|grep core_pattern #(if you are root user.)
kernel.core_pattern = core #(assuming “abrtd” is not running. The explanation about “abrtd” is discussed below.)

or

$sudo sysctl -a|grep core_pattern #(if you are non-root user with sudo permissions.)
kernel.core_pattern = core

The value of kernel.core_pattern is “core” currently. Two ways to change the value of this variable are as follows:

sysctl -w kernel.core_pattern=/tmp/core.%p

Now if you check the value of “kernel.core_pattern”, it will be “/tmp/core.%p”.

$sysctl -a|grep core_pattern
kernel.core_pattern = /tmp/core.%p

This means that the core dump files will be generated in the “/tmp” directory. “%p” extension to core dump files is used to append the process id of the application that crashed. This way, the variable kernel.core_pattern is also used to format the name of core dump files.

ABRT (Automated Bug Reporting Tool) Daemon:

ABRT is an application, included in Fedora Linux Distribution, that is used to report bugs in the software packages whenever crash occurs. Due to this, ABRT also helps in creation of core dump files. Multiple packages may be needed to run various features of ABRT daemon, and their listing is as follows.

abrt
abrt-plugin-bugzilla
abrt-plugin-runapp
abrt-desktop
abrt-addon-ccpp
abrt-addon-kerneloops
abrt-plugin-logger
abrt-libs
abrt-addon-python
abrt-gui

To install these packages in Fedora, one can do:

$yum install <package-name> #(if root user.)

or

$sudo yum install <package-name> #(if non-root user with sudo permissions.)

To check whether ABRT daemon is running on your system, execute:

$service abrtd status or #sudo service abrtd status
abrt is stopped

If it is stopped as shown above, “abrtd” can be started as follows:

$service abrtd start or #sudo service abrtd start
Starting abrt daemon:                                      [  OK  ]

And, now the status should show as follows:
$service abrtd status or #sudo service abrtd status
abrt (pid  5678) is running…

When “abrtd” is running, the value of sysctl variable “kernel.core_pattern” is different from the above as shown below:

$sysctl -a|grep core_pattern
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp /var/cache/abrt %p %s %u %c

“abrtd” creates a sub-directory (named something like “ccpp-1279914365-14618”) in the directory “/var/cache/abrt” as shown in the value of the variable. This also means that the core files will also be stored in that sub-directory in the “/var/cache/abrt” directory (in addition to the current directory where application was run). ABRT daemon also creates other files in addition to the core dump files in the sub-directory to further help users in debugging the crash issue.

By default, “abrtd” created core dump files only for those executable (or packages) that are managed by “rpm” (red hat package manager) utility. To enable “abrtd” for non-rpm application (something you compiled locally and are not managed through rpm), you need to edit the file cat “/etc/abrt/abrt.conf” , and change the value of the field “ProcessUnpackaged” to “yes” as follows:

ProcessUnpackaged = no   #(before editing the file)

ProcessUnpackaged = yes  #(after editing the file)

For full post, please visit here at http://binaryjunction.com/.

For full post, visit here at http://binaryjunction.com .

For full post, please visit  here at http://binaryjunction.com/ .

For full post, please visit  here at http://binaryjunction.com/ .

For full post, please visit here at http://binaryjunction.com/ .

For full post, please visit here at http://binaryjunction.com/ .

For full post, please visit here at http://binaryjunction.com/ .

(Please visit new location of this post here at http://binaryjunction.com/ .)

These questions have been prepared by collecting information from several friends and also by searching on various sites and forums on Internet. In general, I have heard from my friends that F2 VISA interview process is not difficult and not many questions are asked from F2 visa applicants.  So these questions are just for good preparation and building self-confidence.  If some question is not clear, or you want a suggestion for answers for any questions, please leave a comment, I will try my best to give you “just a suggestion”.

For full post, please visit here at http://binaryjunction.com/ .