linux-kernel - Re: linux-next: Tree for Nov 1 (xconfig problem)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Nov 2015 10:48:00 -0800
From:	Randy Dunlap <rdunlap@...radead.org>
To:	Thiago Macieira <thiago.macieira@...el.com>
Cc:	Michal Marek <mmarek@...e.cz>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	Boris Barbulovski <bbarbulovski@...il.com>
Subject: Re: linux-next: Tree for Nov 1 (xconfig problem)

On 11/02/15 08:58, Thiago Macieira wrote:
> On Monday 02 November 2015 08:44:01 Randy Dunlap wrote:
>>> Randy, we need a backtrace. The problem is on the function that called
>>> first(). Can you make sure the crash generates a core dump, then get the
>>> bt
>>> from that?
>>
>> ASSERT: "!isEmpty()" in file /usr/include/QtCore/qlist.h, line 282
>> ../scripts/kconfig/Makefile:22: recipe for target 'xconfig' failed
>> make[2]: *** [xconfig] Aborted (core dumped)
> [cut]
>> #4  0x00007f858c3eec44 in qFatal(char const*, ...) ()
>>     at /usr/lib64/libQtCore.so.4
>> #5  0x00007f858c3eec8a in  () at /usr/lib64/libQtCore.so.4
>> #6  0x00000000004206cc in ConfigList::updateSelection() ()
> 
> Thanks, Randy.
> 
> This seems to be it:
> 
>         if (selectedItems().count() == 0)
>                 return;
> 
>         ConfigItem* item = (ConfigItem*)selectedItems().first();
> 
> Which means this shouldn't be happening. I don't know how the list could be 
> non-empty in one call and empty in the next.  It's wasteful to call 
> selectedItems() twice (it's not a cheap function), but it shouldn't cause this 
> issue.
> 
> We can easily just cache the result and this is what the attached patch does, 
> but given that this error makes no sense to me, I cannot guarantee that you 
> don't have another problem elsewhere.
> 
> Boris, do you have another idea?
> 

Hi,
What does this patch apply to?
I can't apply it cleanly to to 4.3 or linux-next of yesterday or today.

thanks,

-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/