Re: KPluginLoader UBSAN warnings (object has invalid vptr)
On Thursday, 15 October 2020 07:22:59 PDT Milian Wolff wrote: > I have the feeling that this might be a limitation of UBSAN? Or is this an > actual problem - does anyone know? I've seen similar warnings that were impossible. See https://bugreports.qt.io/browse/QTBUG-85398 I'm not sure yet if this is an UBSan bug or if there was some weird, duplicate symbol problem. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: CI Breakage in Solid on FreeBSD
On Fri, Oct 16, 2020 at 8:39 PM Ahmad Samir wrote: > On 2020-10-15 13:32, Adriaan de Groot wrote: > > On Thursday, 15 October 2020 11:22:02 CEST Ben Cooksley wrote: > >> Yesterday changes were landed to Solid, allowing it to make use of new > >> libimobiledevice API. Unfortunately these changes failed to handle the > >> situation where an older version of libimobiledevice is in use, causing > a > >> build failure on FreeBSD. > > > > We -- Ahmed, Kai Uwe, me -- are on it. It won't be an instant-fix because > > IDEVICE_DEVICE_PAIRED isn't a #define, it's an enum value, but we'll get > to > > it. > > > > [ade] > > > > Should hopefully be fixed by Kai Uwe's MR > https://invent.kde.org/frameworks/solid/-/merge_requests/17 > > merged and now we wait to see what the CI will say :) > Thanks all for sorting this out. I've now initiated a replacement Dependency Build, after which all the Plasma jobs that have broken should be functional again. > > -- > Ahmad Samir > Cheers, Ben
Re: stale MR triaging - you can help!
On 16.10.20 10:00, Albert Astals Cid wrote: > El dimarts, 13 d’octubre de 2020, a les 15:53:10 CEST, Harald Sitter va > escriure: >> Moin >> >> As promised in a previous mail I've set up a system that helps us find >> stale MRs to ensure patches don't fall by the wayside. >> >> Lists are filed as issues on invent. To help out you can hit the bell to >> subscribe to `New issue` events at >> https://invent.kde.org/sysadmin/gitlab-triaging >> >> First list of stale MRs here: >> https://invent.kde.org/sysadmin/gitlab-triaging/-/issues >> >> To deal with a stale MR you'll want to check the box and either make >> sure someone takes a look at the MR (e.g. by @mentioning someone who may >> have experience) or doing the review yourself. >> >> Unlike previously described I've refined the behavior a bit: >> >> a) MRs are not linked but listed with verbatim url, it sucks a bit but >> it prevents MRs from updating due to the back-reference an actual >> mention would cause >> b) stale MRs are now MRs that have not seen activity within 4 weeks (up >> from 2 - was woefully too short a time frame) >> c) MRs without subscribers after 2+ weeks are recorded separately >> d) MRs without subscribers after 1+ week where the author is not a KDE >> dev are also recorded (currently a bit bugged as it turns out) >> >> The motivation with c and d is to prevent MRs from going stale to begin >> with, ideally anyway. > > Can we get the issues in each of those 4 categories in different sections of > the issue you create? > > It makes more sense for me to look at d) than at some MR whose author is > Aleix (for example), if it's stale, he knows how to do how to un-stale it, > while a newbie may not know how to. Indeed. That's actually how it works, we've already dealt with the important ones this week though. So all that's left is the mountain of otherwise randomly stale MRs ;) https://invent.kde.org/sysadmin/gitlab-triaging/-/issues?scope=all=%E2%9C%93=closed HS
Re: Git merge workflow: reverse it?
El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va escriure: > Hello everyone! > > At plasma, we are experimenting with new workflow regarding how bugfixes > are put on the stable branch [1]. > > # Previous workflow > > - Current workflow is that we commit to stable branch and then merge it > upwords until master branch > - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then > master > > # Current workflow > > - Proposed workflow is to instead commit all changes in master, and > cherry-pick related changes in the stable branch as needed > - We had been using this workflow for about 1 month now and I'd say it > is working nicely for us. > > # Why? > > We occasionally hit several issues with previous workflow, > > - Merge conflicts when merging changes upwords > - Changes which are valid only for stable branch needs to be reverted in > master branches. So you end-up with, stable-fix, revert of stable fix > and then different fix and overall weird history. > - Accidential merges from the master branch to stable branch which > needs to be force-resetted. > - It's worth noting that Qt also recently changed to merge to dev, > cherry-pick backwards. > - This also allows for workflows where we want to commit some bugfix in > the master branch for few days/weeks and if it works fine in general > testing then, cherry-pick it in stable branches. > > Proposal is to probably adapt this policy kde-wise if people feel that > advantages are worth it. Can we get some conclusion here? We need to notify people if we're changing our default behaviour. Cheers, Albert > > Thanks > > [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html > >
Re: stale MR triaging - you can help!
El dimarts, 13 d’octubre de 2020, a les 15:53:10 CEST, Harald Sitter va escriure: > Moin > > As promised in a previous mail I've set up a system that helps us find > stale MRs to ensure patches don't fall by the wayside. > > Lists are filed as issues on invent. To help out you can hit the bell to > subscribe to `New issue` events at > https://invent.kde.org/sysadmin/gitlab-triaging > > First list of stale MRs here: > https://invent.kde.org/sysadmin/gitlab-triaging/-/issues > > To deal with a stale MR you'll want to check the box and either make > sure someone takes a look at the MR (e.g. by @mentioning someone who may > have experience) or doing the review yourself. > > Unlike previously described I've refined the behavior a bit: > > a) MRs are not linked but listed with verbatim url, it sucks a bit but > it prevents MRs from updating due to the back-reference an actual > mention would cause > b) stale MRs are now MRs that have not seen activity within 4 weeks (up > from 2 - was woefully too short a time frame) > c) MRs without subscribers after 2+ weeks are recorded separately > d) MRs without subscribers after 1+ week where the author is not a KDE > dev are also recorded (currently a bit bugged as it turns out) > > The motivation with c and d is to prevent MRs from going stale to begin > with, ideally anyway. Can we get the issues in each of those 4 categories in different sections of the issue you create? It makes more sense for me to look at d) than at some MR whose author is Aleix (for example), if it's stale, he knows how to do how to un-stale it, while a newbie may not know how to. Cheers, Albert > > HS >
Re: KPluginLoader UBSAN warnings (object has invalid vptr)
El dijous, 15 d’octubre de 2020, a les 16:22:59 CEST, Milian Wolff va escriure: > Hey all, > > I'm finally taking a bit of time to look after KDevelop again. I would most > notably like to make it ASAN/UBSAN clean. One thing I'm stumbling over are > the > following reports: > > ``` > /usr/include/KF5/KCoreAddons/kpluginfactory.h:545:24: runtime error: member > call on address 0x603f2d40 which does not point to an object of type > 'KPluginFactory' > 0x603f2d40: note: object has invalid vptr > 33 00 80 0f e0 31 d4 c3 5d 7f 00 00 a0 41 04 00 80 60 00 00 70 2d 0f 00 > 30 > 60 00 00 00 00 00 00 > ^~~ > invalid vptr > #0 0x7f5dede47d8c in KDevelop::IPlugin* > KPluginFactory::create(QObject*, QList const&) / > usr/include/KF5/KCoreAddons/kpluginfactory.h:545 > #1 0x7f5dede47d8c in > KDevelop::PluginController::loadPluginInternal(QString const&) /home/milian/ > projects/kf5/src/extragear/kdevelop/kdevelop/kdevplatform/shell/ > plugincontroller.cpp:615 > ``` > > Or this one: > > ``` > /usr/include/qt/QtCore/qobject.h:524:12: runtime error: downcast of address > 0x6060002922e0 which does not point to an object of type 'IPlugin' > 0x6060002922e0: note: object has invalid vptr > 36 00 80 24 b0 2f d4 c3 5d 7f 00 00 a0 42 04 00 80 60 00 00 b0 30 d4 c3 > 5d > 7f 00 00 80 fe 06 00 > ^~~ > invalid vptr > #0 0x7f5dede47f20 in KDevelop::IPlugin* > qobject_cast(QObject*) /usr/include/qt/QtCore/qobject.h: > 524 > #1 0x7f5dede47f20 in KDevelop::IPlugin* > KPluginFactory::create(QObject*, QList const&) / > usr/include/KF5/KCoreAddons/kpluginfactory.h:547 > ``` > > I have the feeling that this might be a limitation of UBSAN? Or is this an > actual problem - does anyone know? > > Most notably, the kplugin* tests in kcoreaddons are UBSAN clean for me, which > is quite odd. I would expect them to raise similar warnings, but apparently > they don't. Or potentially it's simply that KDevelop plugins are way more > complex - we apparently are using multiple inheritance there for example: > > ``` > class IPlugin : public QObject, public KXMLGUIClient > class AStylePlugin : public KDevelop::IPlugin, public > KDevelop::ISourceFormatter > ``` > > Maybe that's the problem? Does anyone know? I don't get any of those warnings (on starting kdevelop). What's your compile flags? I used cmake -DCMAKE_BUILD_TYPE=Debug -DECM_ENABLE_SANITIZERS='address;undefined' with gcc 10.2 About that warning i've seen it once and it was because the object i was casting was still not totally created yet and thus wasn't of the target type at that point. Cheers, Albert
Re: CI Breakage in Solid on FreeBSD
On 2020-10-15 13:32, Adriaan de Groot wrote: On Thursday, 15 October 2020 11:22:02 CEST Ben Cooksley wrote: Yesterday changes were landed to Solid, allowing it to make use of new libimobiledevice API. Unfortunately these changes failed to handle the situation where an older version of libimobiledevice is in use, causing a build failure on FreeBSD. We -- Ahmed, Kai Uwe, me -- are on it. It won't be an instant-fix because IDEVICE_DEVICE_PAIRED isn't a #define, it's an enum value, but we'll get to it. [ade] Should hopefully be fixed by Kai Uwe's MR https://invent.kde.org/frameworks/solid/-/merge_requests/17 merged and now we wait to see what the CI will say :) -- Ahmad Samir
Re: KDiagram - Persistent FTBFS for stable branch on Windows
mandag den 12. oktober 2020 12.04.04 CEST skrev Milian Wolff: On Montag, 12. Oktober 2020 11:28:45 CEST Ben Cooksley wrote: On Mon, Oct 12, 2020 at 10:24 PM Milian Wolff wrote: ... Thanks, but that's looking worse then I expected. I guess backporting `35e86e964908ee906dde4f0678c16a838e4712dd` is worth a shot. @Dag: what do you say, should that be safe enough to do? No, it will not apply cleanly. I'll do it. -- Mvh Dag
