Jeremy C. Reed wrote:
I am trying to figure out where an abort core dump in imake is coming
from, so I do:
For a core dump, you should be able to get a nice backtrace from the dump.
(gdb) n
458 cppit(cleanedImakefile, Template, ImakefileC, tmpfd,
tmpMakefile);
(gdb) n
So now I have a new process id.
Are are you sure you have the new process id? Are you also sure that the
child process is still running? It might finish before you can attach to it.
Looking at source I see for its get_stackprotector:
1059 }
1060 if (pclose(fp))
1061 abort();
1062 }
imake assumes the cc -v output is several lines.
Why would pclose fail in this case?
So I see where the problem is probably at -- but can someone teach me how
to find it with gdb itself?
That's not so easy. We'd need to have gdb's follow-fork-mode, which lets
you choose to debug the child instead. As we don't have it, you might use
this "trick": Add a sleep(10) to the child directly after the fork. Then
you have some time to attach to the child. I don't like this, but it
seems to be the only possibility so far.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
