On Wed, 24 Aug 2011 18:55:43 +0200 Lennart Poettering <lenn...@poettering.net> wrote:
> On Wed, 24.08.11 21:40, Mike Kazantsev (mk.frag...@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
gdb.out
Description: Binary data
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel