On 2 Jan, this message from Michael Schmitz echoed through cyberspace: >> So the segfault happens between make recursion depth changes (that's >> what's in brackets, right?). I tried running make under gdb, but since >> it spawns another make (which spawns another one), those childs are not >> running under gdb. > > Isn't there a way to force gdb to attach to child processes as well?
Only for HP-UX. For other OSes, you can try stopping the child and then attaching gdb to it before continuing execution. > Either way, gdb might be able to tell you which child signaled, at least. You can see that from make's output already ;-) It's indeed make. >> I'd run the command that segfaults directly, if I knew which one? Hm, >> make -n comes to mind... I'll have to see what that gives. > > -n won't do anything so I'm not sure it'll act just as make (in case > targets get updated). Add a few echo "yadda" around the makefile to see > where it happens. Well, for sure make -n dep segfaults as well. Not always in the same spot, but always. Repeatedly executing make -n dep tends to go further and further in the process. It also makes it clear that it's indeed make that segfaults: it's within a sequence of terminating childs that it segfaults. >> > I'd blame libc though I really can't put a finger on why :-) If it's not a >> > bad memory issue. mkdep uses realloc quite a lot. >> >> Still: why is _nothing_ else crashing on this machine? During the >> complete install process, running netscape, mozilla, konqueror, what >> not... has not shown a single segfault. > > What's make doing that's different from all other apps, other than forking > like hell and changing directory a lot? You tell me ;-) Cheers Michel ------------------------------------------------------------------------- Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes | Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED] | http://www.cpu.lu/~mlan | Learn Always. "
