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

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

[Randy Dunlap]

On 11/01/15 08:53, Stephen Rothwell wrote:
> Hi all,
> 
> I start again a day early, and this is how you all repay me? ;-)
> 
> Changes since 20151022:
> 

on x86_64:

'make xconfig' dies a quick death when I try to use it:

linux-next-20151101> ASSERT: "!isEmpty()" in file /usr/include/QtCore/qlist.h, line 282


-- 
~Randy

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

[Michal Marek]

On 2015-11-02 04:11, Randy Dunlap wrote:
> On 11/01/15 08:53, Stephen Rothwell wrote:
>> Hi all,
>>
>> I start again a day early, and this is how you all repay me? ;-)
>>
>> Changes since 20151022:
>>
> 
> on x86_64:
> 
> 'make xconfig' dies a quick death when I try to use it:
> 
> linux-next-20151101> ASSERT: "!isEmpty()" in file /usr/include/QtCore/qlist.h, line 282

Added Boris and Thiago to Cc.

Are you using Qt4 or Qt5? An

  ldd scripts/kconfig/qconf | grep Qt

will tell you.

Michal

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

[Thiago Macieira]

On Monday 02 November 2015 14:39:16 Michal Marek wrote:
> On 2015-11-02 04:11, Randy Dunlap wrote:
> > On 11/01/15 08:53, Stephen Rothwell wrote:
> >> Hi all,
> >> 
> >> I start again a day early, and this is how you all repay me? ;-)
> > 
> >> Changes since 20151022:
> > on x86_64:
> > 
> > 'make xconfig' dies a quick death when I try to use it:
> > 
> > linux-next-20151101> ASSERT: "!isEmpty()" in file
> > /usr/include/QtCore/qlist.h, line 282
> Added Boris and Thiago to Cc.
> 
> Are you using Qt4 or Qt5? An

Given the line number, it's a Qt 4.

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?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Randy Dunlap]

On 11/02/15 05:39, Michal Marek wrote:
> On 2015-11-02 04:11, Randy Dunlap wrote:
>> On 11/01/15 08:53, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> I start again a day early, and this is how you all repay me? ;-)
>>>
>>> Changes since 20151022:
>>>
>>
>> on x86_64:
>>
>> 'make xconfig' dies a quick death when I try to use it:
>>
>> linux-next-20151101> ASSERT: "!isEmpty()" in file /usr/include/QtCore/qlist.h, line 282
> 
> Added Boris and Thiago to Cc.
> 
> Are you using Qt4 or Qt5? An
> 
>   ldd scripts/kconfig/qconf | grep Qt
> 
> will tell you.

says:
	libQtGui.so.4 => /usr/lib64/libQtGui.so.4 (0x00007f08ee704000)
	libQtCore.so.4 => /usr/lib64/libQtCore.so.4 (0x00007f08ee219000)


-- 
~Randy

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

[Randy Dunlap]

On 11/02/15 05:51, Thiago Macieira wrote:
> On Monday 02 November 2015 14:39:16 Michal Marek wrote:
>> On 2015-11-02 04:11, Randy Dunlap wrote:
>>> On 11/01/15 08:53, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> I start again a day early, and this is how you all repay me? ;-)
>>>
>>>> Changes since 20151022:
>>> on x86_64:
>>>
>>> 'make xconfig' dies a quick death when I try to use it:
>>>
>>> linux-next-20151101> ASSERT: "!isEmpty()" in file
>>> /usr/include/QtCore/qlist.h, line 282
>> Added Boris and Thiago to Cc.
>>
>> Are you using Qt4 or Qt5? An
> 
> Given the line number, it's a Qt 4.
> 
> 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)


(gdb) bt
#0  0x00007f858b7e5187 in raise () at /lib64/libc.so.6
#1  0x00007f858b7e6538 in abort () at /lib64/libc.so.6
#2  0x00007f858c3ee2b4 in qt_message_output(QtMsgType, char const*) ()
    at /usr/lib64/libQtCore.so.4
#3  0x00007f858c3ee439 in  () at /usr/lib64/libQtCore.so.4
#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() ()
#7  0x0000000000420758 in ConfigList::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.51] ()
#8  0x00007f858c50e1fa in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib64/libQtCore.so.4
#9  0x00007f858cfa7818 in  () at /usr/lib64/libQtGui.so.4
#10 0x00007f858c50e1fa in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib64/libQtCore.so.4
#11 0x00007f858cf83087 in QItemSelectionModel::selectionChanged(QItemSelection const&, QItemSelection const&) () at /usr/lib64/libQtGui.so.4
#12 0x00007f858cf886c1 in QItemSelectionModel::emitSelectionChanged(QItemSelection const&, QItemSelection const&) () at /usr/lib64/libQtGui.so.4
#13 0x00007f858cf88e93 in QItemSelectionModel::select(QItemSelection const&, QFlags<QItemSelectionModel::SelectionFlag>) () at /usr/lib64/libQtGui.so.4
#14 0x00007f858cf833f6 in QItemSelectionModel::clearSelection() ()
---Type <return> to continue, or q <return> to quit---
    at /usr/lib64/libQtGui.so.4
#15 0x00007f858c50e1fa in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib64/libQtCore.so.4
#16 0x0000000000426057 in ConfigList::focusInEvent(QFocusEvent*) ()
#17 0x00007f858ca8e8c9 in QWidget::event(QEvent*) ()
    at /usr/lib64/libQtGui.so.4
#18 0x00007f858ce2b5ee in QFrame::event(QEvent*) () at /usr/lib64/libQtGui.so.4
#19 0x00007f858cea7b7b in QAbstractScrollArea::event(QEvent*) ()
    at /usr/lib64/libQtGui.so.4
#20 0x00007f858cf3aadb in QAbstractItemView::event(QEvent*) ()
    at /usr/lib64/libQtGui.so.4
#21 0x00007f858ca3f76c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQtGui.so.4
#22 0x00007f858ca45cad in QApplication::notify(QObject*, QEvent*) ()
    at /usr/lib64/libQtGui.so.4
#23 0x00007f858c4fa2ad in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQtCore.so.4
#24 0x00007f858ca43eea in QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) () at /usr/lib64/libQtGui.so.4
#25 0x00007f858ca89d7b in QWidget::setFocus(Qt::FocusReason) ()
    at /usr/lib64/libQtGui.so.4
#26 0x00007f858ca46cc0 in QApplication::notify(QObject*, QEvent*) ()
    at /usr/lib64/libQtGui.so.4
---Type <return> to continue, or q <return> to quit---
#27 0x00007f858c4fa2ad in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQtCore.so.4
#28 0x00007f858cab34bf in  () at /usr/lib64/libQtGui.so.4
#29 0x00007f858cab717c in  () at /usr/lib64/libQtGui.so.4
#30 0x00007f858cab570c in QApplication::x11ProcessEvent(_XEvent*) ()
    at /usr/lib64/libQtGui.so.4
#31 0x00007f858cadc5c2 in  () at /usr/lib64/libQtGui.so.4
#32 0x00007f858b2d0a04 in g_main_context_dispatch ()
    at /usr/lib64/libglib-2.0.so.0
#33 0x00007f858b2d0c48 in  () at /usr/lib64/libglib-2.0.so.0
#34 0x00007f858b2d0cec in g_main_context_iteration ()
    at /usr/lib64/libglib-2.0.so.0
#35 0x00007f858c5270be in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
#36 0x00007f858cadc676 in  () at /usr/lib64/libQtGui.so.4
#37 0x00007f858c4f8e6f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
#38 0x00007f858c4f9165 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
#39 0x00007f858c4fe5b9 in QCoreApplication::exec() ()
    at /usr/lib64/libQtCore.so.4
#40 0x000000000040d1dd in main ()


-- 
~Randy

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

[Thiago Macieira]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

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?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

[-- Attachment #2: 0001-Cache-the-result-of-QTreeWidget-selectedItems.patch --]
[-- Type: text/x-patch, Size: 970 bytes --]

From 32426c8282d0ec48f20000bc8e9a9c89c3060c8d Mon Sep 17 00:00:00 2001
From: Thiago Macieira <thiago.macieira@intel.com>
Date: Mon, 2 Nov 2015 11:55:56 -0500
Subject: [PATCH 1/1] Cache the result of QTreeWidget::selectedItems()

It's not a cheap function, so let's not call it twice.

Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
---
 scripts/kconfig/qconf.cc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 91b7e6f..920a252 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -400,10 +400,11 @@ void ConfigList::updateSelection(void)
 	struct menu *menu;
 	enum prop_type type;
 
-	if (selectedItems().count() == 0)
+	QList<QTreeWidgetItem *> items = selectedItems();
+	if (items.count() == 0)
 		return;
 
-	ConfigItem* item = (ConfigItem*)selectedItems().first();
+	ConfigItem* item = (ConfigItem*)items.first();
 	if (!item)
 		return;
 
-- 
2.6.2

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

[Randy Dunlap]

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

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

[Thiago Macieira]

On Monday 02 November 2015 10:48:00 Randy Dunlap wrote:
> Hi,
> What does this patch apply to?
> I can't apply it cleanly to to 4.3 or linux-next of yesterday or today.

Hmm... interesting, it doesn't apply on linux-next. The reason for that is 
that the code on linux-next is different from the one on the tip of the branch 
that I sent to Michal. The difference explains the crash too and why I thought 
it was impossible.

Michal, looks like you missed applying patch #28 "Add current selection 
check." from the original series. It's one of three commits that don't start 
with "Port xconfig to Qt5", so I guess it was  missed. It's the only commit 
missing (you applied 38 and the series had 39).

http://www.spinics.net/lists/linux-kbuild/msg11665.html
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

[Michal Marek]

Dne 2.11.2015 v 20:23 Thiago Macieira napsal(a):
> On Monday 02 November 2015 10:48:00 Randy Dunlap wrote:
>> Hi,
>> What does this patch apply to?
>> I can't apply it cleanly to to 4.3 or linux-next of yesterday or today.
> 
> Hmm... interesting, it doesn't apply on linux-next. The reason for that is 
> that the code on linux-next is different from the one on the tip of the branch 
> that I sent to Michal. The difference explains the crash too and why I thought 
> it was impossible.
> 
> Michal, looks like you missed applying patch #28 "Add current selection 
> check." from the original series. It's one of three commits that don't start 
> with "Port xconfig to Qt5", so I guess it was  missed. It's the only commit 
> missing (you applied 38 and the series had 39).
> 
> http://www.spinics.net/lists/linux-kbuild/msg11665.html

Damn, I guess I forgot to select this patch in mutt and the rest applied
without conflicts :-/. Thanks for spotting it, I will add the missing patch.

Michal