How to set environment variable in gdb

GDB inherits the environment variables from your shell. Some environment variables, like LD_LIBRARY_PATH, might not be inherited for safety reasons. This can cause errors like this when you try to debug:

$ gdb --args ./a.out
(gdb) r
/path/to/a.out: error while loading shared libraries: libfoobar.so.5: cannot open shared object file: No such file or directory

You can set the LD_LIBRARY_PATH environment variable at the gdb shell using the set env command like this:

(gdb) set env LD_LIBRARY_PATH /path/to/1:/path/to/2

However, if you use a shell like Fish, you will notice that this will silently not work and you still get the cannot open shared object file error.

This is because under the covers, gdb is reading the SHELL environment variable to understand what is the shell and doing what is right for that shell. It might not understand how to work with the Fish, which is a relatively new shell.

The solution that works for me, is to set the SHELL variable at the Fish shell to the Bash path:

$ set SHELL (which bash)

And then launch gdb and set the environment variable as shown above. It works after that.

Reference: Your program’s environment (GDB Manual)

Advertisements

Unicode BOM problem

Problem

I processed a JSON file using some tool and the resulting JSON text file would not be accepted by other tools. They would complain that this was a UTF-8 Unicode (with BOM) text file. I had to remove whatever this BOM was from my UTF-8 file.

Solution

BOM is a byte order mark added by some tools to UTF-8 files. BOM is this 3-byte sequence: 0xEF,0xBB,0xBF.

You could use any tool or process to remove these 3-byte sequences. If you are on Linux, the awesome sed tool can do the job:

$ sed -i '1s/^\xEF\xBB\xBF//' in.txt

Reference: How can I remove the BOM from a UTF-8 file?

GDB Colour Filter

A problem I face regularly with GDB is the backtrace. The stack trace lists out the function frames currently on the stack and it is a wall of text. it is hard to discern the function address, function name, function parameters, source file path and line number.

Normal GDB backtrace

This is precisely the problem that GDB Colour Filter solves. Clone its repo and source its Python file inside your ~/.gdbinit and you are set. Backtraces are now printed with distinctly different colors and formatting for all the components of a function frame. I especially find it useful to pick out the function name and the source file and line number.

GDB backtrace with GDB Colour Filter

There is only one slight problem: to display the components of a function frame at a consistent column this breaks down a frame into two lines. So your backtrace lines are doubled and might fill up the display when you try this.

Google Form redirection error

Problem

A team member shared a Google Form for me to fill out. Strangely that form URL could not open in Firefox. It would not load with this error:

The page isn’t redirecting properly
An error occurred during a connection to docs.google.com.
This problem can sometimes be caused by disabling or refusing to accept cookies.

Solution

I did not have any setting in Firefox to disable or refuse some cookies. So that error was wrong. But it gave a hint that the problem might be caused by cookies.

I went into the Firefox options and deleted all cookies involved with the URL google.com. There is no need to delete all cookies, just those that have this URL. Once I did that, the Google Form URL opened correctly.

How to print in a Makefile

Makefiles and especially recursive Makefiles can be hard to understand and debug. But the good old debugging method of printing out values from certain locations in the source code can be employed here too.

  • To print a message when make parses past that location in the Makefile:
$(info Hello World Make just parsed past this line)

Note that make typically parses a file twice before it executes what is needed to satisfy its targets. So, you will see the message you are printing twice.

  • To print the value of a make variable at a certain location in the Makefile:
$(info $(FOOBAR_VAR))

CDex

CDex is a Windows tool for ripping audio tracks from audio CDs to WAV or MP3 files. This is a great utility for ripping the audio CD collection gathering dust in your attic and converting them for playing on devices without a CD/DVD drive.

CDex is straightforward to use:

  • Insert your audio CD into a drive connected to your Windows computer. Its tracks will appear listed in CDex.
  • You can pull the artist/album/track info from FreeDB using the CDDB → Read remote FreeDB option. You would need to provide an email address in the Settings before this can work.
  • To rip to MP3, use the Extract CD tracks to Compressed Audio Files option on the right. This uses the LAME MP3 Encoder, which is installed along with CDex.
  • You can configure the directory and filename format for the ripped MP3 files in the settings.

That is all there is to it.

Tried with: CDex 2.16 and Windows 10 x64

Caffe CUDA_cublas_device_LIBRARY error

Problem

I was trying to build BVLC Caffe from source as described here on Ubuntu 18.04 with CUDA 10.0.

CMake ended with this error:

Please set them or make sure they are set and tested correctly in the CMake files:
CUDA_cublas_device_LIBRARY (ADVANCED)

Solution

This problem seems to occur with a combination of CUDA 10.0 or later and a CMake version that is older than 3.13. I upgraded to CMake 3.14.0 as described here and the problem was solved.

How to install CMake

CMake is easy to install in Ubuntu using apt:

$ sudo apt install cmake

However, depending on your version of Ubuntu, the CMake version that is installed might be very old. So, you might run into problems when you build projects that use features from more recent versions of CMake.

CMake provides binary versions for Linux x86_64. Installing the latest version of CMake from these packages is easy:

  • Remove the Ubuntu version of CMake:
$ sudo apt remove cmake cmake-data
  • Download the .sh binary package of the CMake version you want from here. When I downloaded, I got cmake-3.14.0-Linux-x86_64.sh

  • Move the downloaded package to /opt and execute it:

$ sudo mv cmake-3.14.0-Linux-x86_64.sh /opt
$ cd /opt
$ sudo chmod +x cmake-3.14.0-Linux-x86_64.sh
$ sudo bash ./cmake-3.14.0-Linux-x86_64.sh

This installs this version of CMake in the directory /opt/cmake-3.14.0-Linux-x86_64.

  • Create symbolic links for the CMake binaries:
$ sudo ln -s /opt/cmake-3.14.0-Linux-x86_64.sh/bin/* /usr/local/bin

$ Test if CMake is working:

$ cmake --version
cmake version 3.14.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Tried with: Ubuntu 18.04

Vector growth factor in languages

Growth factor is the factor by which the new size of a C++ STL vector is computed when we need to insert beyond its current capacity. There are containers similar to the STL vector in other languages and it is quite interesting to see what factors were chosen in those implementations.

  • The last time I looked into this (see this post), VC++ vector had a growth factor of 1.5 and GCC vector had a growth factor of 2.

  • Java ArrayList seems to have a growth factor of 1.5. See line 240 in ArrayList.java.

  • Julia also seems to have a growth factor of 1.5.