☑ Sharing pthreads locks between processes

How to share pthreads primitives across processes.

share tomatoes

The POSIX threads library has some useful primitives for locking between multiple threads, primarily mutexes and condition variables.

Typically these are only effective to lock between threads within the same process. However, pthreads defines a PTHREAD_PROCESS_SHARED attribute for both of these primitives which can be used to specify that they should also be used between processes.

This attribute simply indicates that the primitives be used in a way which is compatible with shared access, however — application code must still arrange to store them in shared memory. This is fairly easily arranged with an anonymous mmap(), or shmget() and shmat() if your processes don’t have a parent/child relationship.

The use of shared memory makes things a little more complicated, which is disappointing, but it still seems to me that using these primitives to synchronise processes is probably still a little more elegant than using pipes or something similar (even if that’s probably a little more portable).

I’ve added a code example to my wiki which illustrates this. I’ve used an anonymous mmap() for shared memory — the previous revision of the page used System V shared memory, but since this isn’t cleaned up automatically on application exit then the mmap() approach is safer.

31 Jan 2013 at 1:02PM by Andy Pearce in Software  | Photo by Elaine Casap on Unsplash  | Tags: pthreads  linux  ipc posix  |  See comments

☑ apport in a storm

Ubuntu’s apport service is less then helpful for developers — learn how to disable it.

port storm

I’m not sure quite when it appeared, but Ubuntu 12.04 has a service called apport which is a bit of a pain.

It’s started by default and appears to attempt to collect crash dump information, presumably to send back to Ubuntu. I’ve seen little notification icons appearing at one time or another which I assume is this service doing its job. I’m not going to get into the potential privacy implications of sending core dumps of possibly commercial third party software (the rest of the system may filter the core dumps, I’m not sure), but if you’re a developer trying to get hold of core dumps this is annoying. I discovered this application when trying to figure out where my core dumps were disappearing to.

What happens is that the Upstart job for the service alters the value of /proc/sys/kernel/core_pattern, which changes where core dump files are stored, to pipe the core dump into /usr/share/apport/apport, which is a Python script. This script attempts to write the core dump to the local directory first, and then writes an annotated copy elsewhere, which is presumably picked up by some other background job which puts cutesy little exclamation marks into the notification area or something similar.

In principle, this isn’t all that terrible — after all, general users wouldn’t know a core dump if it bit them on the rear (and you really wouldn’t want a dump biting you in the rear). However, one rather crucial problem is that it ignores any previously set value of core_pattern and simply dumps its own value over it. The script always attempts to dump the core file into the current directory, regardless of the old value of core_pattern.

This is a bit of an issue because I use union mounts for building software, to avoid cluttering up my source directories with build artifacts, and these often confuse the kernel when it tries to generate core dumps. As a result, I change core_pattern to the following to store all core dumps in a central location:


This worked fine until I rebooted for some reason and suddenly apport stuck its ugly nose in.

Anyway, fortunately it’s pretty easy to disable. First edit /etc/default/apport and set enabled to 0:

# set this to 0 to disable apport, or to 1 to enable it
# you can temporarily override this with
# sudo service apport start force_start=1

Then, just stop the service:

sudo service apport stop

At this point you’ll want to check that it’s restored the value of core_pattern to something sensible, and update it yourself if not.

That’s one more developer annoyance in Ubuntu taken care of.

29 Jan 2013 at 1:16PM by Andy Pearce in Software  | Photo by Anna Goncharova on Unsplash  | Tags: linux  ubuntu debugging  |  See comments

☑ Bash expansion weirdness

Expanding a substring of “$*” in bash seems to magically add command-line parameter zero.

inflatable flamingo

Here’s a quirky one. In the bash shell, "$*" expands to a single string which is a whitespace-separated list of arguments starting at one. So if you have the following script as script.sh:

echo Arguments: "$*"

… and you call it as script.sh arg1 arg2 arg3 then you’ll get the following output:

Arguments: arg1 arg2 arg3

So far so tedious. However, if we use some of bash’s parameter expansion rules to select a substring (in this case the substring starting at zero, or the whole string in fact):

echo Arguments: "${*:0}"

… then suddenly you get parameter zero (the filename of the script) included:

Arguments: ./script.sh arg1 arg2 arg3

I’m not sure if that’s a bug or I’m missing some subtlety and it’s expected behaviour, but it’s one of those issues that’s pretty tough to Google around so I suspect it’ll remain a mystery.

25 Jan 2013 at 11:12AM by Andy Pearce in Software  | Photo by Vicko Mozara  | Tags: linux bash  |  See comments

⇐ Page 1   |   ← Page 5   |   Page 6 of 6