Monday, June 13, 2016

GraphViz Tutorial for The Uninitiated

This is not a tutorial per se. But, it's an example of how a complex graph can be generated by GraphViz DOT. You need to head over to  https://github.com/pinczakko/GraphViz-Samples for the source code. But, for the impatient, this is the result:
Rather complex graph generated from GraphViz DOT
At least this sample shows you how powerful GraphViz is, after investing even just a couple of hours learning the ropes. The bonus is, you can combine your GraphViz DOT code to your Doxygen comments and generate the graph in your code documentation. Isn't that powerful? Head over to http://www.stack.nl/~dimitri/doxygen/manual/diagrams.html for that.

Hopefully, this ease the pain creating your code documentation ;-)


Monday, June 6, 2016

Arch Linux cpupower Missing Library Temporary Fix

If you are experiencing the issue described at https://bbs.archlinux.org/viewtopic.php?id=213404 (copied here for your convenience--courtesy of bartbkr):
After a recent upgrade, when I attempt to use cpupower, I get the following
message:
    cpupower: /usr/lib/libpci.so.3: verion `LIBPCI_3.5' not found (required by cpupower)
I haven't changed any of the setting for cpupower recently and everything was
running smoothly before. Now I can't query the cpu settings any longer.
$ ls /usr/lib/libpci.so*
        /usr/lib/libpci.so
        /usr/lib/libpci.so.3
        /usr/lib/libpci.so.3.4.1

Then, the temporary solution is to downgrade cpupower to version 4.6.1. Follow the general downgrade guide at https://wiki.archlinux.org/index.php/Downgrading_packages. For comparison sake, this is the log of failed cpupower at start-up in my machine:
root@jeez /var/cache/pacman/pkg
 # systemctl status cpupower.service
— cpupower.service - Apply cpupower configuration
   Loaded: loaded (/usr/lib/systemd/system/cpupower.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2016-06-06 22:07:38 SGT; 44min ago
  Process: 328 ExecStart=/usr/lib/systemd/scripts/cpupower (code=exited, status=1/FAILURE)
 Main PID: 328 (code=exited, status=1/FAILURE)

Jun 06 22:07:37 jeez systemd[1]: Starting Apply cpupower configuration...
Jun 06 22:07:37 jeez cpupower[328]: cpupower: /usr/lib/libpci.so.3: version `LIBPCI_3.5'
Jun 06 22:07:38 jeez systemd[1]: cpupower.service: Main process exited, code=exited, sta
Jun 06 22:07:38 jeez systemd[1]: Failed to start Apply cpupower configuration.
Jun 06 22:07:38 jeez systemd[1]: cpupower.service: Unit entered failed state.
Jun 06 22:07:38 jeez systemd[1]: cpupower.service: Failed with result 'exit-code'.

This is the excerpt the steps that I did to fix the issue via package downgrade:
root@jeez /var/cache/pacman/pkg
 # pacman -U cpupower-4.6-1-x86_64.pkg.tar.xz
loading packages...
warning: downgrading package cpupower (4.6-2 => 4.6-1)
resolving dependencies...
looking for conflicting packages...

Packages (1) cpupower-4.6-1

Total Installed Size:   0.41 MiB
Net Upgrade Size:      -0.10 MiB

:: Proceed with installation? [Y/n] Y
(1/1) checking keys in keyring                            [###############################] 100%
(1/1) checking package integrity                          [###############################] 100%
(1/1) loading package files                               [###############################] 100%
(1/1) checking for file conflicts                         [###############################] 100%
(1/1) checking available disk space                       [###############################] 100%
:: Processing package changes...
(1/1) downgrading cpupower                                [###############################] 100%
:: Running post-transaction hooks...
(1/1) Updating manpage index...
root@jeez /var/cache/pacman/pkg
 # systemctl restart cpupower.service
root@jeez /var/cache/pacman/pkg
 # journalctl -xe
Jun 06 22:51:51 jeez systemd[1]: Starting Apply cpupower configuration...
-- Subject: Unit cpupower.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit cpupower.service has begun starting up.
Jun 06 22:51:52 jeez systemd[1]: Started Apply cpupower configuration.
-- Subject: Unit cpupower.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit cpupower.service has finished starting up.
--
-- The start-up result is done.
pinczakko@jeez Mon Jun 06 10:52:07pm
~/ systemctl status cpupower.service
— cpupower.service - Apply cpupower configuration
   Loaded: loaded (/usr/lib/systemd/system/cpupower.service; enabled; vendor preset: disabled)
   Active: active (exited) since Mon 2016-06-06 22:51:52 SGT; 26s ago
  Process: 2672 ExecStart=/usr/lib/systemd/scripts/cpupower (code=exited, status=0/SUCCESS)
 Main PID: 2672 (code=exited, status=0/SUCCESS)

Jun 06 22:51:51 jeez systemd[1]: Starting Apply cpupower configuration...
Jun 06 22:51:52 jeez systemd[1]: Started Apply cpupower configuration.

As you see in the shell log above, after downgrading cpupower to version 4.6.1, everything went back to normal. This is only temporary fix until libpci 3.5 promoted from testing to stable. We can go back to cpupower version 4.6.2 by then.

Monday, May 9, 2016

Using DBX Debugger on AIX -- How to pass program arguments to DBX

DBX is the default debugger in IBM AIX OS. This debugger's user interface is rather unusual compared to other debugger. It is a command line debugger just like GNU GDB. But, it has a different philosophy. The user guide for DBX is at: https://www.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.cmds2/dbx.htm. The user guide is exhaustive to be read all at once. I recommend you to focus on your goal, i.e. debugging requirements and read the user guide to suite the requirements.

Let's start with a basic requirements:

  • You have a command line program 
  • The program has several arguments that must be passed at startup time.
Now, let's look at the steps to fulfill the requirements above. Let's start with DBX philosophy. The DBX philosophy is as follows:

  1. Running dbx without any arguments in the shell only starts the debugging environment, nothing more, nothing less.
  2. Running dbx with only the executable (program) file name will load the executable into memory but doesn't run the program. This step also doesn't pass any argument(s) to the program.  
  3. DBX has the so-called "subcommands" which are "commands" that you can type in the DBX debugging environment to instruct the debugger to do something. Another way to pass subcommand to DBX is via a text file known as "command file". A command file contains subcommand and the parameters/arguments required by the subcommand.

The gist of the philosophy is: useful thing can be done mostly via DBX subcommands. The following diagram illustrates this philosophy.
Figure 1 IBM AIX DBX debugger principle of working
The DBX Command Line Interface (CLI) is similar to GNU GDB. Therefore, I'm not going to explain it here. I'll proceed to DBX Scripting Interface. The scripting interface is invoked via DBX's "-c" flag. This is the excerpt from DBX user guide:
-c CommandFileRuns the dbx subcommands in the file before reading from standard input. The specified file in the $HOME directory is processed first; then the file in the current directory is processed. The command file in the current directory overrides the command file in the $HOME directory. If the specified file does not exist in either the $HOME directory or the current directory, a warning message is displayed. The source subcommand can be used once the dbx program is started.
I'll show you how to use -c flag to pass your program arguments at the start of a DBX debugging session. The first thing to do before we can use -c flag is to prepare the Command File. If you just want to pass your program arguments, then the contents of the command file is simply the run subcommand and your program arguments. Below is an example of a valid Command File. Let's name the command file as my_cmd.
run -a 10.10.10.254 -p 8000 -n 2  
In the command file above, the program (to be debugged) arguments starts at -a, the run statement in the beginning refers to DBX run subcommand. The following diagram shows this:
Figure 2 Using run subcommand in your command file
This is the verbatim explanation for run subcommand  from DBX user guide:
run Subcommand
run [ Arguments ] [ <File ] [ >File ] [ > >File ] [ 2>File ] [ 2> >File ] [ >&File ] [ > >&File ]
The run subcommand starts the object file. The Arguments are passed as command-line arguments.
Flags
ItemDescription
<FileRedirects input so that input is received fromFile.
>FileRedirects output to File.
2>FileRedirects standard error to File.
> >FileAppends redirected output to File.
2> >FileAppends redirected standard error to File.
>&FileRedirects output and standard error to File.
> >&FileAppends output and standard error to File.
Example
To run the application with the arguments blue and 12, enter:
run blue 12

Therefore, to start DBX debugger to use my_cmd command file above, we enter this in the shell:
$ dbx -c my_cmd [your_program_name]
The -c flag instruct dbx to use my_cmd as the command file, after that you just need to enter your program executable name. Anyway, after dbx parses the command file, it runs your program as if you type run subcommand in a DBX debugging session.

That's it. I hope this post helps those who just started using DBX in AIX or other AIX-like environment.

Thursday, April 21, 2016

Blank Character is Not Null Character

Perhaps, it is partly because I'm not a native English speaker and partly because I forgot that the devil is in the details that I inadvertently wrote code that supposed to initialize a variable with blank characters with null characters.

Blank characters refer to whitespace character (https://en.wikipedia.org/wiki/Whitespace_character), not the null character (https://en.wikipedia.org/wiki/Null_character). In many cases, acceptable blank character for program input is space, which has a value of 20h in ASCII and 40h in EBCDIC. Well, this is not obvious for me at first until I'm debugging some code in an EBCDIC environment. 

So, next time you read an API documentation that says *BLANK*, it doesn't refer to NULL ('\0') character, but it refers to one of the whitespace character which in many cases refer to SPACE (' ').

As a bonus, these are some usable character conversion tables:
http://www.astrodigital.org/digital/ebcdic.html (this one explicitly states SPACE character as BLANK)