[Kde-graphics-devel] Review Request 125433: kcm_kamera: Double calls to load() lead to strange scrollbars after saving a change

Christian Butcher chrisb2244 at gmail.com
Thu Oct 8 07:22:49 UTC 2015 


> On Sept. 28, 2015, 7:02 a.m., Marcus Meissner wrote:
> > according to git blame I added this to help autoload the camera list ... although I have not much recall of this :/
> 
> Christian Butcher wrote:
>     A run of 'gdb systemsettings5' with 'break KKameraConfig::load()' and corresponding calls to 'bt' informs me that with the load() call inside displayGPSuccessDialogue, first it is called by the displayGPSuccessDialogue:
>     ``` 
>     #0  KKameraConfig::load (this=0x9d3310) at /home/christian/kde-git/Extras/kamera/kcontrol/kamera.cpp:203
>     #1  0x00007fffd3e08bec in KKameraConfig::displayGPSuccessDialogue (this=0x9d3310)
>         at /home/christian/kde-git/Extras/kamera/kcontrol/kamera.cpp:171
>     #2  0x00007fffd3e07c04 in KKameraConfig::KKameraConfig (this=0x9d3310, parent=0x9c3240)
>         at /home/christian/kde-git/Extras/kamera/kcontrol/kamera.cpp:67
>     #3  0x00007fffd3e0c89e in KPluginFactory::createInstance<KKameraConfig, QWidget> (parentWidget=0x0, parent=0x9c3240, args=...)
>         at /opt/kde/include/KF5/KCoreAddons/kpluginfactory.h:477
>     #4  0x00007ffff34df827 in KPluginFactory::create(char const*, QWidget*, QObject*, QList<QVariant> const&, QString const&) ()
>        from /opt/kde/lib64/libKF5CoreAddons.so.5
>     #5  0x00007ffff798ed10 in KCModuleLoader::loadModule(KCModuleInfo const&, KCModuleLoader::ErrorReporting, QWidget*, QStringList const&) () from /opt/kde/lib64/libKF5KCMUtils.so.5
>     #6  0x00007ffff799785c in KCModuleProxyPrivate::loadModule() () from /opt/kde/lib64/libKF5KCMUtils.so.5
>     ...
>     #67 0x00.... in main ()
>     ```
>     
>     and then again by KCModule::qt_static_metacall:
>     ```
>     #0  KKameraConfig::load (this=0x9d3310) at /home/christian/kde-git/Extras/kamera/kcontrol/kamera.cpp:203
>     #1  0x00007ffff6a4e9d9 in KCModule::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
>        from /opt/kde/lib64/libKF5ConfigWidgets.so.5
>     #2  0x00007ffff3075832 in QObject::event(QEvent*) () from /opt/qt5/lib64/libQt5Core.so.5
>     #3  0x00007ffff4be74c7 in QWidget::event(QEvent*) () from /opt/qt5/lib64/libQt5Widgets.so.5
>     #4  0x00007ffff4ba699c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /opt/qt5/lib64/libQt5Widgets.so.5
>     #5  0x00007ffff4babb40 in QApplication::notify(QObject*, QEvent*) () from /opt/qt5/lib64/libQt5Widgets.so.5
>     #6  0x00007ffff3046ae3 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /opt/qt5/lib64/libQt5Core.so.5
>     #7  0x00007ffff3048d53 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
>        from /opt/qt5/lib64/libQt5Core.so.5
>     #8  0x00007ffff309bac3 in ?? () from /opt/qt5/lib64/libQt5Core.so.5
>     #9  0x00007fffed7b778d in g_main_dispatch (context=0x7fffdc0016f0) at ../../glib/gmain.c:3122
>     #10 g_main_context_dispatch (context=context at entry=0x7fffdc0016f0) at ../../glib/gmain.c:3737
>     #11 0x00007fffed7b7a38 in g_main_context_iterate (context=context at entry=0x7fffdc0016f0, block=block at entry=1, 
>         dispatch=dispatch at entry=1, self=<optimized out>) at ../../glib/gmain.c:3808
>     #12 0x00007fffed7b7adc in g_main_context_iteration (context=0x7fffdc0016f0, may_block=1) at ../../glib/gmain.c:3869
>     #13 0x00007ffff309beb7 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
>        from /opt/qt5/lib64/libQt5Core.so.5
>     #14 0x00007ffff3044682 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /opt/qt5/lib64/libQt5Core.so.5
>     #15 0x00007ffff304c18d in QCoreApplication::exec() () from /opt/qt5/lib64/libQt5Core.so.5
>     #16 0x000000000040f108 in main ()
>     ```
>     
>     I would guess that the second call occurs immediately after (but I didn't step through, so I could be horribly wrong). 
>     
>     load() does indeed call populateDeviceListView(), then gp_list_free(list). gp_list_new(&list) is called in the same function, so I don't think there's any risk of double free, but something strange happens.
>     
>     If I watch carefully, sometimes the correct kcm loads and is then replaced by the scrollbars between debug statements to 'kamera.kcontrol' in ~/.xsession-errors (these debug statements aren't in the git repository since they're fairly useless for general use I imagine). I'm sure the reliability of 'tail -f' for judging timing is pretty non-existent but I find it qualitatively convincing.
> 
> Marcus Meissner wrote:
>     I tried to comment it out, it does not seem to change behaviour so it seems good.
>     
>     (the config dialog is broken though... :( )

Should I commit? (I added you as a reviewer also.)

How do you mean broken? If you mean it remains empty, then obviously I shouldn't commit, and should work out why it fixes for me, but not you.
If something else, perhaps I can look at that next?


- Christian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125433/#review86025
-----------------------------------------------------------


On Oct. 8, 2015, 7:22 a.m., Christian Butcher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125433/
> -----------------------------------------------------------
> 
> (Updated Oct. 8, 2015, 7:22 a.m.)
> 
> 
> Review request for KDE Graphics, Plasma and Marcus Meissner.
> 
> 
> Repository: kamera
> 
> 
> Description
> -------
> 
> The displayGPSuccessDialogue(void) function calls load() as its last statement currently.
> 
> Documentation for the KCModule api (both [kde4](http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKCModule.html) and [frameworks](http://api.kde.org/frameworks-api/frameworks5-apidocs/kconfigwidgets/html/classKCModule.html)) informs the reader that load() is called at the end of construction - consequently it seems that the additional load() call leads to the function (which is implemented as KKameraConfig::load() ) being called twice.
> 
> [Bug 236844](https://bugs.kde.org/show_bug.cgi?id=236844) may be related but at least on my KF5 based system, this does not cause or prevent a crash, which is referenced in the bug.
> 
> Separately, COPYING-CMAKE-SCRIPTS is referenced by the FindGphoto2.cmake file, and seems to have missed the commit in [RR-125230](https://git.reviewboard.kde.org/r/125230/). If this was intentional, then my apologies for readding here, but if so, the FindGphoto2.cmake file will need changing in some way.
> 
> 
> Diffs
> -----
> 
>   COPYING-CMAKE-SCRIPTS PRE-CREATION 
>   kcontrol/kamera.cpp 2d8f61449a5a6f2650d864c864652ebea780a422 
>   kcontrol/kameradevice.h b0ecb974f8fcb765228afe1965aeebab8e7656ed 
> 
> Diff: https://git.reviewboard.kde.org/r/125433/diff/
> 
> 
> Testing
> -------
> 
> When the call is present, opening the Kamera KCM within systemsettings after saving changes and going back to the main systemsettings view leads to a strange set of scrollbars.
> 
> With the additional call removed, the KCM-Kamera opens properly on the second attempt, after saving changes.
> 
> As a camera to test, the first (in the scroll list) serial port camera is 'Achiever Digital Adc65'. 'Barbie' may be easier to find as the first entry for 'B', and is also more memorable... I used a serial camera, since then the kcm will load images even without a camera connected
> 
> 
> File Attachments
> ----------------
> 
> scrollbars
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/09/28/74e8bd93-4c4a-4103-9fb1-7bd106258058__kcm1.png
> 
> 
> Thanks,
> 
> Christian Butcher
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20151008/f9879cc6/attachment.html>

More information about the Kde-graphics-devel mailing list