Workaround for crashing Electron/Atom applications!

A few days ago  all my Electron (Atom Shell) apps started crashing on my Ubuntu 17.10  (Artful Aardvark) machine: Skype, Discord, Slack…  and each stack trace looks very much like this:

#0 0x0000000003419062 in ()
#1 0x0000000003f96086 in __start_google_malloc ()
#2 0x00000000034b9dc5 in calloc ()
#3 0x00007ffff20dc5d1 in g_malloc0 () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff4afc4c9 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5 0x00007ffff4b01855 in g_type_register_static () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007ffff4b01af5 in g_type_register_static_simple () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007ffff5c93f24 in gdk_display_manager_get_type () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8 0x00007ffff5c93f69 in gdk_display_manager_get () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#9 0x00007ffff6070954 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#10 0x00007ffff6056f28 in () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#11 0x00007ffff20e2fdf in g_option_context_parse () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff6057538 in gtk_parse_args () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#13 0x00007ffff60575b9 in gtk_init () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#14 0x0000000001049626 in ()
#15 0x000000000104f1e7 in ()
#16 0x0000000001051656 in ()
#17 0x0000000003f6897b in brightray::BrowserMainParts::PreEarlyInitialization() ()
#18 0x0000000003e01169 in atom::AtomBrowserMainParts::PreEarlyInitialization() ()
#19 0x00000000015f6cf4 in ()

I don’t really know what’s on foot here, but Google led me to the GTK2_RC_FILES environment variable.

If I set this to empty, all these applications start properly!

Example starting Skype, note the space after the equals sign:

$ GTK2_RC_FILES= skypeforlinux

or

$ export GTK2_RC_FILES=
$ skypeforlinux

Can someone explain this error and what a proper fix would look like?

Update: Setting the XDG_CONFIG_DIRS environment variable to empty also works as a workaround!

Increase disk size for OpenShift Origin Virtual Machine

Loving OpenShift, but having more than the three projects that already cost more than I earn from them I run an OpenShift Origin Virtual Machine on my home server.

So today I was trying to get Uptime running on OpenShift via uptime-openshift. A truly wonderful way of installing applications, except that it didn’t go so well:

$ rhc app create uptime nodejs-0.10 mongodb-2.4 --from-code=//github.com/rkmallik/uptime-openshift
Application Options
-------------------
Domain: origin
Cartridges: nodejs-0.10, mongodb-2.4
Source Code: //github.com/rkmallik/uptime-openshift
Gear Size: default
Scaling: no

Creating application 'uptime' ... 
The server did not respond correctly. This may be an issue with the server configuration or with your connection to the server (such as a Web proxy or firewall). Please
verify that you can access the OpenShift server //172.16.3.3/broker/rest/domain/origin/applications

Or…

$ rhc app create uptime nodejs-0.10 mongodb-2.4 --from-code=//github.com/rkmallik/uptime-openshift
Application Options
-------------------
Domain: origin
Cartridges: nodejs-0.10, mongodb-2.4
Source Code: //github.com/rkmallik/uptime-openshift
Gear Size: default
Scaling: no

Creating application 'uptime' ... Unpacking premade journal
tar: journal/prealloc.1: Wrote only 2048 of 10240 bytes
tar: Exiting with failure status due to previous errors

What’s going on? It turns out I was running low on disk space. The virtual machine image was only 8 GB and there was too little disk space left when the Mongo cartridge wanted to install the pre-allocated journals!

So, time to enlarge the disk! In short, the steps I took were:

  1. Convert virtual machine disk image to .vdi format
  2. Enlarge .vdi disk image
  3. Add partition with new disk space
  4. Add new partition to LVM volume group
  5. Extend LVM logical volume
  6. Resize file system

Now, let’s dive into the details!

Convert virtual machine disk image to .vdi format

Shutdown the virtual machine first!

As the VirtualBox user on the hypervisor, in the directory for the virtual machine:

$ VBoxManage clonehd origin-vm.vmdk origin-vm.vdi --format VDI
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone hard disk created in format 'VDI'. UUID: 646d9ed4-c751-45a3-9f08-0946e11591c9

Enlarge .vdi disk image

As the VirtualBox user on the hypervisor, in the directory for the virtual machine:

$ VBoxManage modifyhd origin-vm.vdi --resize 81920
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Enlarge it with as much as you want to allow the disk image to grow on the hypervisor! The unit is megabytes.

Now detach the .vmdk file and attach the .vdi file from the virtual machine. I did this with phpVirtualBox, so the corresponding command line is left as an exercise for the reader.

Delete the the .vmdk file, or keep it as backup if you like.

Add partition with new disk space

Start the virtual machine and login. Default root password is changeme. Being a Linux user for about 15 years, I’m no stranger to fdisk:

# fdisk /dev/sda

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
 switch off the mode (command 'c') and change display units to
 sectors (command 'u').

Command (m for help): c
DOS Compatibility flag is not set

Command (m for help): u
Changing display/entry units to sector

Command (m for help): n
Command action
 e extended
 p primary partition (1-4)
p
Partition number (1-4): 3
First sector (16777216-167772159, default 16777216): 
Using default value 16777216
Last sector, +sectors or +size{K,M,G} (16777216-167772159, default 167772159): 
Using default value 167772159

Command (m for help): t
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)

Command (m for help): p

Disk /dev/sda: 85.9 GB, 85899345920 bytes
255 heads, 63 sectors/track, 10443 cylinders, total 167772160 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0003c6cc

 Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 16777215 7875584 8e Linux LVM
/dev/sda3 16777216 167772159 75497472 8e Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

If told to reboot, do that. Otherwise Linux will not show the new partition.

Add new partition to LVM volume group

# vgextend vg_broker /dev/sda3
 No physical volume label read from /dev/sda3
 Physical volume /dev/sda3 not found
 Physical volume "/dev/sda3" successfully created
 Volume group "vg_broker" successfully extended

Extend LVM logical volume

Use all available space:

# lvextend -l +100%FREE /dev/mapper/vg_broker-lv_root
 Extending logical volume lv_root to 78,71 GiB
 Logical volume lv_root successfully resized

Resize file system

First find out the LSize in sectors:

# lvs --units s
 LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
 lv_root vg_broker -wi-ao---- 165060608S 
 lv_swap vg_broker -wi-ao---- 1671168S

Second, resize the file system. Change capital S to lower-case:

# resize2fs /dev/mapper/vg_broker-lv_root 165060608s
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/vg_broker-lv_root is mounted on /; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 5
Performing an on-line resize of /dev/mapper/vg_broker-lv_root to 20632576 (4k) blocks.
The filesystem on /dev/mapper/vg_broker-lv_root is now 20632576 blocks long.

 Done!

If only I remembered why I needed more disk space?!

ZYB closing

For a couple of years I’ve been using ZYB to backup my mobile phone book online. They got bought by Vodafone and now they’re closing:

On 31 July, ZYB will be closing. Please go to www.360.com to register and backup your phone there. We thank all of our customers for their support!

Mysterious crashes = RAM memory failure

I had some mysterious crashes on my Thinkpad T60p the other day. First I got Firefox hangs, second Firefox didn’t start, third I got segfaults when listing a directory on the hard disk, four I got kernel panic when running fsck…

Now I’m running Memtest86 and it does not look good:

That computer is soooo being sent to service!!!

BlueGriffon – “the next-generation Web editor”

BlueGriffon logoI forgot to write about the upcoming WYSIWYG web site editor BlueGriffon when I first heard about it (probably from Fredda) but I got reminded of it today. This is the announcement in Daniel Glazman’s blog (from 30 September):

In the beginning was Netscape Gold. Then Mozilla Composer. From the ashes of Netscape and the code of Mozilla Composer came Nvu. Nvu had a cousin, KompoZer. But all this tools now belong to History and are extinct or on path to extinction.

In the meantime, Mozilla brought Firefox to the masses and its rendering engine, Gecko, has the power to fuel a next-generation wysiwyg editor for the World Wide Web. This editor is BlueGriffon™. Stay tuned!

Bye bye UIQ

Mobile phone interface developer UIQ (a former Symbian office) in Ronneby, Sweden has given notice to all employees today. This is the latest development in a downward spiral that started (or just accelerated?) with the Symbian Foundation announcement earlier this year.

Instantiating Java objects of generic type parameter

I was going to write a really grand blog entry about how to instantiate a Java object of the type specified as parameter to a generic class but I figured that someone must have done that already. The blog article Java Generics: Instantiating Objects Of Type Parameter Without Passing Class Literal To Instance sums it up pretty good. My implementation supports a deeper inheritance hierarchy (caused my Javassist in my case) but I was not clever enough to extract the hack, I mean magic, to a generic Factory class as suggested by the first comment to the article.

The final statement in the article is that This pattern is frequently used for generic DAO classes, and yes I first saw it at hibernate.org – Generic Data Access Objects, but I think it is a bit scary that this workaround is common enough to be called a pattern.