Here is a comment from the Upstart changelog which attempts to explain the scenario leading to the out-of-memory condition:
* init/job.c: job_new(): Fix for nasty OOM scenario when an attempt is made
to start a chroot job with same name as running single-instance non-chroot
job. Previously, the path for a chrooted Job was set from the (nul) instance
name of its parent JobClass. However, since that job instance name already
existed outside the chroot and was already D-Bus registered, nih_dbus_object_new() (which allocates storage and is called by job_register()) returned NULL and kept doing so due to being called
within NIH_MUST(). This resulted in OOM due to an as-yet unidentified
D-Bus bug (possibly a leak in find_subtree_recurse()).
Here is a comment from the Upstart changelog which attempts to explain the scenario leading to the out-of-memory condition:
* init/job.c: job_new(): Fix for nasty OOM scenario when an attempt is made
nih_ dbus_object_ new() (which allocates storage and is called by
job_ register( )) returned NULL and kept doing so due to being called recurse( )).
to start a chroot job with same name as running single-instance non-chroot
job. Previously, the path for a chrooted Job was set from the (nul) instance
name of its parent JobClass. However, since that job instance name already
existed outside the chroot and was already D-Bus registered,
within NIH_MUST(). This resulted in OOM due to an as-yet unidentified
D-Bus bug (possibly a leak in find_subtree_