"*** [kernel.debug] Error code 139"?

Mark Johnston markj at freebsd.org
Fri Jan 9 01:57:10 UTC 2015


On Thu, Jan 8, 2015 at 5:42 PM, Bjoern A. Zeeb
<bzeeb-lists at lists.zabbadoz.net> wrote:
>
>> On 08 Jan 2015, at 18:46 , Mark Johnston <markj at freebsd.org> wrote:
>>
>> On Thu, Jan 08, 2015 at 07:27:10PM +0100, Dimitry Andric wrote:
>>> On 08 Jan 2015, at 16:24, Mark Johnston <markj at freebsd.org> wrote:
>>>>
>>>> On Thu, Jan 08, 2015 at 02:06:16PM +0000, Bjoern A. Zeeb wrote:
>>> ...
>>>>> It only started 2 nights ago and we are both doing daily builds.  Unlikely that stuff from November would do it oh so suddenly.
>>>>>
>>>>> It’s hard to exactly narrow it down as there was a lot of other breakage in the tree but I know that r276729 finished a full universe and I hadn’t noticed the problem before.  So I would almost assume it was something after that (but obviously it could be a combination of things).
>>>>
>>>> Ok, I was able to reproduce the crash by cross-compiling i386 on amd64.
>>>> Reverting r274569 made it go away for me. I'm going to try a few more
>>>> times to see if it's consistent.
>>>
>>> Same here, reverting r274569 makes it work again.
>>
>> I've reverted it in r276848.
>
> So I may revert this reverted changed locally again and see, as the universe before your “backout” went through smoothly;  I’d rather understand the root-cause that triggers this then having something I don’t quite understand why it started to happen 8 weeks after a change…

Me too. Apparently my change was interacting badly with the type graph
of recent i386 GENERIC kernels. I don't think that r274569 is
fundamentally incorrect, but I clearly missed something, and didn't
have the cycles to investigate right away (ctfmerge can be quite
time-consuming to debug in my experience).

Given that the change was breaking the build, I opted to revert it
quickly. This weekend, I'll try to figure out what actually happened.


More information about the freebsd-current mailing list