Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Initial implementation of RAW image loading plug-in based on PhotoFlow #1

Closed
wants to merge 1 commit into from
Closed

Initial implementation of RAW image loading plug-in based on PhotoFlow #1

wants to merge 1 commit into from

Conversation

aferrero2707
Copy link

This is a draft implementation, still in very preliminary stage... if the pull request is accepted, I would suggest to put this code in a new feature branch and not in the master branch.

@hallarempt
Copy link
Contributor

Aw... github is just a mirror, so I don't really see pull requests made here, we use phabricator.kde.org for code review.

@aferrero2707
Copy link
Author

So, what is the right way to proceed in order to propose experimental features for testing?

Thanks!

@hallarempt
Copy link
Contributor

The best way is to post a patch on http://phabricator.kde.org/

@aferrero2707
Copy link
Author

How can I do that? I have tried to register myself on phabricator.kde.org, but the only thing I am presented is this login screen:

screen shot 2017-03-29 at 21 25 52

I have no idea how to proceed from there in order to register into the system... If I insert some username and password, I simply get a message saying that they are invalid.

Thanks!

@hallarempt
Copy link
Contributor

hallarempt commented Apr 4, 2017 via email

@tsdgeos
Copy link
Contributor

tsdgeos commented Apr 27, 2017

Thanks for your contribution :)

This repository is a mirror a KDE repository. For this reason we can't accept contributions through Github. Please see https://community.kde.org/Infrastructure/Github_Mirror for details on how to contribute to this and other KDE projects.

@tsdgeos tsdgeos closed this Apr 27, 2017
kdesysadmin pushed a commit that referenced this pull request Jul 10, 2019
@hallarempt
Try to make this test succeed on Jenkins
32f46f7 
Apparently, on Jenkins we cannot create all of these colorspaces,
so don't fail by dereferencing a null pointer:

********* Start testing of TestLcmsRGBP2020PQColorSpace *********
Config: Using QtTest library 5.12.4, Qt 5.12.4 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 9.1.1 20190611 [gcc-9-branch revision 272147])
PASS   : TestLcmsRGBP2020PQColorSpace::initTestCase()
AddressSanitizer:DEADLYSIGNAL
=================================================================
==6181==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f3f02031167 bp 0x7fff6f5c1290 sp 0x7fff6f5c1280 T0)
==6181==The signal is caused by a READ memory access.
==6181==Hint: address points to the zero page.
    #0 0x7f3f02031166 in KoColorSpace::id() const /home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/libs/pigment/KoColorSpace.cpp:106
    #1 0x41535a in testRoundTrip(KoColorSpace const*, KoColorSpace const*, SourceType) /home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/plugins/color/lcms2engine/tests/TestLcmsRGBP2020PQColorSpace.cpp:44
    #2 0x418726 in testRoundTrip(KoID const&, KoID const&, SourceType) /home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/plugins/color/lcms2engine/tests/TestLcmsRGBP2020PQColorSpace.cpp:118
    #3 0x4192b2 in TestLcmsRGBP2020PQColorSpace::test() /home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/plugins/color/lcms2engine/tests/TestLcmsRGBP2020PQColorSpace.cpp:143
    #4 0x40aa2c in TestLcmsRGBP2020PQColorSpace::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) /home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/build/plugins/color/lcms2engine/tests/TestLcmsRGBP2020PQColorSpace_autogen/EWIEGA46WW/moc_TestLcmsRGBP2020PQColorSpace.cpp:78
    #5 0x7f3efcc6889a in QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const (/usr/lib64/libQt5Core.so.5+0x29689a)
    #6 0x7f3f050a0962  (/usr/lib64/libQt5Test.so.5+0x19962)
    #7 0x7f3f050a1352  (/usr/lib64/libQt5Test.so.5+0x1a352)
    #8 0x7f3f050a1910  (/usr/lib64/libQt5Test.so.5+0x1a910)
    #9 0x7f3f050a1cda in QTest::qRun() (/usr/lib64/libQt5Test.so.5+0x1acda)
    #10 0x7f3f050a1edb in QTest::qExec(QObject*, int, char**) (/usr/lib64/libQt5Test.so.5+0x1aedb)
    #11 0x41b9d7 in main /home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/plugins/color/lcms2engine/tests/TestLcmsRGBP2020PQColorSpace.cpp:185
    #12 0x7f3efc4f2bca in __libc_start_main (/lib64/libc.so.6+0x26bca)
    #13 0x40a8f9 in _start (/home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/build/plugins/color/lcms2engine/tests/TestLcmsRGBP2020PQColorSpace+0x40a8f9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/jenkins/workspace/Extragear/krita/kf5-qt5 SUSEQt5.12/libs/pigment/KoColorSpace.cpp:106 in KoColorSpace::id() const
==6181==ABORTING
kdesysadmin pushed a commit that referenced this pull request Aug 11, 2020
@dimula73
Possibly fix a crash in KisCloneLayerTest reported by our CI
a7cf99a 
The backtrace looks as if an update is executed while the node has been
removed from the layer stack. I couldn't reproduce the crash myself,
my the backtrace is rather convincing.

QDEBUG : KisCloneLayerTest::testUndoingRemovingSource() krita.core: Add node  KisPaintLayer(0x60800007b320, name = "paint1")  to  QObject(0x0)
QDEBUG : KisCloneLayerTest::testUndoingRemovingSource() krita.core: Add node  KisCloneLayer(0x606000223580, name = "clone_of_p1")  to  QObject(0x0)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2392==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f00c3e5b6d1 bp 0x7f00a8e833c0 sp 0x7f00a8e833b0 T19)
==2392==The signal is caused by a READ memory access.
==2392==Hint: address points to the zero page.
    #0 0x7f00c3e5b6d1 in QScopedPointer<KisProjectionLeaf::Private, QScopedPointerDeleter<KisProjectionLeaf::Private> >::operator->() const /usr/include/qt5/QtCore/qscopedpointer.h:118
    #1 0x7f00c3e525e1 in KisProjectionLeaf::original() /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_projection_leaf.cpp:252
    #2 0x7f00c3c21eef in KisAsyncMerger::setupProjection(QSharedPointer<KisProjectionLeaf>, QRect const&, bool) (/home/jenkins/install-prefix/lib64/libkritaimage.so.19+0x1d14eef)
    #3 0x7f00c3c0d860 in KisAsyncMerger::startMerge(KisBaseRectsWalker&, bool) /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_async_merger.cpp:261
    #4 0x7f00c360bc29 in KisUpdateJobItem::runMergeJob() /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_update_job_item.h:135
    #5 0x7f00c360b576 in KisUpdateJobItem::run() /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_update_job_item.h:86
    #6 0x7f00b6659371  (/usr/lib64/libQt5Core.so.5+0xda371)
    #7 0x7f00b66556e0  (/usr/lib64/libQt5Core.so.5+0xd66e0)
    #8 0x7f00b6050ea9 in start_thread (/lib64/libpthread.so.0+0x8ea9)
    #9 0x7f00b617aafe in __clone (/lib64/libc.so.6+0xffafe)
kdesysadmin pushed a commit that referenced this pull request Aug 12, 2020
@dimula73
Possibly fix a crash in KisCloneLayerTest reported by our CI
c6771eb 
The backtrace looks as if an update is executed while the node has been
removed from the layer stack. I couldn't reproduce the crash myself,
my the backtrace is rather convincing.

QDEBUG : KisCloneLayerTest::testUndoingRemovingSource() krita.core: Add node  KisPaintLayer(0x60800007b320, name = "paint1")  to  QObject(0x0)
QDEBUG : KisCloneLayerTest::testUndoingRemovingSource() krita.core: Add node  KisCloneLayer(0x606000223580, name = "clone_of_p1")  to  QObject(0x0)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2392==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f00c3e5b6d1 bp 0x7f00a8e833c0 sp 0x7f00a8e833b0 T19)
==2392==The signal is caused by a READ memory access.
==2392==Hint: address points to the zero page.
    #0 0x7f00c3e5b6d1 in QScopedPointer<KisProjectionLeaf::Private, QScopedPointerDeleter<KisProjectionLeaf::Private> >::operator->() const /usr/include/qt5/QtCore/qscopedpointer.h:118
    #1 0x7f00c3e525e1 in KisProjectionLeaf::original() /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_projection_leaf.cpp:252
    #2 0x7f00c3c21eef in KisAsyncMerger::setupProjection(QSharedPointer<KisProjectionLeaf>, QRect const&, bool) (/home/jenkins/install-prefix/lib64/libkritaimage.so.19+0x1d14eef)
    #3 0x7f00c3c0d860 in KisAsyncMerger::startMerge(KisBaseRectsWalker&, bool) /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_async_merger.cpp:261
    #4 0x7f00c360bc29 in KisUpdateJobItem::runMergeJob() /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_update_job_item.h:135
    #5 0x7f00c360b576 in KisUpdateJobItem::run() /home/jenkins/workspace/Extragear/krita/stable-kf5-qt5 SUSEQt5.14/libs/image/kis_update_job_item.h:86
    #6 0x7f00b6659371  (/usr/lib64/libQt5Core.so.5+0xda371)
    #7 0x7f00b66556e0  (/usr/lib64/libQt5Core.so.5+0xd66e0)
    #8 0x7f00b6050ea9 in start_thread (/lib64/libpthread.so.0+0x8ea9)
    #9 0x7f00b617aafe in __clone (/lib64/libc.so.6+0xffafe)
kdesysadmin pushed a commit that referenced this pull request May 5, 2021
@sh-zam
Crashfix: when an SVG document is closed with an object selected
87c46be 
When slotRecoverColorInResourceManager is hit it calls setResource which
in turn updates the shape which by that point is deleted, triggering an
assert.

* thread #1, name = 'krita', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff0d5aef5 libc.so.6`raise + 325
    frame #1: 0x00007ffff0d44862 libc.so.6`abort + 278
    frame #2: 0x00007ffff12b99ac libQt5Core.so.5`QMessageLogger::fatal(char const*, ...) const + 206
    frame #3: 0x00007ffff12b8db6 libQt5Core.so.5`qt_assert_x(char const*, char const*, char const*, int) + 93
    frame #4: 0x00007ffff745f115 libkritaui.so.17`KisWeakSharedPtr<KisImage>::operator->(this=0x00007fffffffc1e8) at kis_shared_ptr.h:382:13
    frame #5: 0x00007ffff75bffb6 libkritaui.so.17`KisShapeLayerCanvas::slotStartAsyncRepaint(this=0x000055555cc22670) at kis_shape_layer_canvas.cpp:250:47
...
kdesysadmin pushed a commit that referenced this pull request Nov 26, 2021
@sh-zam
Recorder Docker: Prevent infinite back and forth..
95ae2b5 
.. of onRecordButtonToggled, when the color space is unsupported.

The reason for the infinite loop is:

1. setCanvas starts the RecorderWriter thread (say turn #1)

2. after that in the same method we try to stop the writer thread (#1)

3. the started thread (#1) calls the updateRecordStatus and retriggers
the thread start (#2)

4. when the #1 thread is stopped it triggers updateRecordStatus and this
further triggers the stopping of thread #2 and we arrive back at step 2.
kdesysadmin pushed a commit that referenced this pull request Nov 29, 2021
@sh-zam
Recorder Docker: Prevent infinite back and forth..
96bd2d3 
.. of onRecordButtonToggled, when the color space is unsupported.

The reason for the infinite loop is:

1. setCanvas starts the RecorderWriter thread (say turn #1)

2. after that in the same method we try to stop the writer thread (#1)

3. the started thread (#1) calls the updateRecordStatus and retriggers
the thread start (#2)

4. when the #1 thread is stopped it triggers updateRecordStatus and this
further triggers the stopping of thread #2 and we arrive back at step 2.

(cherry picked from commit 95ae2b5)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@aferrero2707 @hallarempt @tsdgeos