[systemd-devel] Unit failed to load: Cannot allocate memory.

[Mike Kazantsev]

On Wed, 24 Aug 2011 18:55:43 +0200
Lennart Poettering <lennart at poettering.net> wrote:

> On Wed, 24.08.11 21:40, Mike Kazantsev (mk.fraggod at gmail.com) wrote:
> 
> > > > Reexec reacts on these units right before "Deserializing state..." msg,
> > > > with the same messages.
> > > > I'll check whether they go away on reexec to 32 and reappear in 33, and
> > > > if that's the case, will have results shortly.
> > > 
> > > Can you reproduce this issue when you run "systemd --test --system" as
> > > normal user after boot?
> > > 
> > 
> > Yes, seem 100% reproducable that way. Same units, same errors.
> > 
> > Looks like it can be (relatively) easily debugged with stuff like gdb
> > now, I'll see if I can come up with conditional breakpoint for failed
> > mallocs.
> > Haven't really used gdb for anything but crash backtraces though, so any
> > suggestions are welcome.
> 
> My recommendation would be to start gdb, then do "b strerror" which will
> set a breakpoint on strerror() which we'll only call if there's
> soemthing wrong. Then do "r" to run the app. You might have to skip over
> a couple of strerror invocations with "c" until you find the one that
> results in memory error. Use "n" to step over function calls, and "s" to
> step into function calls. Use "l" to figure out where you are and "bt"
> to get a backtrace. And that's gdb in a nutshell...
> 

Thanks for the pointers, especially that strerr() breakpoint part.

There are several spots when the strerr() is called.

First, there is some stuff like this:

  Failed to set hostname to <damnation>: Operation not permitted
  Netlink failure for request 1: Operation not permitted
  Failed to configure loopback device: Operation not permitted
  Failed to enable ctrl-alt-del handling: Operation not permitted
  Failed to open /dev/tty0: Permission denied

Second is unit_load() (same number of times as the number of failed
units), where it's called, but nothing is printed.
Next is unit_dump(), when "Loaded:" state of the unit is printed.

I assumed error I'm looking for should be in unit_load(), so I've found
first unit_load call where strerror() gets called (u=0x83af00, seem to
be constant on subsequent runs) and tried to step through it, although
result was a bit unexpected - some assert() call in unit_load_fragment
has failed and systemd was terminated by SIGABRT.

Not sure if it's gdb influence that gives such abnormal behavior, but I
guess the place should be pretty much the same, since I can step
through other random unit_load calls w/o any problem.

gdb output with stepping-through and "bt full" is attached.

I'll try to look into meta.id assignment process a bit later.


-- 
Mike Kazantsev // fraggod.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.out
Type: application/octet-stream
Size: 5088 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110825/91d79ca7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110825/91d79ca7/attachment.pgp>