[kdevplatform] [Bug 371210] patch review shouldn't add files it opens to the recent files menu

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371210

RJVB  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Latest Commit||http://commits.kde.org/kdev
   ||platform/3c559df38551ba0a06
   ||54e944ea2b68dd4b85a15d

--- Comment #2 from RJVB  ---
Git commit 3c559df38551ba0a0654e944ea2b68dd4b85a15d by René J.V. Bertin.
Committed on 21/10/2016 at 14:51.
Pushed by rjvbb into branch 'master'.

add an IDocumentController::DocumentActivation flag to control adding
documents to the "Files/Open Recent" menu and use it in the patchreview
plugin to prevent pollution of said menu.
DocumentController::activateDocument() no longer adds the target document
to the Open Recent menu; use DocumentController::openDocument() for that.
Additionally, the patch review plugin now handles the hardwired maximum
number of files to open (15) correctly, instead of opening no files when
that maximum is exceeded.

REVIEW: 129231

M  +2-1interfaces/idocumentcontroller.h
M  +21   -19   plugins/patchreview/patchreview.cpp
M  +7-2plugins/patchreview/patchreviewtoolview.cpp
M  +2-2shell/documentcontroller.cpp
M  +2-0shell/documentcontroller.h

http://commits.kde.org/kdevplatform/3c559df38551ba0a0654e944ea2b68dd4b85a15d

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 371210] patch review shouldn't add files it opens to the recent files menu

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371210

RJVB  changed:

   What|Removed |Added

URL||https://git.reviewboard.kde
   ||.org/r/129231/

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 371210] patch review shouldn't add files it opens to the recent files menu

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371210

RJVB  changed:

   What|Removed |Added

   Severity|wishlist|normal

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 371210] patch review shouldn't add files it opens to the recent files menu

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371210

--- Comment #1 from RJVB  ---
Created attachment 101650
  --> https://bugs.kde.org/attachment.cgi?id=101650=edit
patch review temporary patchfiles in the recent files menu

The large number of changed files that overwrote my recent files menu contents
hid another thing that I think is a real and recent regression: the presence of
the patch files themselves in the recent files menu.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 371228] enable remote search on IMAP servers

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371228

--- Comment #1 from RJVB  ---
Created attachment 101647
  --> https://bugs.kde.org/attachment.cgi?id=101647=edit
a first draft for enabling remote search in the QuickSearch toolbar. WIP!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 371228] enable remote search on IMAP servers

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371228

RJVB  changed:

   What|Removed |Added

 CC||d...@newtech.fi

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 371228] New: enable remote search on IMAP servers

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371228

Bug ID: 371228
   Summary: enable remote search on IMAP servers
   Product: kmail2
   Version: unspecified
  Platform: Other
OS: other
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: message list
  Assignee: kdepim-b...@kde.org
  Reporter: rjvber...@gmail.com

Dan suggested on the kdepim-users ML that someone might want to submit a
wishticket for a feature to allow remote search on IMAP servers, all the more
since support for the feature is already implemented but dormant.

In his words: 

> maybe we could add a checkbox to the "Quick Search" to enable it and allow 
> full-text search in a specific folder even if the bodies are not available
> locally. Would not work for the "Search" dialog though.

I've taken the bait, so here's the wish ticket :)



Reproducible: Always

Steps to Reproduce:
Do a search in an IMAP folder which isn't configured to download all message
bodies.

Actual Results:  
Messages not available locally are skipped

Expected Results:  
Those messages could be included on user request

I've started to implement the feature. As I'm still using 4.14 that's the code
base I'm using, but I suppose that porting should be relatively
straightforward.

The available support I've been able to find is part of
Akonadi::SearchCreateJob, so that's what I've tried to use. Currently I'm
getting a "cannot create persistent search" error, and I'm still stuck at how
to get the actual results from the returned collection, but I hope it's a
start.

I'm not entirely sure why remote search couldn't be part of the "Search"
dialog, given that the underlying code uses classes that support remote
search??

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 371210] New: patch review shouldn't add files it opens to the recent files menu

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371210

Bug ID: 371210
   Summary: patch review shouldn't add files it opens to the
recent files menu
   Product: kdevplatform
   Version: unspecified
  Platform: Compiled Sources
OS: All
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: patchreview
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com
CC: david.nolden@art-master.de

The patch review plugin can open quite a few files, which aren't always files
you have been editing - for instance when you rename a directory and commit the
resulting change (which KDevelop sadly records as separate delete/create events
rather than renames which git does support).

When you commit or review changes to a file you've been editing that file will
most likely already be in the recent files menu, or at least it won't surprise
appearing there. If however that change has been pending for some time there
still isn't much of a reason to add the file to the list of recent documents.

Reproducible: Always

Steps to Reproduce:
1. commit or review changes that include files you haven't touched for a while
or at all (other than renaming them or the directory they live in)
2. close the review toolview
3. try to open a file from the recent files menu

Actual Results:  
If the patch review concerned enough files, the whole recent files menu will be
populated with the reviewed files. This just happened to me, and it took me a
while to understand why the list contained only unfamiliar files all of a
sudden.

Expected Results:  
Ideally the recent files menu would only contain files you have actually opened
yourself

Supposing it is not trivial to decide on the fly whether or not a file being
opened should be added to the recent files menu, this could be achieved more or
less easily by (order of personal preference):

- opening only the patchfile in review mode and letting the user open any
modified file s/he is interested in by double-clicking in the list of modified
files (which is an existing functionality)
- maintaining separate lists of recent files for the review and other modes.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 340813] sometimes two copies of mysqld are running with Akonadi

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=340813

RJVB  changed:

   What|Removed |Added

 CC||rjvber...@gmail.com

--- Comment #13 from RJVB  ---
So here's an additional observation, from 4.13.3/ akonadi 1.13.1 but maybe
still useful.
As I just reported in a duplicate (https://bugs.kde.org/show_bug.cgi?id=367638)
I get the 1452 error even when I don't have 2 mysql daemons running. Not
continuously at least.

Looking at it today I first thought that they were generated only after a full
sync (Ctrl-L) but then I noticed the error messages also appeared while I was
browsing an email and no sync activity was occurring.
I then made the link with the search folder I created yesterday, which was
designed to combine the entries from several folders in a virtual folder. For
that, I defined a search working on the folders of interest and returning all
items with a total size >= 0kb. I left the 2nd field empty.

When I deleted that search folder the error messages disappeared, but the
unread email in one of the target folders disappeared too. From kmail; Claws
shows they're still there, fortunately.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 367638] DATABASE ERROR: 1452

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=367638

RJVB  changed:

   What|Removed |Added

 CC||rjvber...@gmail.com

--- Comment #2 from RJVB  ---
I wouldn't be so sure that this error only occurs when 2 mysql daemons are
running. I've been seeing this for ages with 14.3.3 and 14.4 (git/head) with
the latest akonadi 1.13.1. For a while now my Linux rig (4.13.3) has been
immune to it and only my OS X system gave the errors. They disappeared from
(and now reappeared on) the Linux system after some combination of fsck and
vacuum, and I think the same may have happened on OS X.

just for kicks, this is what I currently see on my akonadi terminal after each
complete sync (Ctrl-L). I must assume there's potentially a single folder in my
list which is the culprit, but I have a bit too many of them to do manual
refreshes one by one to find the trouble folder(s).

DATABASE ERROR:
Error code: 1452
DB error:  "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)"
Error text: "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to
execute statement"
Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id)
VALUES (:0, :1)"
DATABASE ERROR:
Error code: 1452
DB error:  "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)"
Error text: "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to
execute statement"
Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id)
VALUES (:0, :1)"
DATABASE ERROR:
Error code: 1452
DB error:  "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)"
Error text: "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to
execute statement"
Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id)
VALUES (:0, :1)"
DATABASE ERROR:
Error code: 1452
DB error:  "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)"
Error text: "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to
execute statement"
Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id)
VALUES (:0, :1)"
DATABASE ERROR:
Error code: 1452
DB error:  "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)"
Error text: "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to
execute statement"
Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id)
VALUES (:0, :1)"
DATABASE ERROR:
Error code: 1452
DB error:  "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)"
Error text: "Cannot add or update a child row: a foreign key constraint fails
(`akonadi`.`collectionpimitemrelation`, CONSTRAINT
`collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES
`pimitemtable` (`id`) ON 

[kontact] [Bug 370646] Crash because of stale (dangling) pointers in the attribute registry

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

RJVB  changed:

   What|Removed |Added

URL||http://arstechnica.com/civi
   ||s/viewtopic.php?p=32070659#
   ||p32070659

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 370646] Crash because of stale (dangling) pointers in the attribute registry

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

--- Comment #8 from RJVB  ---
This bug has gotten under my skin. Having looked at this a bit more and asking
around a bit, the most likely explanation for the crash is this:

- KCModuleLoader::loadModule() loads the library to get a pointer to the
create_ function. The library registers its attributes.
- libnoteshared (or the kcm depending on it) doesn't have such a function, and
so KCModuleLoader::loadModule() unloads the library again
- somewhat thereafter, the library (and/or the kcm depending on it) is loaded
once more, and again registers its attributes
- the attribute factory finds a previous registration, and attempts to delete
the registered attributes
- since the library was unloaded and reloaded since those attributes were
"new'ed", the dtor lives (potentially) at a different address.
- delete *it invokes the dtor ... which may SEGV if the dtor address has
changed.

I see that `KCModuleLoader::loadModule()` has hardly changed and not at all in
the aspects outlined above. IOW, this bug is likely to occur in KDE PIM5 too if
libnoteshared hasn't obtained a create_ function since.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 370646] Crash because of stale (dangling) pointers in the attribute registry

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

RJVB  changed:

   What|Removed |Added

Summary|Crash when opening Kontact  |Crash because of stale
   |preferences |(dangling) pointers in the
   ||attribute registry

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #15 from RJVB  ---
Let's just hope that it's the only fix required. As I said, it's not like I had
systematic error messages about the dynamic_cast or even systematic failures,
making this somewhat of a Heisenbug.
I'll be running the additional protection in ClangProblem::allFixits for the
time being.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #11 from RJVB  ---
Created attachment 101587
  --> https://bugs.kde.org/attachment.cgi?id=101587=edit
Give IProblem public visibility.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #10 from RJVB  ---
For now the patch below seems to be a proper fix but I cannot vouch if it's a
definite fix too.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #9 from RJVB  ---
So, changing the "assert's" else clause to

const auto ptr = diagnostic.data();
qWarning() << Q_FUNC_INFO << "dynamic cast to ClangProblem failed
of" << ptr
<< "type" << typeid(*ptr).name();

I now see:

ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7f953f2d1b98 type 12ClangProblem

which means that it's really the dynamic_cast that fails, not the input type
that is wrong.

It does seem that the dynamic_cast succeeds sometimes, but even then I see the
dynamic_cast error appear in the system.log. I'd forgotten that this message
doesn't appear when I use a newer libc++ than the one from OS X 10.9 ...

For now failure or success of the dynamic_cast seems to be random, or maybe
even determined when the code is built. I certainly hope there a proper fix for
that (and independent of libc++ version).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #8 from RJVB  ---
BTW, I see that ClangProblem already has a KDEVCLANGPRIVATE_EXPORT macro in its
definition; its parents have KDEVPLATFORMLANGUAGE_EXPORT except for IProblem.

Am I correct that this changes your proposition to add KDEVBLUBB_EXPORT macros?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #7 from RJVB  ---
Ok, let's not call it a fix then, but a sensible protection.

It's still wrong to just let code fail somewhere down the line by allowing it
to dereference a null pointer. And if the dynamic_cast isn't required it could
simply be skipped in production builds ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 370646] Crash when opening Kontact preferences

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

--- Comment #7 from RJVB  ---
I see there's been a chronological glitch in my comments :-/

I wonder: shouldn't it be more elegant to do the actual unregistering
(attributes.erase(x)) in the Attribute dtor? I'll need to check if the
Attribute dtor is actually called when libnoteshared is unloaded and that
apparently leads to freeing memory allocated ("new'ed") by that library. If it
is, a lot of the above patches will be handled automatically.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #5 from RJVB  ---
What can possibly wrong about the fix? If a variable shouldn't be NULL and
there are apparently reasons why it can happen outside of reasonable
precautions, NOT checking is wrong. 

And clearly this is NOT a situation where an occasional failing dynamic_cast is
something from which you cannot recover (i.e. it's a transient failure), so
there's no need to abort when it happens in code built in production mode. And
IMHO that's independent from a possible fix for *this* case of failing
dynamic_cast.

I can try to add the macro to both ClangProblem and the other mentioned class
to see if that changes anything. Do I have to include anything additional or
make other changes to do this?

Anyway, I doubt a bit if that will be the ideal fix because I'm only seeing the
error messages in question sporadically. There's been only instance where this
kind of fix has been a sufficient solution (ktimetracker in KDE PIM4), but
there the dynamic_cast failed systematically. I'm currently seeing the errors
often because of KDE PIM4, but that code apparently handles the issue
elegantly, and I have failed to figure out which classes to export to make the
error go away, probably somehow related to the fact that the base class is
purely abstract.

I should verify first if we're in the same situation here, i.e. if the cast
ever succeeds. It almost certainly does, because otherwise I should caught this
crash much earlier.

FWIW, I think this doesn't have anything to do with Mac vs. Linux, but with
libc++ vs. libstdc++ .

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #3 from RJVB  ---
scrap that about not seeing the warning:

ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7fa2e1f475a8
ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7fa2e1f480e8
ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7fa2e1f48568
ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7fa2e1f489e8
ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7fa2e1f48c28
ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7fa2e1f48e68
ClangFixits ClangProblem::allFixits() const dynamic cast to ClangProblem failed
of 0x7fa2e1f492e8

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 363893] dynamic_cast error, type_info's (sic) should have public visibility

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363893

RJVB  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=370641

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

RJVB  changed:

   What|Removed |Added

 CC||kf...@kde.org
   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=363893

--- Comment #2 from RJVB  ---
Found it, this is another example of the danger of using Q_ASSERT :

ClangFixits ClangProblem::allFixits() const
{
ClangFixits result;
result << m_fixits;

for (const IProblem::Ptr& diagnostic : diagnostics()) {
const Ptr problem(dynamic_cast(diagnostic.data()));
Q_ASSERT(problem);
result << problem->allFixits();
}
return result;
}

a dynamic_cast can fail even if diagnostic.data() != NULL, for instance because
of (or related to) the issue reported in ticket 363893. 

When code is built in "production" mode, Q_ASSERTs are noops, and this leads
directly to the crash and backtrace shown above.

I cannot assess to what extent a NULL problem should cause KDevelop to abort. I
am currently trying the fix below, and with that implementation I see exactly
the same (popup error reporting) as I see on Linux. Curiously the warning
hasn't been printed yet, even.

ClangFixits ClangProblem::allFixits() const
{
ClangFixits result;
result << m_fixits;

for (const IProblem::Ptr& diagnostic : diagnostics()) {
const Ptr problem(dynamic_cast(diagnostic.data()));
Q_ASSERT(problem);
if (problem) {
result << problem->allFixits();
} else {
qWarning() << Q_FUNC_INFO << "dynamic cast to ClangProblem failed
of" << diagnostic.data();
}
}
return result;
}

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 370646] Crash when opening Kontact preferences

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

--- Comment #6 from RJVB  ---
#1 (anonymous namespace)::NoteSharedRegistrar::~NoteSharedRegistrar()() at
.../kdepim-4.14.git/noteshared/attributes/attributeregistrar.cpp:44
#2 (anonymous namespace)::NoteSharedRegistrar::~NoteSharedRegistrar()() at
.../kdepim-4.14.git/noteshared/attributes/attributeregistrar.cpp:43
#3 (anonymous namespace)::$_0::destroy()() at
.../kdepim-4.14.git/noteshared/attributes/attributeregistrar.cpp:55
#4 __cxa_finalize() at ??:-1
#5 dyld::garbageCollectImages()() at ??:-1
#6 dlclose() at ??:-1
#7 dlclose() at ??:-1
#8 QLibraryPrivate::unload_sys()() at ??:-1
#9 QLibraryPrivate::unload()() at ??:-1
#10 QPluginLoader::unload()() at ??:-1
#11 KCModuleLoader::loadModule(KCModuleInfo const&,
KCModuleLoader::ErrorReporting, QWidget*, QStringList const&)() at ??:-1
#12 KCModuleProxyPrivate::loadModule()() at ??:-1
#13 KCModuleProxy::realModule() const() at ??:-1
#14 KCMultiDialog::addModule(KCModuleInfo const&, KPageWidgetItem*, QStringList
const&)() at ??:-1
#15 KSettings::DialogPrivate::createDialogFromServices()() at ??:-1
#16 KSettings::Dialog::showEvent(QShowEvent*)() at ??:-1
#17 QWidget::event(QEvent*)() at ??:-1
#18 QApplicationPrivate::notify_helper(QObject*, QEvent*)() at ??:-1
#19 QApplication::notify(QObject*, QEvent*)() at ??:-1
#20 QCoreApplication::notifyInternal(QObject*, QEvent*)() at ??:-1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 370646] Crash when opening Kontact preferences

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

--- Comment #5 from RJVB  ---
I don't understand how or why dynamically allocated memory can go stale when
the shared library which allocated it is unloaded, but apparently something
like that happens.

When I replace libnoteshared's attributeregistrar's mechanism with one that
create a global class instance when the library is loaded, I can clearly see
that instance being destroyed. I'll have a look at the backtrace leading into
that dtor, but meanwhile, here's a fix. It extends the AttributeFactory with a
method that returns the newly created attribute instance, and (a circuitous)
one that allows to unregister attributes.
The resulting libraries are ABI compatible, and Kontact no longer crashes

Patch for kdepimlibs4:

diff --git akonadi/attributefactory.cpp akonadi/attributefactory.cpp
index 47a8839..51306f0 100644
--- akonadi/attributefactory.cpp
+++ akonadi/attributefactory.cpp
@@ -30,6 +30,7 @@
 #include "entityannotationsattribute.h"

 #include 
+#include 

 #include 

@@ -79,7 +80,18 @@ class StaticAttributeFactory : public AttributeFactory
 public:
 StaticAttributeFactory()
 : AttributeFactory()
-, initialized(false) {}
+, initialized(false)
+, notDeleted(0) {
+skipList << QLatin1String("NoteDisplayAttribute")
+<< QLatin1String("NoteAlarmAttribute")
+<< QLatin1String("KJotsLockAttribute")
+<< QLatin1String("showfoldernotesattribute");
+}
+~StaticAttributeFactory() {
+if (notDeleted > 0) {
+kWarning(5250) << Q_FUNC_INFO << "attributes not deleted:" <<
notDeleted;
+}
+}
 void init() {
 if (initialized) {
 return;
@@ -98,6 +110,8 @@ public:
 AttributeFactory::registerAttribute();
 }
 bool initialized;
+size_t notDeleted;
+QStringList skipList;
 };

 K_GLOBAL_STATIC(StaticAttributeFactory, s_attributeInstance)
@@ -113,6 +127,9 @@ class AttributeFactory::Private
 {
 public:
 QHash attributes;
+Private() {
+attributes.clear();
+}
 };

 AttributeFactory *AttributeFactory::self()
@@ -132,18 +149,35 @@ AttributeFactory::~ AttributeFactory()
 delete d;
 }

+#include 
 void AttributeFactory::registerAttribute(Attribute *attr)
 {
 Q_ASSERT(attr);
 Q_ASSERT(!attr->type().contains(' ') && !attr->type().contains('\'') &&
!attr->type().contains('"'));
 QHash::Iterator it =
d->attributes.find(attr->type());
 if (it != d->attributes.end()) {
-delete *it;
+// if
(!s_attributeInstance->skipList.contains(QLatin1String(attr->type( {
+delete *it;
+// } else {
+// s_attributeInstance->notDeleted += 1;
+// }
 d->attributes.erase(it);
 }
 d->attributes.insert(attr->type(), attr);
 }

+void AttributeFactory::unRegisterAttribute(Attribute *attr)
+{
+Q_ASSERT(attr);
+Q_ASSERT(!attr->type().contains(' ') && !attr->type().contains('\'') &&
!attr->type().contains('"'));
+kDebug(5250) << Q_FUNC_INFO << "deleting entry for type" << attr->type()
<< attr;
+QHash::Iterator it =
d->attributes.find(attr->type());
+if (it != d->attributes.end()) {
+delete *it;
+d->attributes.erase(it);
+}
+}
+
 Attribute *AttributeFactory::createAttribute(const QByteArray )
 {
 Attribute *attr = self()->d->attributes.value(type);
diff --git akonadi/attributefactory.h akonadi/attributefactory.h
index 647b67e..be3b471 100644
--- akonadi/attributefactory.h
+++ akonadi/attributefactory.h
@@ -60,6 +60,16 @@ public:
 {
 AttributeFactory::self()->registerAttribute(new T);
 }
+template  inline static T *getRegisteredAttribute()
+{
+T *attr = new T;
+AttributeFactory::self()->registerAttribute(attr);
+return attr;
+}
+inline static void deRegisterAttribute(Attribute *attr)
+{
+AttributeFactory::self()->unRegisterAttribute(attr);
+}

 /**
  * Creates an entity attribute object of the given type.
@@ -76,6 +86,7 @@ protected:
 private:
 static AttributeFactory *self();
 void registerAttribute(Attribute *attribute);
+void unRegisterAttribute(Attribute *attribute);

 class Private;
 Private *const d;


Patch for kdepim4:

diff --git noteshared/attributes/attributeregistrar.cpp
noteshared/attributes/attributeregistrar.cpp
index cdcc949..56a61c0 100644
--- noteshared/attributes/attributeregistrar.cpp
+++ noteshared/attributes/attributeregistrar.cpp
@@ -22,19 +22,46 @@

 #include 

+#include 
+#include 
+
 namespace {

 // Anonymous namespace; function is invisible outside this file.
+
+class NoteSharedRegistrar {
+public:
+NoteSharedRegistrar()
+{
+  kDebug(5500) << Q_FUNC_INFO << this;
+ 

[kdevelop] [Bug 370641] kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

--- Comment #1 from RJVB  ---
Another one:

Is this output from KDevelop too?
"error: abstractnavigationwidget.cpp.o DWARF DIE at 0x16b4 for class
'QWidget' has a base class 'QObject' that is a forward declaration, not a
complete definition.
Please file a bug against the compiler and include the preprocessed output for
/Volumes/VMs/MPbuild/_Volumes_Debian_MP9_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/language/duchain/navigation/abstractnavigationwidget.cpp
"


Application: KDevelop (kdevelop), signal: Segmentation fault: 11
(lldb) process attach --pid 71568
Process 71568 stopped
Executable module set to
"/Applications/MacPorts/KF5/kdevelop.app/Contents/MacOS/kdevelop.bin".
Architecture set to: x86_64-apple-macosx.
(lldb) set set term-width 200
(lldb) thread info
thread #1: tid = 0x42f856, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 +
8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

(lldb) bt all
* thread #1: tid = 0x42f856, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x000108719dee libKF5Crash.5.dylib`KCrash::startProcess(int,
char const**, bool) [inlined] startProcessInternal(argc=,
directly=) + 125 at kcrash.cpp:649
frame #2: 0x000108719d71
libKF5Crash.5.dylib`KCrash::startProcess(argc=,
argv=, waitAndExit=) + 17 at kcrash.cpp:631
frame #3: 0x000108719bb5
libKF5Crash.5.dylib`KCrash::defaultCrashHandler(sig=11) + 1061 at
kcrash.cpp:528
frame #4: 0x7fff8b6e15aa libsystem_platform.dylib`_sigtramp + 26
frame #5: 0x00012138edbf
libKDevClangPrivate.26.dylib`QVector::operator+=(this=0x7fff578d2450,
l=0x0040) + 31 at qvector.h:790
frame #6: 0x00012138d4eb
libKDevClangPrivate.26.dylib`ClangProblem::allFixits() const [inlined]
QVector::operator<<(this=0x7fff578d2450, l=) + 43
at qvector.h:275
frame #7: 0x00012138d4e6
libKDevClangPrivate.26.dylib`ClangProblem::allFixits(this=0x)
const + 38 at clangproblem.cpp:185
frame #8: 0x00012138d60e
libKDevClangPrivate.26.dylib`ClangProblem::allFixits(this=) const
+ 334 at clangproblem.cpp:190
frame #9: 0x00012138d3de
libKDevClangPrivate.26.dylib`ClangProblem::solutionAssistant(this=0x7fd1ce7ae130)
const + 30 at clangproblem.cpp:165
frame #10: 0x00012138d782 libKDevClangPrivate.26.dylib`non-virtual
thunk to ClangProblem::solutionAssistant(this=) const + 18 at
clangproblem.cpp:163
frame #11: 0x00010be2ec97
libKDevPlatformLanguage.10.dylib`KDevelop::ProblemNavigationContext::html(this=,
shorten=) + 6551 at problemnavigationcontext.cpp:172
frame #12: 0x00010be30f96
libKDevPlatformLanguage.10.dylib`KDevelop::AbstractNavigationWidget::update(this=0x7fd1b99e6c00)
+ 54 at abstractnavigationwidget.cpp:148
frame #13: 0x00010be30e70
libKDevPlatformLanguage.10.dylib`KDevelop::AbstractNavigationWidget::setContext(this=0x7fd1b99e6c00,
context=, initBrows=) + 224 at
abstractnavigationwidget.cpp:116
frame #14: 0x0001205ec2ec
kdevcontextbrowser.so`ContextBrowserPlugin::navigationWidgetForPosition(this=0x7fd1c554e290,
view=0x7fd1c6141ac0, position=) + 2748 at
contextbrowser.cpp:530
frame #15: 0x0001205eae9a
kdevcontextbrowser.so`ContextBrowserPlugin::showToolTip(this=0x7fd1c554e290,
view=0x7fd1c6141ac0, position=) + 90 at contextbrowser.cpp:576
frame #16: 0x0001205eae24
kdevcontextbrowser.so`ContextBrowserHintProvider::textHint(this=0x7fd1c554e408,
view=, cursor=0x00230099) + 324 at contextbrowser.cpp:407
frame #17: 0x000109034297
libKF5TextEditor.5.dylib`KateViewInternal::textHintTimeout(this=0x7fd1c618e780)
+ 311 at kateviewinternal.cpp:3101
frame #18: 0x000109129f35
libKF5TextEditor.5.dylib`KateViewInternal::qt_static_metacall(_o=,
_c=, _id=, _a=) + 885 at
moc_kateviewinternal.cpp:200
frame #19: 0x00010b59b9a4
QtCore`QMetaObject::activate(sender=0x7fd1c618e998,
signalOffset=, local_signal_index=,
argv=) + 3028 at qobject.cpp:3730
frame #20: 0x00010b593ca0
QtCore`QObject::event(this=0x7fd1c618e998, e=) + 48 at
qobject.cpp:1237
frame #21: 0x00010a4131e6
QtWidgets`QApplicationPrivate::notify_helper(this=,
receiver=0x7fd1c618e998, e=0x7fff578d32b8) + 294 at
qapplication.cpp:3804
frame #22: 0x00010a416726
QtWidgets`QApplication::notify(this=, receiver=,
e=) + 8470 at qapplication.cpp:3767
frame #23: 0x00010b567687
QtCore`QCoreApplication::notifyInternal2(receiver=0x7fd1c618e998,
event=0x7fff578d32b8) + 167 at qcoreapplication.cpp:1020
frame #24: 0x00010b5c08a1 QtCore`QTimerInfoList::activateTimers()
[inlined] QCoreApplication::sendEvent(receiver=,
event=0x00010b7d2150) + 1329 at qcoreapplication.h:225
frame #25: 

[kontact] [Bug 370646] Crash when opening Kontact preferences

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

--- Comment #4 from RJVB  ---
Why this happens is unclear to me, but the line

 const bool registered = dummy();

in libnoteshared's attributeregistrar.cpp is executed twice. I think that can
only happen when the library is loaded twice.

I may be saying something stupid here, but if the library gets unloaded without
removing its registered attributes, are their addresses still valid when the
library is loaded next?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 370646] Crash when opening Kontact preferences

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

--- Comment #3 from RJVB  ---
I ran kontact through valgrind to get another angle. I think in the end it just
confirms what I already thought:

```
--72548-- run: /usr/bin/dsymutil "/opt/local/lib/kde4/kcm_knote.so"
--72548-- run: /usr/bin/dsymutil
"/opt/local/lib/libknotesprivate.4.14.21.dylib"
--72548-- run: /usr/bin/dsymutil "/opt/local/lib/libnoteshared.4.14.21.dylib"
--72548-- run: /usr/bin/dsymutil "/opt/local/lib/libkdnssd.4.14.21.dylib"
warning: (x86_64) /tmp/lto.o unable to open object file
warning: no debug symbols in executable (-arch x86_64)
==72548== Invalid read of size 8
==72548==at 0xCA796B9:
Akonadi::AttributeFactory::registerAttribute(Akonadi::Attribute*)
(attributefactory.cpp:148)
==72548==by 0x19ED63DE: global constructors keyed to a
(attributefactory.h:61)
==72548==by 0x7FFF5FC11C6D:
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in
/usr/lib/dyld)
==72548==by 0x7FFF5FC11DF9:
ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in
/usr/lib/dyld)
==72548==by 0x7FFF5FC0EAA1:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==72548==by 0x7FFF5FC0EA2A:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==72548==by 0x7FFF5FC0EA2A:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==72548==by 0x7FFF5FC0E935:
ImageLoader::runInitializers(ImageLoader::LinkContext const&,
ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)
==72548==by 0x7FFF5FC04B0D: dyld::runInitializers(ImageLoader*) (in
/usr/lib/dyld)
==72548==by 0x7FFF5FC0B80E: dlopen (in /usr/lib/dyld)
==72548==by 0x90657ED: dlopen (in /usr/lib/system/libdyld.dylib)
==72548==by 0x38F8AFC: QLibraryPrivate::load_sys() (in
/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore)
==72548==  Address 0x1a48cd40 is not stack'd, malloc'd or (recently) free'd
==72548== 
*** KMail got signal 11 (Exiting)
*** Dead letters dumped.
KCrash: Application 'kontact' crashing...
KCrash: Attempting to start
/opt/local/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi directly
```

-- 
You are receiving this mail because:
You are watching all bug changes.

[kontact] [Bug 370646] Crash when opening Kontact preferences

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

--- Comment #2 from RJVB  ---
Backtrace below.

Among the things I tried was not deleting only attributes of type
NoteDisplayAttribute. That actually made things worse, somehow, causing crashes
even when the application was starting up.

I do wonder about the delete, which appears to be a recent addition.
QHash::insert doesn't make copies as far as I read its documentation, so why
the delete? To allow the code registering an attribute to forget about it?
Maybe libnoteshared registers attributes it then deletes itself?

Application: Kontact (kontact), signal: Segmentation fault: 11
(lldb) process attach --pid 59010
Process 59010 stopped
Executable module set to "/opt/local/bin/kontact".
Architecture set to: x86_64-apple-macosx.
(lldb) set set term-width 200
(lldb) thread info
thread #1: tid = 0x354337, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 +
8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

(lldb) bt all
* thread #1: tid = 0x354337, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x000107fc616e libkdeui.5.dylib`KCrash::startProcess(int,
char const**, bool) + 286
frame #2: 0x000107fc5295
libkdeui.5.dylib`KCrash::defaultCrashHandler(int) + 1189
frame #3: 0x7fff8b6e15aa libsystem_platform.dylib`_sigtramp + 26
frame #4: 0x00010a5249ca
libakonadi-kde.4.dylib`Akonadi::AttributeFactory::registerAttribute(this=0x7f97dbc28870,
attr=0x7f97e1d8b980) + 538 at attributefactory.cpp:141
frame #5: 0x000120e3c2cf libnoteshared.4.dylib`_GLOBAL__I_a [inlined]
void
Akonadi::AttributeFactory::registerAttribute()
+ 47 at attributefactory.h:61
frame #6: 0x000120e3c2a4 libnoteshared.4.dylib`_GLOBAL__I_a [inlined]
(anonymous namespace)::dummy() at attributeregistrar.cpp:30
frame #7: 0x000120e3c2a4 libnoteshared.4.dylib`_GLOBAL__I_a [inlined]
__cxx_global_var_init at attributeregistrar.cpp:38
frame #8: 0x000120e3c2a4 libnoteshared.4.dylib`_GLOBAL__I_a + 4 at
attributeregistrar.cpp:0
frame #9: 0x7fff61468c6e
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) +
268
frame #10: 0x7fff61468dfa
dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
frame #11: 0x7fff61465aa2
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, ImageLoader::InitializerTimingList&) + 308
frame #12: 0x7fff61465a2b
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, ImageLoader::InitializerTimingList&) + 189
frame #13: 0x7fff61465a2b
dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
unsigned int, ImageLoader::InitializerTimingList&) + 189
frame #14: 0x7fff61465936
dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&,
ImageLoader::InitializerTimingList&) + 54
frame #15: 0x7fff6145bb0e dyld`dyld::runInitializers(ImageLoader*) + 89
frame #16: 0x7fff6146280f dyld`dlopen + 538
frame #17: 0x7fff8eb347ee libdyld.dylib`dlopen + 59
frame #18: 0x00010981aafd QtCore`QLibraryPrivate::load_sys() + 2589
frame #19: 0x000109818000 QtCore`QLibrary::load() + 80
frame #20: 0x0001093b5281
libkdecore.5.dylib`KLibLoader::library(QString const&,
QFlags) + 145
frame #21: 0x00010a0acb73
libkcmutils.4.dylib`KCModuleLoader::loadModule(KCModuleInfo const&,
KCModuleLoader::ErrorReporting, QWidget*, QStringList const&) + 3635
frame #22: 0x00010a0b470c
libkcmutils.4.dylib`KCModuleProxyPrivate::loadModule() + 668
frame #23: 0x00010a0b4432
libkcmutils.4.dylib`KCModuleProxy::realModule() const + 66
frame #24: 0x00010a0b0791
libkcmutils.4.dylib`KCMultiDialog::addModule(KCModuleInfo const&,
KPageWidgetItem*, QStringList const&) + 385
frame #25: 0x00010a0caf6b
libkcmutils.4.dylib`KSettings::DialogPrivate::createDialogFromServices() + 2715
frame #26: 0x00010a0ca053
libkcmutils.4.dylib`KSettings::Dialog::showEvent(QShowEvent*) + 1923
frame #27: 0x0001085ce1f6 QtGui`QWidget::event(QEvent*) + 1334
frame #28: 0x000108574afc
QtGui`QApplicationPrivate::notify_helper(QObject*, QEvent*) + 332
frame #29: 0x000108577e99 QtGui`QApplication::notify(QObject*, QEvent*)
+ 8281
frame #30: 0x000109830126
QtCore`QCoreApplication::notifyInternal(QObject*, QEvent*) + 118
frame #31: 0x0001085ccf0c QtGui`QWidgetPrivate::show_helper() + 668
frame #32: 0x0001085cd9ae QtGui`QWidget::setVisible(bool) + 974
frame #33: 0x000108a314b9 QtGui`QDialog::setVisible(bool) + 169
frame #34: 0x00010732b8fc
libkontactprivate.4.dylib`Kontact::MainWindow::slotPreferences() [inlined]
QWidget::show(this=) + 668 at qwidget.h:497
frame #35: 0x00010732b8f1

[kontact] [Bug 370646] New: Crash when opening Kontact preferences

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370646

Bug ID: 370646
   Summary: Crash when opening Kontact preferences
   Product: kontact
   Version: GIT (master)
  Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: kdepim-b...@kde.org
  Reporter: rjvber...@gmail.com

Kontact built from the latest 4.14 branch sources crashes on OS X whenever I
open the Kontact preferences dialog.

Reproducible: Always

Steps to Reproduce:
1. Start Kontact
2. Select Settings/Configure Kontact


Actual Results:  
DrKonqi appears

Expected Results:  
Kontact preferences dialog appears

The actual crash is in line 141 of attributefactory.cpp
(`AttributeFactory::registerAttribute(Attribute *attr)`):

delete *it;

For now I haven't seen it happen when I comment that line out; I hope this only
leads to a minor memory leak (which I find preferable over a crash).

I hope this info is useful for the KF5 version but would appreciate a
backported fix.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 370641] New: kdevelop (clang parser) crash when selecting a specific line

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370641

Bug ID: 370641
   Summary: kdevelop (clang parser) crash when selecting a
specific line
   Product: kdevelop
   Version: 5.0.1
  Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

Application: kdevelop (5.0.1)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.27.0
Operating System: Darwin 13.4.0 x86_64
Distribution (Platform): MacPorts Packages

-- Information about the crash:
- What I was doing when the application crashed:

I'm debugging a crash in KDEPIM git/master of the 4.14 branch; for that I added
a qDebug() statement to kdepimlibs' attributefactory.cpp after line 141:

qDebug() << "delete *" << it << "=" << *it;

I could enter that line without issues, but when I reselected it (to remove the
"<< it <<" bit which doesn't compile) the clang parser provoked a crash 2 times
in a row.

The null *this ptr looks suspicious in frame #7.

I'm using llvm+clang 3.9.0 .

The crash can be reproduced every time.

-- Backtrace:
Application: KDevelop (kdevelop), signal: Segmentation fault: 11
(lldb) process attach --pid 42827
Process 42827 stopped
Executable module set to
"/Applications/MacPorts/KF5/kdevelop.app/Contents/MacOS/kdevelop.bin".
Architecture set to: x86_64-apple-macosx.
(lldb) set set term-width 200
(lldb) thread info
thread #1: tid = 0x32a2a5, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 +
8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

(lldb) bt all
* thread #1: tid = 0x32a2a5, 0x7fff8f109e20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x7fff8f109e20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x00010899ddee libKF5Crash.5.dylib`KCrash::startProcess(int,
char const**, bool) [inlined] startProcessInternal(argc=,
directly=) + 125 at kcrash.cpp:649
frame #2: 0x00010899dd71
libKF5Crash.5.dylib`KCrash::startProcess(argc=,
argv=, waitAndExit=) + 17 at kcrash.cpp:631
frame #3: 0x00010899dbb5
libKF5Crash.5.dylib`KCrash::defaultCrashHandler(sig=11) + 1061 at
kcrash.cpp:528
frame #4: 0x7fff8b6e15aa libsystem_platform.dylib`_sigtramp + 26
frame #5: 0x000120e42dbf
libKDevClangPrivate.26.dylib`QVector::operator+=(this=0x7fff57654450,
l=0x0040) + 31 at qvector.h:790
frame #6: 0x000120e414eb
libKDevClangPrivate.26.dylib`ClangProblem::allFixits() const [inlined]
QVector::operator<<(this=0x7fff57654450, l=) + 43
at qvector.h:275
frame #7: 0x000120e414e6
libKDevClangPrivate.26.dylib`ClangProblem::allFixits(this=0x)
const + 38 at clangproblem.cpp:185
frame #8: 0x000120e4160e
libKDevClangPrivate.26.dylib`ClangProblem::allFixits(this=) const
+ 334 at clangproblem.cpp:190
frame #9: 0x000120e413de
libKDevClangPrivate.26.dylib`ClangProblem::solutionAssistant(this=0x7fba2d75ff00)
const + 30 at clangproblem.cpp:165
frame #10: 0x000120e41782 libKDevClangPrivate.26.dylib`non-virtual
thunk to ClangProblem::solutionAssistant(this=) const + 18 at
clangproblem.cpp:163
frame #11: 0x00010c05cc97
libKDevPlatformLanguage.10.dylib`KDevelop::ProblemNavigationContext::html(this=,
shorten=) + 6551 at problemnavigationcontext.cpp:172
frame #12: 0x00010c05ef96
libKDevPlatformLanguage.10.dylib`KDevelop::AbstractNavigationWidget::update(this=0x7fba22f05b30)
+ 54 at abstractnavigationwidget.cpp:148
frame #13: 0x00010c05ee70
libKDevPlatformLanguage.10.dylib`KDevelop::AbstractNavigationWidget::setContext(this=0x7fba22f05b30,
context=, initBrows=) + 224 at
abstractnavigationwidget.cpp:116
frame #14: 0x00011a7f62ec
kdevcontextbrowser.so`ContextBrowserPlugin::navigationWidgetForPosition(this=0x7fba2589db40,
view=0x7fba26323e00, position=) + 2748 at
contextbrowser.cpp:530
frame #15: 0x00011a7f4e9a
kdevcontextbrowser.so`ContextBrowserPlugin::showToolTip(this=0x7fba2589db40,
view=0x7fba26323e00, position=) + 90 at contextbrowser.cpp:576
frame #16: 0x00011a7f4e24
kdevcontextbrowser.so`ContextBrowserHintProvider::textHint(this=0x7fba2589dcb8,
view=, cursor=0x0022008d) + 324 at contextbrowser.cpp:407
frame #17: 0x0001092b7ae7
libKF5TextEditor.5.dylib`KateViewInternal::textHintTimeout(this=0x7fba26363b50)
+ 311 at kateviewinternal.cpp:3095
frame #18: 0x0001093ad4c5
libKF5TextEditor.5.dylib`KateViewInternal::qt_static_metacall(_o=,
_c=, _id=, _a=) + 885 at
moc_kateviewinternal.cpp:200
frame #19: 0x00010b7ed9a4
QtCore`QMetaObject::activate(sender=0x7fba26363d68,
signalOffset=, local_signal_index=,
argv=) + 3028 at qobject.cpp:3730
frame #20: 0x00010b7e5ca0

[frameworks-kfilemetadata] [Bug 370499] New: bug in FindFFmpeg.cmake

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370499

Bug ID: 370499
   Summary: bug in FindFFmpeg.cmake
   Product: frameworks-kfilemetadata
   Version: 5.27.0
  Platform: Compiled Sources
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: pinak.ah...@gmail.com
  Reporter: rjvber...@gmail.com

There's a typo causing a bug in FindFFmpeg.cmake that causes it to consider
libpostproc "not found" even if it's installed.

Reproducible: Always

Steps to Reproduce:
configure kfilemetadata with a compatible FFMpeg installed

Actual Results:  
libpostproc is considered not available

Expected Results:  
all installed FFMpeg components should be found

--- cmake/orig.FindFFmpeg.cmake2016-10-11 21:21:21.0 +0200
+++ cmake/FindFFmpeg.cmake2016-10-11 21:49:52.0 +0200
@@ -124,7 +126,7 @@
   find_component(AVDEVICE libavdevice avdevice libavdevice/avdevice.h)
   find_component(AVUTIL   libavutil   avutil   libavutil/avutil.h)
   find_component(SWSCALE  libswscale  swscale  libswscale/swscale.h)
-  find_component(POSTPROC libpostproc postproc libpostproc/postprocess.h)
+  find_component(POSTPROCESS libpostproc postproc libpostproc/postprocess.h)

   # Check if the required components were found and add their stuff to the
FFMPEG_* vars.
   foreach (_component ${FFmpeg_FIND_COMPONENTS})

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 370257] [OS X] weird window "dissociation" glitch

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370257

--- Comment #2 from RJVB  ---
I cannot reproduce this when starting Kate through the Finder; in that case its
window also opens with the document already open. It is thus faster to start,
but also faster to quit. And finally, when I start kate with a document from a
shell, I'm seeing messages (when quitting) in the system.log:

Oct  7 19:00:45 Portia.local WindowServer[139]:
_CGXRemoveWindowFromWindowMovementGroup: Window not in group

They also appear when I open a document directly in Kate

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 370257] [OS X] weird window "dissociation" glitch

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370257

--- Comment #1 from RJVB  ---
Created attachment 101475
  --> https://bugs.kde.org/attachment.cgi?id=101475=edit
screenshot showing the glitch

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 370257] New: [OS X] weird window "dissociation" glitch

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370257

Bug ID: 370257
   Summary: [OS X] weird window "dissociation" glitch
   Product: kate
   Version: 16.04.1
  Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: application
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

I'm seeing a really weird graphic glitch in which almost the entire content of
kate's window is duplicated when I move the application while it's starting up.

Kate must do something different, because it's also the only application which
I've seen printing Qt warnings like below. The setScreen() attempt isn't a
direct cause btw, because those warnings are printed instead of any actual work
being done by the function.

QWidgetWindow(0x7fc40c5a4780, name="QFrameClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a3e50, name="QSplitterClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a2fa0, name="QFrameClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a2130, name="QSplitterClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a2130, name="QSplitterClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a2130, name="QSplitterClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a2fa0, name="QFrameClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a2fa0, name="QFrameClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a3e50, name="QSplitterClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a3e50, name="QSplitterClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a4780, name="QFrameClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40c5a4780, name="QFrameClassWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.
QWidgetWindow(0x7fc40ce07a90, name="mainToolBarWindow") (
QScreen(0x7fc409c78760, name="BenQ GL2250H") ): Attempt to set a screen on a
child window.


Reproducible: Always

Steps to Reproduce:
1. start Kate with a document from a terminal ("kate foo.txt")
2. move the window before the document has been opened


Actual Results:  
See screenshot. The contents are shown twice, once where they belong, and once
where they would have appeared if the window hadn't been moved.

Expected Results:  
no such weirdness.

This makes one wonder if kate always maintains 2 views, which only happen to be
superimposed because the window usually doesn't move in between the successive
creations.

- this situation can be rectified by going into and out from fullscreen mode
- moving the window moves both "areas"
- kate is the only application in which I've been able to provoke this
behaviour.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 361805] cmake project manager should call cmake without any arguments on imported pre-existing build directories (and maybe not auto-call at all)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361805

--- Comment #2 from RJVB  ---
Will do, but probably not before next week.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 348414] Crash in KNotification::flags() (NotifyByAudio::onAudioFinished)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=348414

--- Comment #52 from RJVB  ---
Sadly, no. I cannot recall having seen this crash, but I also do not normally
get an audio notification when I do a git commit through KDevelop. If ever it
becomes a habit I can try to provoke this while running through valgrind (but
that in itself is a bit more than my machine can handle, for KDevelop at
least).

I noticed this in my backtrace:
#16 0x7fc783a11aa8 in QCoreApplication::sendPostedEvents
(receiver=receiver@entry=0x0, event_type=event_type@entry=0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qcoreapplication.cpp:1513

is it possible that this crash is the result using delete instead of
->deleteLater() on an object pointer inheriting QObject and representing a
widget (or otherwise be a potential recipient of GUI events)? That would
explain why the crash isn't systematic.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 369278] debugger toolbar (and toolbar items in general) should remain put where user left it (and maintain its visibility across restarts)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369278

RJVB  changed:

   What|Removed |Added

  Flags||Usability+

--- Comment #2 from RJVB  ---
I've changed the bug title because I think that same multi-level restore
apparent from the backtraces above causes other items to be restored when they
shouldn't.

For instance, I have been trying to get rid of the "Documentation" toolbar item
because I don't use it (for a large part because using it tends to make its
window reappear persistently). The "Documentation" toolbar item also keeps
restoring itself.

In fact, it does that much more persistently than the debugger toolbar:
1- open a session in KDevelop
2- remove the DOcumentation button from any toolbar it may be on, in all areas
(code, review, debug)
3- quit KDevelop
4- restart KDevelop
5- back to 2)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 369278] debugger toolbar (and toolbar items in general) should remain put where user left it (and maintain its visibility across restarts)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369278

RJVB  changed:

   What|Removed |Added

Summary|debugger toolbar should |debugger toolbar (and
   |remain put where user left  |toolbar items in general)
   |it (and maintain its|should remain put where
   |visibility) |user left it (and maintain
   ||its visibility across
   ||restarts)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-knotifications] [Bug 348414] Crash in KNotification::flags() (NotifyByAudio::onAudioFinished)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=348414

RJVB  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
 CC||rjvber...@gmail.com

--- Comment #50 from RJVB  ---
According to DrKonqi I just got this crash in KDevelop, when I hit the Git
plugin's "Commit" button 

Application: KDevelop (kdevelop5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fc786437780 (LWP 25726))]

Thread 19 (Thread 0x7fc75700 (LWP 25730)):
#0  0x7fc7831976cd in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fc77c10cc10 in read (__nbytes=16, __buf=0x7fc75fffec30,
__fd=) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#2  g_wakeup_acknowledge (wakeup=0x7fc7600015b0) at
/build/buildd/glib2.0-2.40.2/./glib/gwakeup.c:210
#3  0x7fc77c0cbb14 in g_main_context_check
(context=context@entry=0x7fc758000990, max_priority=2147483647,
fds=fds@entry=0x7fc758010980, n_fds=n_fds@entry=1) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3532
#4  0x7fc77c0cbf7b in g_main_context_iterate
(context=context@entry=0x7fc758000990, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3731
#5  0x7fc77c0cc0ec in g_main_context_iteration (context=0x7fc758000990,
may_block=may_block@entry=1) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795
#6  0x7fc783a636fb in QEventDispatcherGlib::processEvents
(this=0x7fc7580008c0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:419
#7  0x7fc783a0d62a in QEventLoop::exec (this=this@entry=0x7fc75fffee20,
flags=..., flags@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventloop.cpp:204
#8  0x7fc78384301b in QThread::exec (this=this@entry=0x7fc78584a420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread.cpp:500
#9  0x7fc7855d9615 in QDBusConnectionManager::run (this=0x7fc78584a420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/dbus/qdbusconnection.cpp:189
#10 0x7fc783847d29 in QThreadPrivate::start (arg=0x7fc78584a420 <(anonymous
namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#11 0x7fc77cf51184 in start_thread (arg=0x7fc75700) at
pthread_create.c:312
#12 0x7fc7831a637d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 18 (Thread 0x7fc74d973700 (LWP 25737)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1  0x7fc783848a66 in wait_relative (time=1000, this=0x3561ec0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:126
#2  wait (time=1000, this=0x3561ec0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:134
#3  QWaitCondition::wait (this=this@entry=0x335e878,
mutex=mutex@entry=0x335e880, time=time@entry=1000) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:208
#4  0x7fc781309938 in KDevelop::DUChainPrivate::CleanupThread::run
(this=0x335e860) at
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kdevplatform5/kf5-kdevplatform-devel/work/kf5-kdevplatform-5/language/duchain/duchain.cpp:282
#5  0x7fc783847d29 in QThreadPrivate::start (arg=0x335e860) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#6  0x7fc77cf51184 in start_thread (arg=0x7fc74d973700) at
pthread_create.c:312
#7  0x7fc7831a637d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 17 (Thread 0x7fc7208be700 (LWP 25738)):
#0  0x7fc7831976cd in read () at 

[kdevplatform] [Bug 363494] closing a Patch Review via (git) commit opens the documentation view

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363494

--- Comment #9 from RJVB  ---
I think that what happens is that the review and debug areas have its own
setting for the documentation visibility, and that somehow the visibility isn't
restored properly when going back to the code area.

Why the documentation view actually opens when it wasn't in the review (or
debug) area beats me...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 369278] debugger toolbar should remain put where user left it (and maintain its visibility)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369278

--- Comment #1 from RJVB  ---
A bit more info on this one: apparently the debugger toolbar state is saved in
more than 1 location. If it reappears against my instructions, I quit KDevelop
and turn the debugger toolbar off in kdeveloprc, it will reappear consistently.

In Sublime::MainWindow::loadSettings() its visibility will be set to false,
which also allows me to set a conditional breakpoint in QWidget::setVisible()
to catch subsequent changes. And indeed, a bit later I get a whole series of
hits with the backtraces below, suggesting that its a plugin restoring its view
settings that causes this. Could that be the debugger plugin itself or is it
just the plugin load order and what its idea bout debugger toolbar visibility
is that determines whether it will ultimately be visible?

If so, why do so many plugins store a visibility state for this toolbar, and
what can be done about it? This basically means that the toolbar's effective
visibility at startup is almost purely random, and that doesn't apply for other
toolbars.

1st:
* thread #1: tid = 0x1ba872e, 0x00010cdc69f8
QtWidgets`QWidget::setVisible(this=0x7fd5fcd14590, visible=true) + 40 at
qwidget.cpp:8112, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
frame #0: 0x00010cdc69f8
QtWidgets`QWidget::setVisible(this=0x7fd5fcd14590, visible=true) + 40 at
qwidget.cpp:8112 [opt]
   8109 
   8110 void QWidget::setVisible(bool visible)
   8111 {
-> 8112 if (visible) { // show
   8113 if (testAttribute(Qt::WA_WState_ExplicitShowHide) &&
!testAttribute(Qt::WA_WState_Hidden))
   8114 return;
   8115 
(lldb) bt
* thread #1: tid = 0x1ba872e, 0x00010cdc69f8
QtWidgets`QWidget::setVisible(this=0x7fd5fcd14590, visible=true) + 40 at
qwidget.cpp:8112, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0: 0x00010cdc69f8
QtWidgets`QWidget::setVisible(this=0x7fd5fcd14590, visible=true) + 40 at
qwidget.cpp:8112 [opt]
frame #1: 0x00010cf6ed00
QtWidgets`QToolBarAreaLayout::restoreState(this=0x7fd5fa8a2a38,
stream=0x7fff54bd5198, _toolBars=, tmarker=,
testing=false) + 912 at qtoolbararealayout.cpp:1356 [opt]
frame #2: 0x00010ceda412
QtWidgets`QMainWindowLayoutState::restoreState(this=0x7fd5fa8a2a20,
_stream=, oldState=) + 642 at
qmainwindowlayout.cpp:985 [opt]
frame #3: 0x00010cee1be2
QtWidgets`QMainWindowLayout::restoreState(this=0x7fd5fa8a2a00,
stream=) + 98 at qmainwindowlayout.cpp:2522 [opt]
frame #4: 0x00010ced62de
QtWidgets`QMainWindow::restoreState(this=0x7fd5fc9db3a0,
state=, version=) + 142 at qmainwindow.cpp:1329 [opt]
frame #5: 0x00010c0ea769
libKF5XmlGui.5.dylib`KMainWindow::applyMainWindowSettings(KConfigGroup const&)
+ 1811
frame #6: 0x00010c11dac3
libKF5XmlGui.5.dylib`KXmlGuiWindow::applyMainWindowSettings(KConfigGroup
const&) + 23
frame #7: 0x00010c11da98
libKF5XmlGui.5.dylib`KXmlGuiWindow::finalizeGUI(bool) + 98
frame #8: 0x00010c10f0e7
libKF5XmlGui.5.dylib`KXMLGUIFactory::addClient(KXMLGUIClient*) + 1169
frame #9: 0x00010b07aeb7
libKDevPlatformShell.10.dylib`KDevelop::MainWindowPrivate::addPlugin(this=0x7fd5fa429a50,
plugin=) + 439 at mainwindow_p.cpp:97 [opt]
frame #10: 0x00010df184b6 QtCore`QMetaObject::activate(QObject*, int,
int, void**) [inlined] QtPrivate::QSlotObjectBase::call(this=,
r=, a=) + 2054 at qobject_impl.h:124 [opt]
frame #11: 0x00010df1849b
QtCore`QMetaObject::activate(sender=0x7fd5fa439b80,
signalOffset=, local_signal_index=,
argv=) + 2027 at qobject.cpp:3715 [opt]
frame #12: 0x00010ba2cb7f
libKDevPlatformInterfaces.10.dylib`KDevelop::IPluginController::pluginLoaded(this=,
_t1=) + 63 at moc_iplugincontroller.cpp:235 [opt]
frame #13: 0x00010b083aac
libKDevPlatformShell.10.dylib`KDevelop::PluginController::loadPluginInternal(this=,
pluginId=) + 7916 at plugincontroller.cpp:578 [opt]
frame #14: 0x00010b08936b
libKDevPlatformShell.10.dylib`KDevelop::PluginController::allPluginsForExtension(QString
const&, QMap const&) [inlined]
KDevelop::PluginController::allPluginsForExtension(QString const&,
QMap const&)::$_9::operator()(KPluginMetaData const&) const
+ 85 at plugincontroller.cpp:658 [opt]
frame #15: 0x00010b089316
libKDevPlatformShell.10.dylib`KDevelop::PluginController::allPluginsForExtension(QString
const&, QMap const&) [inlined] void
KDevelop::PluginControllerPrivate::foreachEnabledPlugin const&)::$_9>(this=0x7fd5fa4f2c60)::$_9,
QString const&, QMap const&, QString const&) + 790 at
plugincontroller.cpp:220 [opt]
frame #16: 0x00010b089000
libKDevPlatformShell.10.dylib`KDevelop::PluginController::allPluginsForExtension(this=0x7fd5fa439b80,
extension=, 

[buildsystem] [Bug 369554] sleeper design bug in the installation layout due to assumptions about filesystem case sensitivity

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369554

RJVB  changed:

   What|Removed |Added

URL||https://git.reviewboard.kde
   ||.org/r/127822/

-- 
You are receiving this mail because:
You are watching all bug changes.

[buildsystem] [Bug 369554] sleeper design bug in the installation layout due to assumptions about filesystem case sensitivity

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369554

--- Comment #1 from RJVB  ---
I don't really know how invasive it would be to address this issue properly, or
rather, how to fix this without being overly invasive. Looking at KPeople I see

/opt/local/include/KF5/KPeople/KPeople/Widgets/Actions
/opt/local/include/KF5/KPeople/kpeople/widgets/actions.h

which means that on a case-insensitive-but-preserving FS (HFS, NTFS) you can
end up with 4 different situations:

/opt/local/include/KF5/KPeople/kpeople/widgets/{Actions,actions.h}
/opt/local/include/KF5/KPeople/KPeople/widgets/{Actions,actions.h}
/opt/local/include/KF5/KPeople/kpeople/Widgets/{Actions,actions.h}
/opt/local/include/KF5/KPeople/KPeople/Widgets/{Actions,actions.h}

and that's presuming that the case preservations works reliably. Transfer such
a tree via a FAT32 thumbdrive and all bets are off. Evidently that's less
likely to happen with a headerfile directory (and just shouldn't be done) but
I'm concerned that the underlying implicit assumption about the FS has been
made elsewhere too. And as I note in the ticket: Mac OS app bundles should
support being transferred to and from case-insensitive volumes and still be
usable on a case-sensitive volume (idem for KF5 framework bundles if they ever
see the light).

The most straightforward fix would be to use only CamelCase OR lowercase header
directories, i.e. one of
/opt/local/include/KF5/KPeople/kpeople/widgets/{Actions,actions.h}
/opt/local/include/KF5/KPeople/KPeople/Widgets/{Actions,actions.h}

This is also what Qt5 does, and one can presume they have seen a lot more
testing of this approach on many more platforms.
NB: one could create the appropriate symlinks when installing to a
case-sensitive FS, but evidently that makes it impossible to copy the result to
a case-insensitive FS.

I realise that doing this is an invasive change that requires patching lots of
dependent code, and even if those patches could be generated automatically the
patched code would then no longer build against older versions of the
frameworks. Still, it'd be an almost perfect way to force people to look for
other places where the assumption about FS case-sensitivity could lead to
problems.

-- 
You are receiving this mail because:
You are watching all bug changes.

[buildsystem] [Bug 369554] New: sleeper design bug in the installation layout due to assumptions about filesystem case sensitivity

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369554

Bug ID: 369554
   Summary: sleeper design bug in the installation layout due to
assumptions about filesystem case sensitivity
   Product: buildsystem
   Version: unspecified
  Platform: Other
OS: other
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: neund...@kde.org
  Reporter: rjvber...@gmail.com

There is a design sleeper bug in the installation layout that has serious
effects when triggered. I see it throughout the frameworks and have to presume
it is made in other places too, which is why I am reporting it in this section
(the only relevant generic one that doesn't only have old-and-cold tickets).

The underlying issue here is that the design of at least the framework header
file tree assumes it is installed onto a case-sensitive filesystem. While this
is the norm on traditional Unix and Linux, conceivable for good reasons, it
simply isn't the norm in the rest of the world - and that rest is in fact a
(much) bigger target market.

The perfect illustration of this design bug ls in the KF5 frameworks header
file install locations. KF5 applies the usual convention that C headers are
lower-case and have a .h extension and C++ headers are capitalised and have no
extension: foo.h and Foo . A number of frameworks go beyond that, and put the C
headers in a subdirectory "foo" and the C++ headers in a directory "Foo". For
example:

KIOCore/KIO/Global
KIOCore/kio/global.h

Installing this on a case-insensitive filesystem 2 things may happen:
1) when KIO is created after kio (or vice-versa) an error is raised that the
directory already exists
2) the underlying routines consider KIO and kio to be the same directory, and
one ends up with

KIOCore/KIO/Global
KIOCore/KIO/global.h

or

KIOCore/kio/Global
KIOCore/kio/global.h

(presuming that the FS is case-preserving).

This is not a problem as long as the installed files are used only on the local
host (and the software itself doesn't reject an opened file if its path isn't
identical to the requested name).

The sleeper bug is triggered when installers are created on a case-insensitive
host and deployed on a case-sensitive host. That target host will receive the
same merged directory, but there the underlying system routines will take case
into account, and in this example, including "KIO/Global" or "kio/kio.h" will
fail.

We have had to deal with this bug on (Mac) OS (X) for a long time; in KDE4 days
it was limited to a select few of badly designed projects (like nepomuk-core).

At the moment I have only noticed this design issue in the header file install
location, which is of course an area that may not affect end-users so much. But
given that the issue is most likely the result of insufficient consideration of
all possible deployment targets it is bound to be present in other areas too.

Reproducible: Always

Steps to Reproduce:
1. Build any project on a host with case-insensitive filesystem
2. Create an installer
3. Deploy on a host with a case-sensitive filesystem


Actual Results:  
If the project contains 'foo' and 'Foo' directories in the same parent
directory, these will be merged in the final install, either as 'foo' or as
'Foo' depending on the OS and the order of unpacking. As a result, opening
either "foo/foo.h" or "Foo/Foo" will fail.

This also happens on a case-insensitive filesystem, but there it is only a
problem if higher-level code checks the name of the file actually opened
against the expected name (i.e. if it rejects "Foo/foo.h" or "foo/Foo").

Expected Results:  
No issues that result from assumptions about filesystem case sensitivity.

This design issue has implications for Mac and PC users. I have less view of PC
user practices, but it is quite common for more advanced Mac users to set their
system to case-sensitive, or at least use case-sensitive volumes (externals,
partitions, ...). 

One easy way to get around this issue would be to test for and enforce
case-sensitivity in the build system, so that installers can only be created on
such systems. However, with the typical Mac way of installing by dragging an
application icon to the target destination that won't be enough. Users will
expect that they can drag their applications along with them, possibly
transporting them on a thumb drive or other media with a case-insensitive FS
like FAT32.

Note that Qt5 also uses "foo.h" C headers and "Foo" C++ headers (which then
include the C header). However, it installs both versions into the same
directory from the onset so the issue reported here shouldn't occur.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 369546] code browser popup shows wrong function declaration

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369546

--- Comment #1 from RJVB  ---
Created attachment 101352
  --> https://bugs.kde.org/attachment.cgi?id=101352=edit
screenshot showing the code browser glitch. NB: INFINITE is defined to be -1

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 369546] New: code browser popup shows wrong function declaration

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369546

Bug ID: 369546
   Summary: code browser popup shows wrong function declaration
   Product: kdevplatform
   Version: git master
  Platform: Compiled Sources
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: contextbrowser
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

I've noticed a case where the code browser popup that appears when hovering the
mouse curser over a function shows an incorrect function declaration,
systematically and both Linux and OS X; see the screenshot.

Reproducible: Always

Steps to Reproduce:
1. Open a file containing an affected function declaration or definition
2. Hover the mouse cursor over the function name


Actual Results:  
A window pops up with a different function declaration

Expected Results:  
The popup window should show the same declaration as the source code

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 369525] Rewrite the command echo in the Build toolview

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369525

--- Comment #2 from RJVB  ---
"Copy to clipboard" doesn't give a lot of leeway to address the issue; the only
intervention I can see that can be applied without too much 2nd-guessing is to
strip the final newline from the selection. But I'd rather see this fixed in a
less catch-all fashion that cannot have unforeseen side-effects.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 369525] New: Rewrite the command echo in the Build toolview

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369525

Bug ID: 369525
   Summary: Rewrite the command echo in the Build toolview
   Product: kdevelop
   Version: git master
  Platform: Other
OS: All
Status: UNCONFIRMED
  Severity: critical
  Priority: NOR
 Component: Build tools: CMake
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

Here's an example command echo from the build toolview/progress window:

/Users/bertin/work/src/MSWin/SynchroTr/CMake/Release> /opt/local/bin/cmake
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=MacPorts -G 'Unix
Makefiles' -Wno-dev '-DCMAKE_C_FLAGS=-O3 -march=native -g'
'-DCMAKE_CXX_FLAGS=-O3 -march=native -g'

Guess what happens when you are trying to figure out why things don't configure
as you expect, you copy the line using the "Copy selection to clipboard"
toolbutton, and paste the result in a terminal, for instance with the idea of
appending "--debug-output"

Reproducible: Always

Steps to Reproduce:
1. Copy a progress command echo like the one shown above
2. Paste into a terminal


Actual Results:  
The line will be executed because a newline was included during the copy
procedure. There's little one can do about that, except for remembering to type
a comment or illegal character (I often use a brace) before doing the paste.

If the file after the '>' is owned by the user, its contents will be lost.

Expected Results:  
This is of course the expected result...

The problem could be avoided by printing what is actually being done:

(cd /Users/bertin/work/src/MSWin/SynchroTr/CMake/Release ; /opt/local/bin/cmake
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=MacPorts -G 'Unix
Makefiles' -Wno-dev '-DCMAKE_C_FLAGS=-O3 -march=native -g'
'-DCMAKE_CXX_FLAGS=-O3 -march=native -g')

or by using a different "prompt" character that doesn't have a special meaning
in the shell.

Alternatively, the build progress view (and similar toolviews) could support
partial selection instead of allowing to select only complete lines.

You could call this a stupid operator error and that wouldn't be entirely
wrong. I would evidently never have executed the command "as is", and if I
hadn't been trying to figure out why something didn't work I might even have
double-checked what I was about to do before pasting.
Still, it's something that clearly can happen, with potentially very annoying
results.

I experienced dataloss because of this, so I'm putting a Critical severity.
Feel free to bump it down after having taken note ;)

I'm volunteering to look into this and put up a draft modification for review;
just please point me to the code that has to be changed. Searching for a '>' in
a large C++ project might provoke a hay fever attack otherwise ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 369483] New: KDevelop crash after cancelling a CMake project import

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369483

Bug ID: 369483
   Summary: KDevelop crash after cancelling a CMake project import
   Product: kdevelop
   Version: 5.0.1
  Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

Application: kdevelop (5.0.1)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Darwin 13.4.0 x86_64
Distribution (Platform): MacPorts Packages

-- Information about the crash:
- What I was doing when the application crashed:

I was importing a new CMake-based project when I realised there were some
issues with my CMake files. The import process was in the dialog where it asks
for a build directory; I cancelled that one and got this crash.

-- Backtrace:
Application: KDevelop (kdevelop), signal: Segmentation fault: 11
(lldb) process attach --pid 75545
Process 75545 stopped
Executable module set to
"/Applications/MacPorts/KF5/kdevelop.app/Contents/MacOS/kdevelop.bin".
Architecture set to: x86_64-apple-macosx.
(lldb) set set term-width 200
(lldb) thread info
thread #1: tid = 0x190e5aa, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 +
8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

(lldb) bt all
* thread #1: tid = 0x190e5aa, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x00010675cfe2 libKF5Crash.5.dylib`KCrash::startProcess(int,
char const**, bool) + 135
frame #2: 0x00010675ce06
libKF5Crash.5.dylib`KCrash::defaultCrashHandler(int) + 1049
frame #3: 0x7fff81b8c5aa libsystem_platform.dylib`_sigtramp + 26
frame #4: 0x00010915f678
QtCore`QHashData::nextNode(node=0x7fd767a05920) + 8 at qhash.cpp:557
frame #5: 0x0001099f159a
libKDevPlatformLanguage.10.dylib`QHash::erase(QHash::iterator) [inlined] QHash::iterator::operator++() + 8 at qhash.h:320
frame #6: 0x0001099f1592
libKDevPlatformLanguage.10.dylib`QHash::erase(this=, it=) + 258 at
qhash.h:834
frame #7: 0x0001099f281d
libKDevPlatformLanguage.10.dylib`KDevelop::BackgroundParserPrivate::parseDocumentsInternal(this=)
+ 1645 at backgroundparser.cpp:314
frame #8: 0x0001099f2173
libKDevPlatformLanguage.10.dylib`KDevelop::BackgroundParser::parseDocuments(this=0x7fd764f05150)
+ 67 at backgroundparser.cpp:655
frame #9: 0x0001092ebde3 QtCore`QObject::event(this=,
e=) + 659 at qobject.cpp:1256
frame #10: 0x00010815e1e6
QtWidgets`QApplicationPrivate::notify_helper(this=,
receiver=0x7fd764f05150, e=0x7fd7526b97f0) + 294 at
qapplication.cpp:3804
frame #11: 0x000108161726
QtWidgets`QApplication::notify(this=, receiver=,
e=) + 8470 at qapplication.cpp:3767
frame #12: 0x0001092bf567
QtCore`QCoreApplication::notifyInternal2(receiver=0x7fd764f05150,
event=0x7fd7526b97f0) + 167 at qcoreapplication.cpp:1020
frame #13: 0x0001092c0166
QtCore`QCoreApplicationPrivate::sendPostedEvents(receiver=0x,
event_type=0, data=0x7fd762413de0) + 566 at qcoreapplication.h:225
frame #14: 0x00011391892e
libqcocoa.dylib`QCocoaEventDispatcherPrivate::processPostedEvents(this=0x7fd76275bca0)
+ 190 at qcocoaeventdispatcher.mm:883
frame #15: 0x000113919211
libqcocoa.dylib`QCocoaEventDispatcherPrivate::postedEventsSourceCallback(info=0x7fd76275bca0)
+ 33 at qcocoaeventdispatcher.mm:920
frame #16: 0x7fff8bb905b1
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
frame #17: 0x7fff8bb81c62 CoreFoundation`__CFRunLoopDoSources0 + 242
frame #18: 0x7fff8bb813ef CoreFoundation`__CFRunLoopRun + 831
frame #19: 0x7fff8bb80e75 CoreFoundation`CFRunLoopRunSpecific + 309
frame #20: 0x7fff8c2cca0d HIToolbox`RunCurrentEventLoopInMode + 226
frame #21: 0x7fff8c2cc685 HIToolbox`ReceiveNextEventCommon + 173
frame #22: 0x7fff8c2cc5bc
HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 65
frame #23: 0x7fff8589c24e AppKit`_DPSNextEvent + 1434
frame #24: 0x7fff8589b89b AppKit`-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
frame #25: 0x7fff8588f99c AppKit`-[NSApplication run] + 553
frame #26: 0x00011391808d
libqcocoa.dylib`QCocoaEventDispatcher::processEvents(this=0x7fd762759fa0,
flags=) + 2189 at qcocoaeventdispatcher.mm:416
frame #27: 0x0001092bb981
QtCore`QEventLoop::exec(QFlags) [inlined]
QEventLoop::processEvents(QFlags) + 401 at

[kdevplatform] [Bug 369278] debugger toolbar should remain put where user left it (and maintain its visibility)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369278

RJVB  changed:

   What|Removed |Added

 CC||7437...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 369238] KDevelop5 hang on exit in itemrepository.h (deleteItem())

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369238

RJVB  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 369278] New: debugger toolbar should remain put where user left it (and maintain its visibility)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369278

Bug ID: 369278
   Summary: debugger toolbar should remain put where user left it
(and maintain its visibility)
   Product: kdevplatform
   Version: git master
  Platform: Compiled Sources
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: debugger
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com
CC: niko.s...@gmail.com

The debugger toolbar has the nasty habit of reverting to its default location,
and reappearing in views where it's supposed to be hidden

Reproducible: Sometimes

Steps to Reproduce:
1. Put the debugger toolbar where you want it to be, possibly hiding it in the
standard code view
2. Quit the session
3. Reopen the session, possibly after having opened other sessions or with
another session open that has been kept open.

Actual Results:  
The debugger toolbar may or may not restore its previous location and
visibility.

Expected Results:  
The debugger toolbar reappears where it was told to be, and remains hidden if
it was told so.

Locking the toolbars has no effect whatsoever contrary to what one might
expect.

The "reset" appears to be triggered when anything else in the overall
windowstate changed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kxmlgui] [Bug 369276] New: KActionCollection, menu/action reuse and the native Mac menubar

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369276

Bug ID: 369276
   Summary: KActionCollection, menu/action reuse and the native
Mac menubar
   Product: frameworks-kxmlgui
   Version: unspecified
  Platform: Other
OS: OS X
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: kdelibs-b...@kde.org
  Reporter: rjvber...@gmail.com

I'm making another attempt at raising awareness about a Qt platform limitation
on Mac that has potentially severe implications for reuse of QMenus, QActions
and QActionWidgets in multiple menus if one of those is attached to a native
QMenuBar.

In short, this is not possible (because items attached to the native menubar
are reparented away from their original parent), and according to the
documentation it can lead to the menu items (be they actions or submenus) not
appearing or remaining disabled. The documentation isn't explicit which
instances might not appear or remain disabled; practical experience suggests
this only occurs in menus under the toplevel menubar.
Qt versions before 5.3 were not affected to the best of my knowledge; 5.4 and
5.5 would print error messages each time the software added an item to or
removed it from an additional menu.

In other words, the KActionCollection class is compromised on OS X, and that's
not exactly a class that sees only limited use.

The big problem here is that it is near impossible to predict which instances
will be affected. With earlier KTextEditor and Qt versions, for instance, I had
to disable the paste history and bookmarks menus to stop the error messages.
With Qt 5.6.1 and KTextEditor 5.24.0 it is the Mode and Highlighting menus that
are populated almost exclusively with disabled submenus.

The fact that items are reparented suggests that reusing them may also lead to
memory leak, accessing stale objects or double freeing (and indeed I have seen
some crashes that appeared related to menu item reuse).

The most effective solution I've found until now is to disable the native
menubar. Evidently this isn't ideal if the goal is to make KDE applications
look and behave as natively as possible. Also, just setting the
Qt::AA_DontUseNativeMenuBar attribute before any menus are created isn't enough
for all applications. Some may (like KHelpCenter) never show the menubar, some
(those that do not offer a hide/show menu feature like KDevelop) may start
unpredictably with the menubar in hidden state, or hide it at runtime in
reaction to some event.

The alternative solution is to avoid reuse on OS X, either in the source code
or in the ui.rc definition files but it is my experience that it isn't always
trivial to figure out what to disable where.

I've tried to get some answers about the underlying limitation from the Qt team
on one of their mailing lists, but it is probably worthwhile to start thinking
of workarounds independently. After all the official Qt stance may be "software
just shouldn't do this", like with QMenu::addSection() (which doesn't add a
named section on all platforms).



Reproducible: Sometimes

Steps to Reproduce:
1. Create QMenu, QAction and/or QActionWidget instances
2. Add them to a QMenuBar that corresponds to the Mac native, toplevel menubar
in addition to one or more other menu(bar)s


Actual Results:  
the instances (or items therein) may not appear or remain disabled, a priori
only in the toplevel menubar (but that may depend on the order of attribution).

Expected Results:  
All instances in all menu(bar)s appear and are enabled as expected

I'm hesitating between calling this a wishlist ticket and something stronger.
KActionCollection sees considerably widespread use, so I'm going to settle with
"Major".

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 306128] kdevelop crashs on launch after crash on remove project [ItemRepository::followerIndex assertion]

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=306128

--- Comment #5 from RJVB  ---
Let me copy part of the duplicate I just filed (through DrKonqi which didn't
find this report):

In a debug build the ASSERTS will provoke an abort in the situation that caused
my latest hang, but now that KDevelop5 has seen 2 release versions already
anomalies in deleteItem() should also be handled (as elegantly as possible) in
release builds.

Apparently currentIndex should never become 0. What would be the side-effects
of returning early from deleteItem(), i.e.

//If this assertion triggers, the deleted item was not registered under
the given hash
Q_ASSERT(currentIndex);
+if (!currentIndex) {
+return;
+}

It seems deleteItem() has no business trying to delete an item that's not
registered under the current hash, but not doing anything may mean we'll end up
in slightly larger closed loop, calling deleteItem() on the same item
indefinitely?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 369238] KDevelop5 hang on exit in itemrepository.h (deleteItem())

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369238

--- Comment #2 from RJVB  ---
DrKonqi c/should have picked up that report...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 369238] KDevelop5 hang on exit in itemrepository.h (deleteItem())

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369238

RJVB  changed:

   What|Removed |Added

 CC||kf...@kde.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 369238] New: KDevelop5 hang on exit in itemrepository.h (deleteItem())

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369238

Bug ID: 369238
   Summary: KDevelop5 hang on exit in itemrepository.h
(deleteItem())
   Product: kde
   Version: unspecified
  Platform: unspecified
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: rjvber...@gmail.com

Application: kdevelop5 (5.0.1)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Linux 4.5.7-ck1-mainline-core2-rjvb x86_64
Distribution: Ubuntu 14.04.5 LTS

-- Information about the crash:
- What I was doing when the application crashed:

This was a session that I had launched only to check a few aspects of the CMake
manager's build dir settings. After telling it to exit it remained stuck as
shown in the backtrace, consuming close to 100% CPU.

This has been discussed before. In a debug build the ASSERTS will provoke an
abort, but now that KDevelop5 has seen 2 release versions already anomalies in
deleteItem() should also be handled (as elegantly as possible) in release
builds.

Apparently currentIndex should never become 0. What would be the side-effects
of returning early from deleteItem(), i.e.

//If this assertion triggers, the deleted item was not registered under
the given hash
Q_ASSERT(currentIndex);
if (!currentIndex) {
return;
}

It seems deleteItem() has no business trying to delete an item that's not
registered under the current hash, but not doing anything may mean we'll end up
in slightly larger closed loop, calling deleteItem() on the same item
indefinetely?

The crash can be reproduced sometimes.

-- Backtrace:
Application: KDevelop (kdevelop5), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fb515f1b780 (LWP 20525))]

Thread 8 (Thread 0x7fb4f533b700 (LWP 20528)):
#0  0x7fb512c7cfdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fb505d95b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7fb505d9764f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fb4f7fb1ac9 in QXcbEventReader::run (this=0x15adde0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1325
#4  0x7fb51332bd29 in QThreadPrivate::start (arg=0x15adde0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#5  0x7fb50ca37184 in start_thread (arg=0x7fb4f533b700) at
pthread_create.c:312
#6  0x7fb512c8a37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 7 (Thread 0x7fb4efde4700 (LWP 20529)):
#0  0x7fb50ca3955a in __GI___pthread_mutex_lock (mutex=0x7fb4e8000a50) at
../nptl/pthread_mutex_lock.c:125
#1  0x7fb50bbf3981 in g_mutex_lock (mutex=mutex@entry=0x7fb4e8000990) at
/build/buildd/glib2.0-2.40.2/./glib/gthread-posix.c:209
#2  0x7fb50bbb1699 in g_main_context_prepare
(context=context@entry=0x7fb4e8000990, priority=priority@entry=0x7fb4efde3cf8)
at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3354
#3  0x7fb50bbb1f03 in g_main_context_iterate
(context=context@entry=0x7fb4e8000990, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3714
#4  0x7fb50bbb20ec in g_main_context_iteration (context=0x7fb4e8000990,
may_block=may_block@entry=1) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795
#5  0x7fb5135476fb in QEventDispatcherGlib::processEvents
(this=0x7fb4e80008c0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:419
#6  0x7fb5134f162a in QEventLoop::exec (this=this@entry=0x7fb4efde3e20,
flags=..., flags@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventloop.cpp:204
#7  0x7fb51332701b in QThread::exec (this=this@entry=0x7fb51532e420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread.cpp:500
#8  0x7fb5150bd615 in QDBusConnectionManager::run (this=0x7fb51532e420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/dbus/qdbusconnection.cpp:189
#9  0x7fb51332bd29 in 

[kde] [Bug 369237] New: KDevelop5 hang on exit in itemrepository.h (deleteItem())

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369237

Bug ID: 369237
   Summary: KDevelop5 hang on exit in itemrepository.h
(deleteItem())
   Product: kde
   Version: unspecified
  Platform: unspecified
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: rjvber...@gmail.com

Application: kdevelop5 (5.0.1)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Linux 4.5.7-ck1-mainline-core2-rjvb x86_64
Distribution: Ubuntu 14.04.5 LTS

-- Information about the crash:
- What I was doing when the application crashed:

This was a session that I had launched only to check a few aspects of the CMake
manager's build dir settings. After telling it to exit it remained stuck as
shown in the backtrace, consuming close to 100% CPU.

This has been discussed before. In a debug build the ASSERTS will provoke an
abort, but now that KDevelop5 has seen 2 release versions already anomalies in
deleteItem() should also be handled (as elegantly as possible) in release
builds.

Apparently currentIndex should never become 0. What would be the side-effects
of returning early from deleteItem(), i.e.

//If this assertion triggers, the deleted item was not registered under
the given hash
Q_ASSERT(currentIndex);
if (!currentIndex) {
return;
}

It seems deleteItem() has no business trying to delete an item that's not
registered under the current hash, but not doing anything may mean we'll end up
in slightly larger closed loop, calling deleteItem() on the same item
indefinetely?

The crash can be reproduced sometimes.

-- Backtrace:
Application: KDevelop (kdevelop5), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fb515f1b780 (LWP 20525))]

Thread 8 (Thread 0x7fb4f533b700 (LWP 20528)):
#0  0x7fb512c7cfdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fb505d95b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7fb505d9764f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fb4f7fb1ac9 in QXcbEventReader::run (this=0x15adde0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1325
#4  0x7fb51332bd29 in QThreadPrivate::start (arg=0x15adde0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#5  0x7fb50ca37184 in start_thread (arg=0x7fb4f533b700) at
pthread_create.c:312
#6  0x7fb512c8a37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 7 (Thread 0x7fb4efde4700 (LWP 20529)):
#0  0x7fb50ca3955a in __GI___pthread_mutex_lock (mutex=0x7fb4e8000a50) at
../nptl/pthread_mutex_lock.c:125
#1  0x7fb50bbf3981 in g_mutex_lock (mutex=mutex@entry=0x7fb4e8000990) at
/build/buildd/glib2.0-2.40.2/./glib/gthread-posix.c:209
#2  0x7fb50bbb1699 in g_main_context_prepare
(context=context@entry=0x7fb4e8000990, priority=priority@entry=0x7fb4efde3cf8)
at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3354
#3  0x7fb50bbb1f03 in g_main_context_iterate
(context=context@entry=0x7fb4e8000990, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3714
#4  0x7fb50bbb20ec in g_main_context_iteration (context=0x7fb4e8000990,
may_block=may_block@entry=1) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795
#5  0x7fb5135476fb in QEventDispatcherGlib::processEvents
(this=0x7fb4e80008c0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:419
#6  0x7fb5134f162a in QEventLoop::exec (this=this@entry=0x7fb4efde3e20,
flags=..., flags@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventloop.cpp:204
#7  0x7fb51332701b in QThread::exec (this=this@entry=0x7fb51532e420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread.cpp:500
#8  0x7fb5150bd615 in QDBusConnectionManager::run (this=0x7fb51532e420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/dbus/qdbusconnection.cpp:189
#9  0x7fb51332bd29 in 

[kate] [Bug 369207] Mode & Highlighting menus remain empty on Mac OS X

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369207

--- Comment #5 from RJVB  ---
Created attachment 101240
  --> https://bugs.kde.org/attachment.cgi?id=101240=edit
Patch to work around the issue on OS X

Moving the Mode and Highlighting menus into the popup/context menu makes them
behave as expected. It seems at least the Mode menu becomes better behaved when
a copy is preserved in the toplevel menubar, but there's little point in
keeping potentially broken copies around.

The patch also provides a number of more Mac-like shortcuts for typical menu
actions.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 369207] Mode & Highlighting menus remain empty on Mac OS X

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369207

--- Comment #4 from RJVB  ---
According to QMenu::isEnabled() and QAction::isEnabled(), the submenus and
their actions are all enabled.

However, according to the QMenu documentation:

QMenu on OS X with Qt Build Against Cocoa

QMenu can be inserted only once in a menu/menubar. Subsequent insertions
will have no effect or will result in a disabled menu item.

See the Menus example for an example of how to use QMenuBar and QMenu in
your application.

and according to the QWidgetAction docs:

OS X: If you add a widget to a menu in the application's menu bar on OS X,
the widget will be added and it will function but with some limitations:

1. The widget is reparented away from the QMenu to the native menu
view. If you show the menu in some other place (e.g. as a popup menu), the
widget will not be there.

So it seems we're looking at a similar error/limitation as the one that
previously led to error messages about menu items being added to or removed
from more than 1 menu. Those messages no longer appear in Qt 5.6, but clearly
the underlying reason is still there.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 369227] New: relative build directories

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369227

Bug ID: 369227
   Summary: relative build directories
   Product: kdevelop
   Version: unspecified
  Platform: Other
OS: All
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: all build tools
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

Working on a few projects on different hosts I realised I'm missing a feature
from Xcode I never gave much thought too. Come to think of it, I think MSVC has
this feature too:

You can take a source tree containing an Xcode project anywhere (via git
checkout, or say on an external disk), open the project in the IDE on no matter
what host with a compatible Xcode version, and it will build without having to
redefine the build location.

This is (presumably) because they store the build directory as a path that's
relative to the project file.

I realise that CMake and possibly QMake too store full paths in the Makefiles
they generate, but even with that limitation it is still useful to have support
for relative build directories for projects shared via VCS.

Reproducible: Always

Steps to Reproduce:
1. Set up a project and export it to a VCS like git, including the .kdev4
project file and directory.
2. Check out the project on a host with a different filesystem layout, in a
different location on the same host or as another user.
3. Open the cloned project.

Actual Results:  
The build directory will not be found and will be expected in an inappropriate
location. Or possibly the original build directory will be used (when the a
working copy was made in a different location on the same host).

Expected Results:  
The build directory might not exist in the initial working copy but it should
still be expected at the same location relative to the project file. With
KDevelop that could be the CMake/QMake/whatever file that contains the actual
project description, or the foo.kdev4 file.

Xcode also makes collaboration easier by storing certain project settings in
user-specific files which would typically not be under version control.
KDevelop could do the same in the .kdev4 directory:

foo/.kdev4/foo.kdev4 : shared settings
foo/.kdev4/${LOGNAME}.kdev4 : user-specific settings

Prime candidates for such user-specific settings would be the selected build
directory but also absolute build directories (esp. if they're under the user's
$HOME) or simply build directories that were marked private during their
declaration, because any of their settings contain something user or
host-specific.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-ktexteditor] [Bug 256561] Katepart scrolls per paragraph rather than what is set globally (e.g. 3 lines)

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=256561

RJVB  changed:

   What|Removed |Added

 CC||rjvber...@gmail.com

--- Comment #23 from RJVB  ---
Unrelated, but since someone is looking at scrolling behaviour: it would be
very nice if Kate and Kate-based applications would stop zooming when one hits
the Ctrl key to activate a shortcut when inertial scrolling events are still
coming in. I think Qt already takes care of this on OS X with information that
isn't available on X11.

Thomas Lübking and I designed a PoC class inheriting QTextBrowser and adding a
relatively simple wheelEvent() override: http://github.com/RJVB/qtwheeltest .

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 369207] Mode & Highlighting menus remain empty on Mac OS X

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369207

--- Comment #3 from RJVB  ---
So this appears to be related to using the Mac toplevel menubar: adding 

QCoreApplication::setAttribute(Qt::AA_DontUseNativeMenuBar);

to main() gives functional and populated Mode an Highlighting menus too.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 369207] Mode & Highlighting menus remain empty on Mac OS X

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369207

--- Comment #2 from RJVB  ---
Created attachment 101236
  --> https://bugs.kde.org/attachment.cgi?id=101236=edit
screenshot of KDevelop running in X11 mode on OS X, showing a normal Tools/Mode
menu (with an additional item)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 369207] Mode & Highlighting menus remain empty on Mac OS X

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369207

--- Comment #1 from RJVB  ---
Created attachment 101235
  --> https://bugs.kde.org/attachment.cgi?id=101235=edit
screenshot of KDevelop running in native mode on OS X, showing the crippled
Tools/Mode menu

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 369207] New: Mode & Highlighting menus remain empty on Mac OS X

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=369207

Bug ID: 369207
   Summary: Mode & Highlighting menus remain empty on Mac OS X
   Product: kate
   Version: 16.08
  Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: part
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

I noticed that the Tools/Mode and Tools/Highlighting menus remain empty, except
for the *disabled* submenus for the various known categories and the items:

"Normal" & "New Filetype" in Tools/Mode
and
"None" in Tools/Highlighting

Both Kate5 and KDevelop5 are affected.

Curiously this happens only when I use Qt's normal/default Cocoa QPA; when I
start the applications in X11 mode (`-platform xcb`) the menus behave normally.

See the screenshots I'll be attaching.

I'm currently using Kate 16.08.0 and KTextEditor 5.24.0

Reproducible: Always

Steps to Reproduce:
1. Start Kate5 or KDevelop5
2. Open a document of a supported type for which highlighting definitions exist
3. Check the Tools/Mode and Tools/Highlighting menus

Actual Results:  
See the Cocoa screenshot and notice how the submenus are present but disabled.
The New Filetype menu item has no effect.

Expected Results:  
See the XCB screenshot: populated submenus

The highlighting mode can be selected normally via the status bar widget, so
the issue cannot be explained by missing highlighting definitions.

The same software versions do NOT have the "New Filetype" Tools/Mode menu item
on Linux.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 368965] Crash when clicking on Table button in top menu bar [patch]

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368965

--- Comment #5 from RJVB  ---
I haven't been able to reproduce this crash, but I'll incorporate it in my
port. Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #21 from RJVB  ---
I'd have to figure out how to start a debugging session in lldb-mi manually, in
order to check this correctly :)
But: did you ever notice how starting the debugger on a C++ app using KDE or Qt
takes so much longer than starting it on a simple C app? That's because it has
to scan through many more libraries containing many more and considerably more
complex types. Maybe not all that scanned information is cached, but a good
part is. It seems a bit weird that it would let the process image reach 6Gb but
then there are so many different kinds of memory footprint nowadays, some of
which are purely virtual (with overcommit and all) that I don't trust myself to
notice the one that corresponds to actual memory use when the system is being
trashed.

FWIW, I've the kernel overcommit parameter set to 2 on my system, but that
shouldn't affect the amount of memories applications request nor increase the
amount they actually get.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #19 from RJVB  ---
Yes, at least as far as starting with a break in main goes. I didn't go much
beyond testing that; lldb-mi-3.9 took so much memory when I tried with a simple
Qt5 app that my whole plasma4 environment was OOM'ed.

One detail though: is a patched lldb-mi required for the correct change of
working directory? Because that detail doesn't work with the lldb plugin on
Linux even though the debug output suggests it does.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368928] New: crash while quitting KDevelop with a debug session still open

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368928

Bug ID: 368928
   Summary: crash while quitting KDevelop with a debug session
still open
   Product: kde
   Version: unspecified
  Platform: unspecified
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: rjvber...@gmail.com

Application: kdevelop5 (5.0.0)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Linux 4.5.7-ck1-mainline-core2-rjvb x86_64
Distribution: Ubuntu 14.04.5 LTS

-- Information about the crash:
- What I was doing when the application crashed:

I had been testing the debugging of a simple Qt5 application using the lldb
plugin and lldb-mi-3.9 .
When that session became unresponsive due to excessive memory usage by the
debugger I first hit the Stop All toolbar button, and then KDevelop's window
close button before the debug session (and view) had been closed completely.

- Unusual behaviour I noticed:

My whole plasma (4) desktop had come down except for KWin.

-- Backtrace:
Application: KDevelop (kdevelop5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f8cf779e780 (LWP 15415))]

Thread 5 (Thread 0x7f8cd6bbf700 (LWP 15416)):
#0  0x7f8cf4500fdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f8ce7619b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f8ce761b64f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f8cd9835ac9 in QXcbEventReader::run (this=0x1c67df0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1325
#4  0x7f8cf4bafd29 in QThreadPrivate::start (arg=0x1c67df0) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#5  0x7f8cee2bb184 in start_thread (arg=0x7f8cd6bbf700) at
pthread_create.c:312
#6  0x7f8cf450e37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7f8cd56c6700 (LWP 15417)):
#0  0x7f8ced47761a in g_mutex_get_impl (mutex=0x7f8cc8000990) at
/build/buildd/glib2.0-2.40.2/./glib/gthread-posix.c:120
#1  0x7f8ced4779a9 in g_mutex_unlock (mutex=mutex@entry=0x7f8cc8000990) at
/build/buildd/glib2.0-2.40.2/./glib/gthread-posix.c:228
#2  0x7f8ced435ef6 in g_main_context_iterate
(context=context@entry=0x7f8cc8000990, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3712
#3  0x7f8ced4360ec in g_main_context_iteration (context=0x7f8cc8000990,
may_block=may_block@entry=1) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795
#4  0x7f8cf4dcb6fb in QEventDispatcherGlib::processEvents
(this=0x7f8cc80008c0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:419
#5  0x7f8cf4d7562a in QEventLoop::exec (this=this@entry=0x7f8cd56c5e20,
flags=..., flags@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventloop.cpp:204
#6  0x7f8cf4bab01b in QThread::exec (this=this@entry=0x7f8cf6bb2420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread.cpp:500
#7  0x7f8cf6941615 in QDBusConnectionManager::run (this=0x7f8cf6bb2420
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/dbus/qdbusconnection.cpp:189
#8  0x7f8cf4bafd29 in QThreadPrivate::start (arg=0x7f8cf6bb2420 <(anonymous
namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#9  0x7f8cee2bb184 in start_thread (arg=0x7f8cd56c6700) at
pthread_create.c:312
#10 0x7f8cf450e37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7f8cc4926700 (LWP 15422)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1  0x7f8cf4bb0a66 in wait_relative (time=1000, this=0x25a1310) at

[kdevelop] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #17 from RJVB  ---
Thanks, but I just found the reason when I tried a manual debugging session.
Turns out it's more a bug in the lldb-3.9 package: it doesn't install
non-versioned binaries, but it wants an lldb-server executable.

That also explains why it worked before (when I still had a working ll**-3.8
install) and no longer after I upgraded to 3.9.0 . I noticed the issue just too
long after that upgrade so I didn't make the link (mental link, not symlink)
:-/

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 368905] New: a shell is started even when the konsole plugin isn't loaded

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368905

Bug ID: 368905
   Summary: a shell is started even when the konsole plugin isn't
loaded
   Product: kate
   Version: 16.08
  Platform: Compiled Sources
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: application
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

Even when Kate's konsole plugin isn't loaded (used), a shell is started when a
document is opened.

Reproducible: Always

Steps to Reproduce:
A:
1. Start Kate so that it's stdout and stderr are connected to a terminal
2. Quit.

B:
1. Start Kate so that it's stdout and stderr are connected to a terminal
2. Open a document
3. Quit.



Actual Results:  
A:
No warnings about shells on exit.

B:
shell did not close, sending SIGHUP
Process  37896  did not die with SIGHUP

I see the same "sending SIGHUP" message on Linux, but there the shell
apparently reacts as expected to the signal.

Expected Results:  
There appears to be no reason to start a shell when the konsole plugin isn't
being used.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 364807] KWrite does not sport its icon.

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364807

RJVB  changed:

   What|Removed |Added

 CC||rjvber...@gmail.com

--- Comment #2 from RJVB  ---
FWIW, the correct cross-platform way of getting the icon to show up in task
switchers, Docks etc. is something along the lines of

app.setWindowIcon(QIcon::fromTheme("appIconName", app.windowIcon()));

this avoids replacing the application icon (resource) installed in or with the
application with an empty icon; as a general rule of thumb one can say that
platforms either store the app icon resource with the app (OS X, MS Windows) or
else they use an icon from a user-selectable icon theme from some central
location.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #15 from RJVB  ---
No, I didn't tick the "don't ask again option". I checked with an unpatched
lldb 3.8.1 on OS X and I indeed got the warning in the debugger console, but
IIRC everything else was functional.

No, on Linux I get something else: it looks like the debug session is being
created as expected, and then the IDE falls back into the regular code view.
Which means I cannot even get at the debugger console to check for any relevant
output there.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 368568] Crash when quitting KDevelop with a patch review open

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368568

RJVB  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from RJVB  ---
A crash deep in Qt can occur because of something done wrong in the dependent
code; are you sure that's not the case here?

Can you reproduce the issue?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #12 from RJVB  ---
(In reply to Aetf from comment #8)

> Could you try if this works for you?

It works in the sense that it rejects Apple-style version reporting ...

With these hunks I get a functional LLDB plugin again:
```
@@ -381,9 +393,40 @@ void DebugSession::handleCoreFile(const QStringList )

 void DebugSession::handleVersion(const QStringList& s)
 {
+m_hasCorrectCLIOutput = !s.isEmpty();
+if (!m_hasCorrectCLIOutput) {
+// No output from 'version' command. It's likely that
+// the lldb used is not patched for the CLI output
+
+if (!qobject_cast(qApp))  {
+//for unittest
+qFatal("You need a graphical application.");
+}
+
+auto ans = KMessageBox::warningYesNo(
+qApp->activeWindow(),
+i18n("Your lldb-mi version is unsupported, as it lacks an
essential patch."
+ "See https://llvm.org/bugs/show_bug.cgi?id=28026 for more
information."
+ "Debugger console will be disabled to prevent crash."
+ "Do you want to continue?"),
+i18n("LLDB Version Unsupported"),
+KStandardGuiItem::yes(),
+KStandardGuiItem::no(),
+"unsupported-lldb-debugger");
+if (ans == KMessageBox::ButtonCode::No) {
+programFinished("Stopped because of unsupported LLDB version");
+stopDebugger();
+}
+return;
+}
+
 qCDebug(DEBUGGERLLDB) << s.first();

+#ifdef Q_OS_OSX
+QRegularExpression rx("^lldb-(\\d+).(\\d+).(\\d+)\\b",
QRegularExpression::MultilineOption);
+#else
 QRegularExpression rx("^lldb version: (\\d+).(\\d+).(\\d+)\\b",
QRegularExpression::MultilineOption);
+#endif
 auto match = rx.match(s.first());
 int version[] = {0, 0, 0};
 if (match.hasMatch()) {
@@ -394,7 +437,12 @@ void DebugSession::handleVersion(const QStringList& s)

 // minimal version is 3.8.1
 bool ok = true;
+#ifdef Q_OS_OSX
+// lldb 3.8.1 reports version 350.99.0 on OS X
+const int min_ver[] = {350, 99, 0};
+#else
 const int min_ver[] = {3, 8, 1};
+#endif
 for (int i = 0; i < 3; ++i) {
 if (version[i] < min_ver[i]) {
 ok = false;
```

Unrelated: for some reason I can no longer use the lldb plugin on Linux. It
starts, but then "drops out of" the debugging view, back into the code view.
Any ideas?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #11 from RJVB  ---
I'll try tomorrow, but how do you handle the case where you cannot determine
the version of a perfectly acceptable lldb-mi? Again, the user may not have
much choice to install a patched lldb-mi (think users on OS X).

As to using liblldb: this *is* the preferred way to write a GUI for lldb.
Pretty sure it's how Xcode interfaces to the debugger; there's also a
(commercial) GUI for lldb that almost certainly does the same thing. Let's be
honest, it's the most direct way to control the debugger; rather than figuring
out how to control an existing driver that's tailored for another kind of
application you send exactly the commands you want, without having to parse
text replies which may not be perfectly adequate for what you want.

Best you can do in this aspect is ask on the lldb ML, to get an uptodate
opinion and hopefuly also some feedback on how lldb-mi is perceived. When I
asked I got a strong impression it was seen as a 2nd-class citizen that existed
only for Eclipse and that would likely never evolve towards a full MI
implementation.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 368568] Crash when quitting KDevelop with a patch review open

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368568

--- Comment #1 from RJVB  ---
Application: kdevelop5 (5.0.0) git v5.0.0-257-gff07af4 / v4.90.91-551-g4a90319

 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Linux 4.5.7-ck1-mainline-core2-rjvb x86_64
Distribution: Ubuntu 14.04.5 LTS

-- Information about the crash:
- What I was doing when the application crashed:

This crash occurs systematically when I exit KDevelop with the patchreview
toolview still open.

The crash can be reproduced every time.

-- Backtrace:
Application: KDevelop (kdevelop5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fede9e4c780 (LWP 19130))]

Thread 10 (Thread 0x7fedc9f92700 (LWP 19131)):
#0  0x7fede6bb1fdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fedd9cdbb72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7fedd9cdd64f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fedcc9e2b09 in QXcbEventReader::run (this=0x1827c10) at
/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1325
#4  0x7fede7260c99 in QThreadPrivate::start (arg=0x1827c10) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#5  0x7fede096d184 in start_thread (arg=0x7fedc9f92700) at
pthread_create.c:312
#6  0x7fede6bbf37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 9 (Thread 0x7fedc8a99700 (LWP 19132)):
#0  g_source_iter_next (iter=iter@entry=0x7fedc8a98c80,
source=source@entry=0x7fedc8a98c78) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:931
#1  0x7feddfae762b in g_main_context_prepare
(context=context@entry=0x7fedbc000990, priority=priority@entry=0x7fedc8a98cf8)
at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3330
#2  0x7feddfae7f03 in g_main_context_iterate
(context=context@entry=0x7fedbc000990, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3714
#3  0x7feddfae80ec in g_main_context_iteration (context=0x7fedbc000990,
may_block=may_block@entry=1) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795
#4  0x7fede747c62b in QEventDispatcherGlib::processEvents
(this=0x7fedbc0008c0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:419
#5  0x7fede742656a in QEventLoop::exec (this=this@entry=0x7fedc8a98e20,
flags=..., flags@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventloop.cpp:204
#6  0x7fede725bf8b in QThread::exec (this=this@entry=0x7fede925e400
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread.cpp:500
#7  0x7fede8fed605 in QDBusConnectionManager::run (this=0x7fede925e400
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/dbus/qdbusconnection.cpp:189
#8  0x7fede7260c99 in QThreadPrivate::start (arg=0x7fede925e400 <(anonymous
namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#9  0x7fede096d184 in start_thread (arg=0x7fedc8a99700) at
pthread_create.c:312
#10 0x7fede6bbf37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 8 (Thread 0x7fedb83e2700 (LWP 19134)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
#1  0x7fede72619d6 in wait_relative (time=1000, this=0x2149f80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:126
#2  wait (time=1000, this=0x2149f80) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:134
#3  QWaitCondition::wait (this=this@entry=0x2143308,
mutex=mutex@entry=0x2143310, time=time@entry=1000) at

[kdevelop] [Bug 368568] Crash when quitting KDevelop with a patch review open

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368568

RJVB  changed:

   What|Removed |Added

 OS|OS X|All
Version|5.0.0   |git master

-- 
You are receiving this mail because:
You are watching all bug changes.

[konversation] [Bug 364899] konversation5 crashes on exit

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364899

RJVB  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from RJVB  ---
Reopening as not fixed at all, or broken anew.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konversation] [Bug 368682] another konversation5 crash at exit

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368682

--- Comment #1 from RJVB  ---
Happens on Linux too.

In addition, DrKonqi insists that this is the same crash as the closed bug
364988, so that one wasn't fixed at all apparently.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konversation] [Bug 368682] New: another konversation5 crash at exit

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368682

Bug ID: 368682
   Summary: another konversation5 crash at exit
   Product: konversation
   Version: unspecified
  Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: konversation-de...@kde.org
  Reporter: rjvber...@gmail.com

Application: konversation (1.6-master #5006)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Darwin 13.4.0 x86_64
Distribution (Platform): MacPorts Packages

-- Information about the crash:
- What I was doing when the application crashed:

Just like the previous crash (bug 364899), this crash occurs at exit even if I
only start the application and quit it immediately.

Built from commit #43190f3b8b1f4d27a4350a2306665ac4e360bd5e

I haven't tried on Linux yet.

The crash can be reproduced every time.

-- Backtrace:
Application: Konversation (konversation), signal: Segmentation fault: 11
(lldb) process attach --pid 52835
Process 52835 stopped
Executable module set to
"/Applications/MacPorts/KF5/konversation.app/Contents/MacOS/konversation".
Architecture set to: x86_64-apple-macosx.
(lldb) set set term-width 200
(lldb) thread info
thread #1: tid = 0xc4edfb, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 +
8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

(lldb) bt all
* thread #1: tid = 0xc4edfb, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x000109635fe2 libKF5Crash.5.dylib`KCrash::startProcess(int,
char const**, bool) + 135
frame #2: 0x000109635e06
libKF5Crash.5.dylib`KCrash::defaultCrashHandler(int) + 1049
frame #3: 0x7fff81b8c5aa libsystem_platform.dylib`_sigtramp + 26
frame #4: 0x00010b746417
QtCore`QThreadStorageData::get(this=0x) const + 39 at
qthreadstorage.cpp:117
frame #5: 0x00010afe04b6 QtGui`QOpenGLContext::currentContext()
[inlined] QGuiGLThreadContext*&
qThreadStorage_localData(d=0x) + 8 at
qthreadstorage.h:65
frame #6: 0x00010afe04ae QtGui`QOpenGLContext::currentContext()
[inlined]
QThreadStorage::localData(this=0x) at
qthreadstorage.h:139
frame #7: 0x00010afe04ae QtGui`QOpenGLContext::currentContext() + 14 at
qopenglcontext.cpp:415
frame #8: 0x00010afb26a9
QtGui`QSurface::~QSurface(this=0x7f80b1f94d40) + 25 at qsurface.cpp:127
frame #9: 0x00010afa9e08
QtGui`QWindow::~QWindow(this=0x7f80b1f94d30) + 72 at qwindow.cpp:207
frame #10: 0x00010a75036e QtWidgets`QWidgetWindow::~QWidgetWindow()
[inlined] QWidgetWindow::~QWidgetWindow(this=0x7f80b1f94d30) + 14 at
qwidgetwindow.cpp:131
frame #11: 0x00010a750369
QtWidgets`QWidgetWindow::~QWidgetWindow(this=0x7f80b1f94d30) + 9 at
qwidgetwindow.cpp:131
frame #12: 0x00010a7209f2
QtWidgets`QWidgetPrivate::deleteTLSysExtra(this=0x7f80b1ea1cc0) + 322 at
qwidget.cpp:1890
frame #13: 0x00010a72069e
QtWidgets`QWidget::destroy(this=, destroyWindow=,
destroySubWindows=) + 830 at qwidget.cpp:12297
frame #14: 0x00010a71fe2e
QtWidgets`QWidget::~QWidget(this=0x7f80b1ea1570) + 1486 at qwidget.cpp:1679
frame #15: 0x00010a86d5ae QtWidgets`QMenu::~QMenu() [inlined]
QMenu::~QMenu(this=0x7f80b1ea1570) + 14 at qmenu.cpp:1495
frame #16: 0x00010a86d5a9
QtWidgets`QMenu::~QMenu(this=0x7f80b1ea1570) + 9 at qmenu.cpp:1495
frame #17: 0x00010b932473
QtCore`QObjectPrivate::deleteChildren(this=0x7f80b1e9f040) + 243 at
qobject.cpp:1963
frame #18: 0x00010a71fe12
QtWidgets`QWidget::~QWidget(this=0x7f80b1e9e9c0) + 1458 at qwidget.cpp:1674
frame #19: 0x00010a86d5ae QtWidgets`QMenu::~QMenu() [inlined]
QMenu::~QMenu(this=0x7f80b1e9e9c0) + 14 at qmenu.cpp:1495
frame #20: 0x00010a86d5a9
QtWidgets`QMenu::~QMenu(this=0x7f80b1e9e9c0) + 9 at qmenu.cpp:1495
frame #21: 0x00010931ba56
konversation`IrcContextMenus::~IrcContextMenus(this=0x7f80b1b44400) + 38 at
irccontextmenus.cpp:86
frame #22: 0x000109321eba konversation`(anonymous
namespace)::Q_QGS_s_ircContextMenusPrivate::innerFunction()::Cleanup::~Cleanup()
[inlined] IrcContextMenus::~IrcContextMenus(this=0x7f80b1b44400) + 26 at
irccontextmenus.cpp:85
frame #23: 0x000109321eb2 konversation`(anonymous
namespace)::Q_QGS_s_ircContextMenusPrivate::innerFunction()::Cleanup::~Cleanup()
[inlined]
IrcContextMenusPrivate::~IrcContextMenusPrivate(this=0x7f80b1b44400) at
irccontextmenus.cpp:66
frame #24: 0x000109321eb2 konversation`(anonymous
namespace)::Q_QGS_s_ircContextMenusPrivate::innerFunction()::Cleanup::~Cleanup()
[inlined]

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #7 from RJVB  ---
One more thought: I don't think you can expect that every user will have a
patched lldb-mi anytime soon, so I'd advise to add a workaround like the one I
posted. I don't really see any other way how you could handle the situation,
other than falling back to using the commandline argument. You could post a
warning that the lldb version cannot be verified, but that should be a warning
that can be set to "don't show again". 

There's one alternative though: check the command *name*. It's quite common
that the clang drivers have at least the branch in their name (3.9 in my case).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #6 from RJVB  ---
With the patch I get 

> lldb-mi-mp-3.9
(gdb)
version
~"lldb-360.99.0\n"
^done
(gdb)

A year or two ago I asked about using the lldb-mi driver, on the lldb mailing
list. I was told that the really clever thing to do for integrating lldb into
an IDE (or writing a UI for it) would be to use liblldb directly

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #4 from RJVB  ---
No, I didn't apply that patch, I'm just running 3.9.0 (release).

> lldb-mi-mp-3.9 --versionLong
LLDB Machine Interface Driver (MI) All rights reserved
Version: 1.0.0.9
Version: GNU gdb (GDB) 7.4 
(This is a MI stub on top of LLDB and not GDB)
All rights reserved.

> lldb-mi-mp-3.9 
(gdb)
version
lldb-360.99.0
^done
(gdb)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

RJVB  changed:

   What|Removed |Added

 CC||7437...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #2 from RJVB  ---
I think this happens because/when DebugSession::handleVersion() is called with
an empty QStringList argument.

Why that would happen I have no idea, possible it's related to commit
102f673c6ff1afe5b1ca9cb6faa0503663b96e16 ("LLDB plugin: check LLDB version
rather than lldb-mi version, which doesn't change frequently"). If that does
what I think it does it tries to invoke lldb, which may not be in the path.

Either way, returning early from handleVersion() works around the crash and
allows the debugger to function:

```
diff --git a/debuggers/lldb/debugsession.cpp b/debuggers/lldb/debugsession.cpp
index 448d3ea..e4e5c22 100644
--- a/debuggers/lldb/debugsession.cpp
+++ b/debuggers/lldb/debugsession.cpp
@@ -381,6 +381,10 @@ void DebugSession::handleCoreFile(const QStringList )

 void DebugSession::handleVersion(const QStringList& s)
 {
+if (s.isEmpty()) {
+// silently do nothing if s is empty
+return;
+}
 qCDebug(DEBUGGERLLDB) << s.first();

 QRegularExpression rx("^lldb version: (\\d+).(\\d+).(\\d+)\\b",
QRegularExpression::MultilineOption);
```

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 368603] crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

--- Comment #1 from RJVB  ---
Backtrace on OS X :

Backtrace of the crash I experienced:

Application: KDevelop (kdevelop), signal: Segmentation fault: 11
(lldb) process attach --pid 32720
Process 32720 stopped
Executable module set to
"/Applications/MacPorts/KF5/kdevelop.app/Contents/MacOS/kdevelop.bin".
Architecture set to: x86_64-apple-macosx.
(lldb) set set term-width 200
(lldb) thread info
thread #1: tid = 0xbfd384, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 +
8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

(lldb) bt all
* thread #1: tid = 0xbfd384, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x0001070c4fe2 libKF5Crash.5.dylib`KCrash::startProcess(int,
char const**, bool) + 135
frame #2: 0x0001070c4e06
libKF5Crash.5.dylib`KCrash::defaultCrashHandler(int) + 1049
frame #3: 0x7fff81b8c5aa libsystem_platform.dylib`_sigtramp + 26
frame #4: 0x00010998ec23 QtCore`QRegularExpression::match(QString
const&, int, QRegularExpression::MatchType,
QFlags) const [inlined]
QString::length(this=0x000109d084a0) const + 4 at qstring.h:866
frame #5: 0x00010998ec1f
QtCore`QRegularExpression::match(this=0x7fff58dba8e0,
subject=0x000109d084a0, offset=0, matchType=NormalMatch,
matchOptions=) const + 47 at qregularexpression.cpp:1712
frame #6: 0x00011dd22b28
kdevlldb.so`KDevMI::LLDB::DebugSession::handleVersion(this=0x7f91a3b38870,
s=0x7f91a3f28678) + 296 at debugsession.cpp:387
frame #7: 0x00011dd33fcf
kdevlldb.so`KDevMI::MI::MICommand::invokeHandler(this=0x7f91a3f28650,
r=0x7f919bc96760) + 47 at micommand.cpp:111
frame #8: 0x00011dd39755
kdevlldb.so`KDevMI::MIDebugger::processLine(this=,
line=) + 2213 at midebugger.cpp:198
frame #9: 0x00011dd37d48
kdevlldb.so`KDevMI::MIDebugger::readyReadStandardOutput(this=) +
248 at midebugger.cpp:135
frame #10: 0x000109ac84b6 QtCore`QMetaObject::activate(QObject*, int,
int, void**) [inlined] QtPrivate::QSlotObjectBase::call(this=,
r=, a=) + 2054 at qobject_impl.h:124
frame #11: 0x000109ac849b
QtCore`QMetaObject::activate(sender=0x7f91a3f23530,
signalOffset=, local_signal_index=,
argv=) + 2027 at qobject.cpp:3715
frame #12: 0x0001099d611d
QtCore`QProcessPrivate::tryReadFromChannel(QProcessPrivate::Channel*) [inlined]
QProcess::readyReadStandardError(QProcess::QPrivateSignal) + 8 at
moc_qprocess.cpp:365
frame #13: 0x0001099d6115
QtCore`QProcessPrivate::tryReadFromChannel(this=,
channel=) + 693 at qprocess.cpp:1029
frame #14: 0x0001099d96b7 QtCore`QProcess::qt_static_metacall(QObject*,
QMetaObject::Call, int, void**) [inlined]
QProcessPrivate::_q_canReadStandardOutput(this=) + 663 at
qprocess.cpp:1038
frame #15: 0x0001099d96ab
QtCore`QProcess::qt_static_metacall(_o=, _c=,
_id=, _a=0x7fff58dbaef0) + 651 at moc_qprocess.cpp:205
frame #16: 0x000109ac8884
QtCore`QMetaObject::activate(sender=0x7f919844bea0,
signalOffset=, local_signal_index=,
argv=) + 3028 at qobject.cpp:3730
frame #17: 0x000109b6221c
QtCore`QSocketNotifier::activated(this=, _t1=152,
(null)=) + 60 at moc_qsocketnotifier.cpp:135
frame #18: 0x000109acfc59
QtCore`QSocketNotifier::event(this=0x7f919844bea0, e=) + 425
at qsocketnotifier.cpp:260
frame #19: 0x0001089341e6
QtWidgets`QApplicationPrivate::notify_helper(this=,
receiver=0x7f919844bea0, e=0x7fff58dbb488) + 294 at
qapplication.cpp:3804
frame #20: 0x000108937726
QtWidgets`QApplication::notify(this=, receiver=,
e=) + 8470 at qapplication.cpp:3767
frame #21: 0x000109a94567
QtCore`QCoreApplication::notifyInternal2(receiver=0x7f919844bea0,
event=0x7fff58dbb488) + 167 at qcoreapplication.cpp:1020
frame #22: 0x000109ae8c36 QtCore`qt_mac_socket_callback(__CFSocket*,
unsigned long, __CFData const*, void const*, void*) [inlined]
QCoreApplication::sendEvent(receiver=, event=0x000109cff130) +
214 at qcoreapplication.h:225
frame #23: 0x000109ae8c29
QtCore`qt_mac_socket_callback(s=, callbackType=,
(null)=, (null)=, info=0x7f919858f140) + 201 at
qcfsocketnotifier.cpp:61
frame #24: 0x7fff8bbd0057 CoreFoundation`__CFSocketPerformV0 + 855
frame #25: 0x7fff8bb905b1
CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
frame #26: 0x7fff8bb81c62 CoreFoundation`__CFRunLoopDoSources0 + 242
frame #27: 0x7fff8bb813ef CoreFoundation`__CFRunLoopRun + 831
frame #28: 0x7fff8bb80e75 CoreFoundation`CFRunLoopRunSpecific + 309
frame #29: 0x7fff8c2cca0d HIToolbox`RunCurrentEventLoopInMode + 226
frame #30: 0x7fff8c2cc7b7 HIToolbox`ReceiveNextEventCommon + 479
frame #31: 0x7fff8c2cc5bc

[kde] [Bug 368603] New: crash when starting an lldb debug session

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368603

Bug ID: 368603
   Summary: crash when starting an lldb debug session
   Product: kde
   Version: unspecified
  Platform: unspecified
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: rjvber...@gmail.com

Application: kdevelop5 (5.0.0)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Linux 4.5.7-ck1-mainline-core2-rjvb x86_64
Distribution: Ubuntu 14.04.5 LTS

-- Information about the crash:
- What I was doing when the application crashed:

This crash happens when trying to start a debugging session with the lldb
plugin, with KDevelop git/master v4.90.91-551-g4a90319 . It happens on OS X as
well.

The crash can be reproduced every time.

-- Backtrace:
Application: KDevelop (kdevelop5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f83c23b9780 (LWP 24817))]

Thread 17 (Thread 0x7f83a24ff700 (LWP 24818)):
#0  0x7f83bf11efdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f83b2248b72 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f83b224a64f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f83a4f4fb09 in QXcbEventReader::run (this=0x1cc8c30) at
/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/plugins/platforms/xcb/qxcbconnection.cpp:1325
#4  0x7f83bf7cdc99 in QThreadPrivate::start (arg=0x1cc8c30) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread_unix.cpp:341
#5  0x7f83b8eda184 in start_thread (arg=0x7f83a24ff700) at
pthread_create.c:312
#6  0x7f83bf12c37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 16 (Thread 0x7f83a1006700 (LWP 24819)):
#0  0x7f83bf9e7806 in QTimerInfoList::repairTimersIfNeeded
(this=0x7f8394002f20) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qtimerinfo_unix.cpp:160
#1  0x7f83bf9e7863 in QTimerInfoList::timerWait (this=0x7f8394002f20,
tm=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qtimerinfo_unix.cpp:382
#2  0x7f83bf9e8b86 in timerSourcePrepareHelper (timeout=0x7f83a1005c74,
src=) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:126
#3  timerSourcePrepare (source=,
timeout=timeout@entry=0x7f83a1005c74) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:159
#4  0x7f83b805468d in g_main_context_prepare
(context=context@entry=0x7f8394000990, priority=priority@entry=0x7f83a1005cf8)
at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3352
#5  0x7f83b8054f03 in g_main_context_iterate
(context=context@entry=0x7f8394000990, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3714
#6  0x7f83b80550ec in g_main_context_iteration (context=0x7f8394000990,
may_block=may_block@entry=1) at
/build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795
#7  0x7f83bf9e962b in QEventDispatcherGlib::processEvents
(this=0x7f83940008c0, flags=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:419
#8  0x7f83bf99356a in QEventLoop::exec (this=this@entry=0x7f83a1005e20,
flags=..., flags@entry=...) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/kernel/qeventloop.cpp:204
#9  0x7f83bf7c8f8b in QThread::exec (this=this@entry=0x7f83c17cb400
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/corelib/thread/qthread.cpp:500
#10 0x7f83c155a605 in QDBusConnectionManager::run (this=0x7f83c17cb400
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.6.1/qtbase/src/dbus/qdbusconnection.cpp:189
#11 0x7f83bf7cdc99 in QThreadPrivate::start (arg=0x7f83c17cb400 <(anonymous

[kdevplatform] [Bug 363494] closing a Patch Review via (git) commit opens the documentation view

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363494

--- Comment #8 from RJVB  ---
(posted too fast)

Wouldn't that give a hint at what's going here, i.e. "simply" a lack of
persistence of the documentation view's settings?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevplatform] [Bug 363494] closing a Patch Review via (git) commit opens the documentation view

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363494

--- Comment #7 from RJVB  ---
Well, I thought I could simply work around this issue by removing the
Documentation button from my toolbars. While that's true I have to repeat the
action each time I restart KDevelop because that damn. button keeps coming
back...

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 360488] dolphin with >=kde-frameworks-5.20 crashes when copy+paste file in same directory

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360488

--- Comment #15 from RJVB  ---
That's an old KDE4 version!

I can confirm that Dolphin 16.08.0 (with FWs 5.24.0) doesn't crash when doing a
copy/paste of a file without changing directories. It pops up a warning that
offers to give the copy a new name.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 368568] New: Crash when quitting KDevelop with a patch review open

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368568

Bug ID: 368568
   Summary: Crash when quitting KDevelop with a patch review open
   Product: kdevelop
   Version: 5.0.0
  Platform: Compiled Sources
OS: OS X
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: rjvber...@gmail.com

Application: kdevelop (5.0.0)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.24.0
Operating System: Darwin 13.4.0 x86_64
Distribution (Platform): MacPorts Packages

-- Information about the crash:
- What I was doing when the application crashed:

I just uploaded a new patch to ReviewBoard using the patchreview plugin's
export feature. I then quit KDevelop without closing the patch review first.
That omission causes a systematic crash on OS X.

The crash can be reproduced every time.

-- Backtrace:
Application: KDevelop (kdevelop), signal: Segmentation fault: 11
(lldb) (lldb) process attach --pid 66237
Process 66237 stopped
Executable module set to
"/Applications/MacPorts/KF5/kdevelop.app/Contents/MacOS/kdevelop.bin".
Architecture set to: x86_64-apple-macosx.
(lldb) set set term-width 200
(lldb) thread info
thread #1: tid = 0xb74213, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 +
8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP

(lldb) bt all
* thread #1: tid = 0xb74213, 0x7fff8451ce20 libsystem_kernel.dylib`__wait4
+ 8, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x7fff8451ce20 libsystem_kernel.dylib`__wait4 + 8
frame #1: 0x0001064d1fe2 libKF5Crash.5.dylib`KCrash::startProcess(int,
char const**, bool) + 135
frame #2: 0x0001064d1e06
libKF5Crash.5.dylib`KCrash::defaultCrashHandler(int) + 1049
frame #3: 0x7fff81b8c5aa libsystem_platform.dylib`_sigtramp + 26
frame #4: 0x0001067406ec
QtQml`QQmlApplicationEngine::~QQmlApplicationEngine() [inlined] void
qDeleteAll::const_iterator>(QList::const_iterator,
QList::const_iterator) + 19 at qalgorithms.h:317
frame #5: 0x0001067406d9
QtQml`QQmlApplicationEngine::~QQmlApplicationEngine() [inlined] void
qDeleteAll >(QList const&) + 29 at qalgorithms.h:325
frame #6: 0x0001067406bc
QtQml`QQmlApplicationEngine::~QQmlApplicationEngine() [inlined]
QQmlApplicationEnginePrivate::cleanUp() at qqmlapplicationengine.cpp:54
frame #7: 0x0001067406bc
QtQml`QQmlApplicationEngine::~QQmlApplicationEngine() [inlined]
QQmlApplicationEngine::~QQmlApplicationEngine(this=0x7f9713816a90) + 14 at
qqmlapplicationengine.cpp:236
frame #8: 0x0001067406ae
QtQml`QQmlApplicationEngine::~QQmlApplicationEngine() [inlined]
QQmlApplicationEngine::~QQmlApplicationEngine(this=0x7f9713816a90) at
qqmlapplicationengine.cpp:234
frame #9: 0x0001067406ae
QtQml`QQmlApplicationEngine::~QQmlApplicationEngine(this=0x7f9713816a90) +
14 at qqmlapplicationengine.cpp:234
frame #10: 0x000108e9fe48 QtCore`QObject::event(QEvent*) [inlined]
qDeleteInEventHandler(o=0x7f9713816a90) + 14 at qobject.cpp:4472
frame #11: 0x000108e9fe3a
QtCore`QObject::event(this=0x7f9713816a90, e=) + 746 at
qobject.cpp:1247
frame #12: 0x000107d1a1e6
QtWidgets`QApplicationPrivate::notify_helper(this=,
receiver=0x7f9713816a90, e=0x7f972f883e20) + 294 at
qapplication.cpp:3804
frame #13: 0x000107d1d726
QtWidgets`QApplication::notify(this=, receiver=,
e=) + 8470 at qapplication.cpp:3767
frame #14: 0x000108e73567
QtCore`QCoreApplication::notifyInternal2(receiver=0x7f9713816a90,
event=0x7f972f883e20) + 167 at qcoreapplication.cpp:1020
frame #15: 0x000108e74166
QtCore`QCoreApplicationPrivate::sendPostedEvents(receiver=0x,
event_type=0, data=0x7f9720c13b60) + 566 at qcoreapplication.h:225
frame #16: 0x000108e73c4c QtCore`QCoreApplication::exec() + 412 at
qcoreapplication.cpp:1296
frame #17: 0x000106264526 kdevelop.bin`main(argc=,
argv=0x7f97236d3d70) + 55766 at main.cpp:876
frame #18: 0x7fff84caa5fd libdyld.dylib`start + 1

  thread #2: tid = 0xb74214, 0x7fff8451ce22 libsystem_kernel.dylib`__wait4
+ 10, queue = 'com.apple.libdispatch-manager'
frame #0: 0x7fff8451ce22 libsystem_kernel.dylib`__wait4 + 10
frame #1: 0x0001064d1fe2 libKF5Crash.5.dylib`KCrash::startProcess(int,
char const**, bool) + 135
frame #2: 0x0001064d1e06
libKF5Crash.5.dylib`KCrash::defaultCrashHandler(int) + 1049
frame #3: 0x7fff81b8c5aa libsystem_platform.dylib`_sigtramp + 26
frame #4: 0x7fff8451d663 libsystem_kernel.dylib`kevent64 + 11
frame #5: 0x7fff810f9136 libdispatch.dylib`_dispatch_mgr_thread + 52

  thread #3: tid = 0xb74230, 0x7fff8451c9aa libsystem_kernel.dylib`__select
+ 10, name = 

[kdevelop] [Bug 363473] KDevelop should use a different tab bar widget for tabbed documents

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363473

--- Comment #20 from RJVB  ---
I've elaborated the patch a bit and submitted it for review:
https://git.reviewboard.kde.org/r/128880/

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 363473] KDevelop should use a different tab bar widget for tabbed documents

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363473

--- Comment #19 from RJVB  ---
Created attachment 101017
  --> https://bugs.kde.org/attachment.cgi?id=101017=edit
many tabs, QtCurve with a Fusion QTabBar

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 363473] KDevelop should use a different tab bar widget for tabbed documents

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363473

--- Comment #18 from RJVB  ---
Created attachment 101016
  --> https://bugs.kde.org/attachment.cgi?id=101016=edit
Many tabs, Breeze with a Fusion QTabBar

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 363473] KDevelop should use a different tab bar widget for tabbed documents

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363473

--- Comment #17 from RJVB  ---
Created attachment 101015
  --> https://bugs.kde.org/attachment.cgi?id=101015=edit
Many tabs with the native Macintosh theme but the Fusion style for the QTabBar
widget

I think this may yet be the best solution: just setting the QTabBar style to
Fusion for tabbed Sublime documents.

See also the screenshots combining this approach with Breeze and QtCurve.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 363473] KDevelop should use a different tab bar widget for tabbed documents

[RJVB via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363473

--- Comment #16 from RJVB  ---
(In reply to RJVB from comment #12)
> It wouldn't be possible to force a specific widget style on one particular
> widget class, perchance? Something like "QTabBar { style : Fusion }" ?

In fact it is:

```
diff --git a/sublime/container.cpp b/sublime/container.cpp
index b04f6c3..3deb21f 100644
--- a/sublime/container.cpp
+++ b/sublime/container.cpp
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -54,6 +55,7 @@ public:
 ContainerTabBar(Container* container)
 : QTabBar(container), m_container(container)
 {
+setStyle(QStyleFactory::create("fusion"));
 installEventFilter(this);
 }

```

-- 
You are receiving this mail because:
You are watching all bug changes.