Bug 456348

Hi,

I'm also encountering the same bug on:

Krusader: 2.7.2
Operating System: Manjaro
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.18.6-1-MANJARO (64-bit)
Graphics Platform: X11

Best regards,
Andrej

Same problem. Krusader don't browse archives after last update. Only infinity rotating circle.

Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.2
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.13.0-51-generic (64-bit)
Graphics Platform: X11

Same problem here!

Krusader: 2.7.2
Operating System: Manjaro
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.10.129-1-MANJARO (64-bit)
Graphics Platform: X11

I have the same problem trying to open/view zip archives.

Operating System: Fedora Linux 36
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.3
Kernel Version: 5.18.11-200.fc36.x86_64 (64-bit)

Same issue here.

Krusader: 2.7.2
Operating System: Manjaro Linux
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.12-3-MANJARO (64-bit)
Graphics Platform: X11

*** This bug has been confirmed by popular vote. ***

I have same issue in Krusader, only ZIP archives are affected.

Krusader: 2.7.2
Operating System: Arch Linux
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.14-arch1-1
Graphics Platform: X11

I tried it (using the git version of Krusader, under Kubuntu 22.04) and no problem was seen. If you can follow the steps of
    https://commits.kde.org/krusader?path=INSTALL
then you can build the git version of Krusader, use its latest features, etc. 
If you have been able to do it, is your problem solved?

Indeed, if I compile the latest master (fc69c9fa), it works. If I compile 2.7.2 (released in 2019) from source, it freezes. However, it only broke a few weeks ago in several distributions. So I guess some library has changed in an incompatible way.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Thanks, Dániel for changing the status of this bug report (and, before that, writing some important information).

As it seems that it's not a bug of Krusader (because the problem doesn't happen using the latest code of Krusader), I'm going to mark this bug as "RESOLVED - NOT A BUG". Anyway, please feel free to write in this bug report if you think it's necessary.

If you have time, it would be a good idea to release a new version of Krusader soon, or figure out the cause of the problem and backport the fix, or perhaps backport the current krarc implementation to the stable Krusader, or instruct packagers about what library version to require.

I too have switched to the developer version (using the krusader-git package from the Arch AUR) and can confirm, that opening ZIP archives works in that version just fine.

(In reply to Toni Asensi Esteve from comment #8)
> I tried it (using the git version of Krusader, under Kubuntu 22.04) and no
> problem was seen. If you can follow the steps of
>     https://commits.kde.org/krusader?path=INSTALL
> then you can build the git version of Krusader, use its latest features,
> etc. 
> If you have been able to do it, is your problem solved?

Hi, I have compiled 2.8.0 dev (kubuntu 22.04, kde 5.25.4, qt 5.15.3) and the problem is still there. :-(

*** This bug has been confirmed by popular vote. ***

(In reply to Jan from comment #14)
> (In reply to Toni Asensi Esteve from comment #8)
> > I tried it (using the git version of Krusader, under Kubuntu 22.04) and no
> > problem was seen. If you can follow the steps of
> >     https://commits.kde.org/krusader?path=INSTALL
> > then you can build the git version of Krusader, use its latest features,
> > etc. 
> > If you have been able to do it, is your problem solved?
> 
> Hi, I have compiled 2.8.0 dev (kubuntu 22.04, kde 5.25.4, qt 5.15.3) and the
> problem is still there. :-(

The problem is there when installing into usr folder, when installing to another folder like opt/krusader, all is OK with 2.8.0-dev

FROM:
cmake ../krusader -DCMAKE_INSTALL_PREFIX=/usr/ -DCMAKE_C_FLAGS="-O2 -fPIC" -DCMAKE_CXX_FLAGS="-O2 -fPIC"
TO:
cmake ../krusader -DCMAKE_INSTALL_PREFIX=/opt/krusader -DCMAKE_C_FLAGS="-O2 -fPIC" -DCMAKE_CXX_FLAGS="-O2 -fPIC"

So, it is OK with version 2.8.0-dev

(In reply to Jan from comment #16)
> (In reply to Jan from comment #14)
> > (In reply to Toni Asensi Esteve from comment #8)
> > > I tried it (using the git version of Krusader, under Kubuntu 22.04) and no
> > > problem was seen. If you can follow the steps of
> > >     https://commits.kde.org/krusader?path=INSTALL
> > > then you can build the git version of Krusader, use its latest features,
> > > etc. 
> > > If you have been able to do it, is your problem solved?
> > 
> > Hi, I have compiled 2.8.0 dev (kubuntu 22.04, kde 5.25.4, qt 5.15.3) and the
> > problem is still there. :-(
> 
> The problem is there when installing into usr folder, when installing to
> another folder like opt/krusader, all is OK with 2.8.0-dev
> 
> FROM:
> cmake ../krusader -DCMAKE_INSTALL_PREFIX=/usr/ -DCMAKE_C_FLAGS="-O2 -fPIC"
> -DCMAKE_CXX_FLAGS="-O2 -fPIC"
> TO:
> cmake ../krusader -DCMAKE_INSTALL_PREFIX=/opt/krusader -DCMAKE_C_FLAGS="-O2
> -fPIC" -DCMAKE_CXX_FLAGS="-O2 -fPIC"
> 
> So, it is OK with version 2.8.0-dev

But when testing I encounter other problems, such as not being able to write to the existing zip, etc.

When opening a file which is inside ZIP in krusader, e.g. because of editing, then it is not possible to save modifications because of "Writing to zip is not supported". This does not happen in Dolphin (which uses Ark to display files inside ZIP), or any other file manager like Double Commander, etc.

Enable write support (krarc ioslave) is enabled in krusader, latest version installed 2.8.0-dev

(In reply to Toni Asensi Esteve from comment #11)
> Thanks, Dániel for changing the status of this bug report (and, before that,
> writing some important information).
> 
> As it seems that it's not a bug of Krusader (because the problem doesn't
> happen using the latest code of Krusader), I'm going to mark this bug as
> "RESOLVED - NOT A BUG". Anyway, please feel free to write in this bug report
> if you think it's necessary.

Hi,

IMHO this is a wrong resolution of this bug and unacceptable from a point of normal Krusader user. You can't expect from users without knowledge of compiling programs to build their own Krusader version and you also can't expect them to use the broken version for years before 2.8.0 finally releases. I think this bug should stay open until 2.8.0 is released or fix is backported into stable.

Best regards,
Andrej

(In reply to Andrej M. from comment #19)

> IMHO this is a wrong resolution of this bug and unacceptable from a point of
> normal Krusader user. You can't expect from users without knowledge of
> compiling programs to build their own Krusader version and you also can't
> expect them to use the broken version for years before 2.8.0 finally
> releases. I think this bug should stay open until 2.8.0 is released or fix
> is backported into stable.

I agree!

Is there any information about *why* this happens? Unfortunately there wasn't any error or log message (I know of). Shouldn't there be some kind of info, warning or error messages when a function like this is called (and) fails?

> FROM:
> cmake ../krusader -DCMAKE_INSTALL_PREFIX=/usr/ -DCMAKE_C_FLAGS="-O2 -fPIC" -DCMAKE_CXX_FLAGS="-O2 -fPIC"
> TO:
> cmake ../krusader -DCMAKE_INSTALL_PREFIX=/opt/krusader -DCMAKE_C_FLAGS="-O2 -fPIC" -DCMAKE_CXX_FLAGS="-O2 -fPIC"

That is not an acceptable fix or even workaround. I cannot ship that in distribution packages, those MUST be installed to /usr.

I suspect that something is invoking a wrong executable, from kdelibs 4 or even 3, see, e.g., bug #386859 for a similar issue.

According to strace, it runs /usr/libexec/kf5/kioslave5 correctly, with /usr/lib64/qt5/plugins/kio_krarc.so, so the paths seem all right. I guess I need to strace the kioslave5 process next.

As far as I can tell, the kioslave5 process crashes on startup when using kio_krarc, which is why it looks unresponsive to Krusader.

Using this to debug further:
strace -f kioclient5 ls krarc:/path/to/archive.7z/ 2>&1 | less
I get the same hanging behavior as in Krusader, and indeed, as I suspected, the kioslave5 child process is segfaulting:
[pid 45454] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---

This is a backtrace from ABRT:
https://bugzilla.redhat.com/show_bug.cgi?id=2114822

> Thread no. 1 (8 frames)
> #0 std::__atomic_base<QThreadData*>::load at /usr/include/c++/12/bits/atomic_base.h:818
> #1 std::atomic<QThreadData*>::load at /usr/include/c++/12/atomic:579
> #2 QAtomicOps<QThreadData*>::loadRelaxed<QThreadData*> at ../../include/QtCore/../../src/corelib/thread/qatomic_cxx11.h:239
> #3 QBasicAtomicPointer<QThreadData>::loadRelaxed at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:248
> #4 QObject::thread at kernel/qobject.cpp:1487
> #5 KIO::SlaveBase::SlaveBase at /usr/src/debug/kf5-kio-5.96.0-1.fc36.x86_64/src/core/slavebase.cpp:266
> #6 kio_krarcProtocol::kio_krarcProtocol at /usr/src/debug/krusader-2.7.2-6.fc36.x86_64/krArc/krarc.cpp:144
> #7 kdemain at /usr/src/debug/krusader-2.7.2-6.fc36.x86_64/krArc/krarc.cpp:129

The reporter Wladimir Palant writes:
> Judging from the backtrace, this is a regression from https://invent.kde.org/frameworks/kio/-/commit/865d9b7a80a02979d46bf3dede2dc4d551d501ba – the possibility that `qApp` might be null is not considered here.

CCing the author of the pinpointed commit (David Faure).

Ping? Can somebody please look at this regression? We have already pinpointed the offending commit, I have even posted a suggested fix that just needs testing as a comment to that commit. It looks like this should be a really easy fix.

I am on Arch Linux and I tried krusader-git package from AUR. Git version does not have this issue, I can browse archives like before.

It seems there is planned release of 2.8.0 in a week from now (Nov 20): https://invent.kde.org/utilities/krusader/-/merge_requests/110

So I guess this bug is solved some time between 2.7.2 release and now.

The official 2.8.0 release is out and it fixes the problem for me:

Krusader: 2.8.0
Operating System: Manjaro

Thanks to everyone involved in the release.

Best regards,
Andrej