kern/122318 (CMake core dumping, chroot exiting)

[Chagin Dmitry]

On Fri, 25 Jul 2008, Roman Divacky wrote:

> 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...
>

yes, but I remember it was a question about chroot...

Sean, can you provide full command which you run?

-- 
Have fun!
chd