kern/122318 (CMake core dumping, chroot exiting)

[Roman Divacky]

On Fri, Jul 25, 2008 at 10:21:56AM +0200, Roman Divacky wrote:
> On Wed, Jul 23, 2008 at 04:19:16PM -0500, Sean C. Farley wrote:
> > On Thu, 24 Jul 2008, Chagin Dmitry wrote:
> > 
> > >On Wed, 23 Jul 2008, Sean C. Farley wrote:
> > >>On Wed, 23 Jul 2008, Roman Divacky wrote:
> > >>>On Wed, Jul 23, 2008 at 12:50:51PM -0500, Sean C. Farley wrote:
> > >>>>I am seeing if anyone has any insight on this PR (kern/122318[1]).
> > >>>>It would be nice to once again build using cmake within a Linux
> > >>>>chroot.  :)
> > >>>>
> > >>>>Basically, the bug is that not only that cmake is dumping core; it
> > >>>>is also forcing the user out of the chroot environment.  Here is
> > >>>>the command used to start the chroot:
> > >>>>/compat/linux/usr/sbin/chroot <chroot path> su - <build user>
> > >>>>
> > >>>>  1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
> > >>>
> > >>>looking at the trace you provided I guess this is what's going on:
> > >>>
> > >>>cmake forks/execs gcc and waits to be notified about the success of
> > >>>the command it tried, the notification comes (the SIGCHLD) the
> > >>>handler tries do something and then returns and now something is
> > >>>wrong and it receives the SIGSEGV..
> > >>>
> > >>>or am I wrong and linux_ktrace does not translate signals and the
> > >>>SIGCHLD is in fact SIGTSTP?
> > >>>
> > >>>what is the fd 3 and 4? can you provide full ktrace.out?
> > >>
> > >>I have the full output of the execution here using ktrace -d:
> > >>http://www.farley.org/freebsd/tmp/cmake-kdump.txt
> > >
> > >hi!
> > >
> > >Please, can you run ktrace with -i flag?
> > >
> > >thnx!
> > 
> > No problem.  Same URL.  The countless meetings this week are destroying
> > my mind; I was thinking -d did what -i actually does.  :)
> 
> the cmake opens:
> 
>  18279 ld       CALL  linux_open(0x7fffffffe5b4,0,0x1b6)
>  18279 ld       NAMI  "/usr/lib/crtend.o"
>  18279 ld       RET   linux_open 3
> 
> which is obviously wrong and probably causes the regression.. how is this possible I dont
> know.
> 
> anyway, the trace is all strange...
> 
> 1) it uses getpmsg/putpmsg which are unimplemented (hows that it work? does it
> work or just pretends to?)
> 
> 2) what is this?
> 
>  18267 gmake    CALL  [417](0x7fffffffcf90)
>  18267 gmake    RET   [417] JUSTRETURN
>  18267 gmake    CALL  linux_waitpid(0xffffffff,0x7fffffffd3f4,0,0)
>  18267 gmake    RET   linux_waitpid 18277/0x4765
>  18267 gmake    CALL  [340](0x1,0x529d90,0)
>  18267 gmake    RET   [340] 0
>  18267 gmake    CALL  [340](0x3,0x7fffffffd3c0,0)
>  18267 gmake    RET   [340] 0
> 
> 
> anyway, try to investigate why the cmake does not open crtend.o under /compat but uses
> fbsd one, that should fix the proble I believe

erm... all wrong :) the gmake is a fbsd binary so its ok to open that file...