Bug 481878 - Plasma Crashes while dragging a file to Chromium's icon in the icons-only task manager when there are Chromium windows
Summary: Plasma Crashes while dragging a file to Chromium's icon in the icons-only tas...
Status: RESOLVED DUPLICATE of bug 480474
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.27.10
Platform: Neon Linux
: NOR crash
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2024-02-27 02:53 UTC by Eric R
Modified: 2024-02-27 19:49 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
New crash information added by DrKonqi (84.07 KB, text/plain)
2024-02-27 02:53 UTC, Eric R
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric R 2024-02-27 02:53:45 UTC
Application: plasmashell (5.27.10)

Qt Version: 5.15.12
Frameworks Version: 5.114.0
Operating System: Linux 6.5.0-21-generic x86_64
Windowing System: Wayland
Distribution: KDE neon 5.27
DrKonqi: 5.27.10 [CoredumpBackend]

-- Information about the crash:
Bug 481876 is also my report, from the first time this happened. This is my retry. I also tried it once with only one Chromium window open, but that worked without problem. With two Chromium windows open, I dragged a file to the Chromium icon in the task manager. The panel disappeared as I dragged the file from the panel to the preview of the Chromium window. 

In spite of that, I was able to complete the drag and drop and attached the file to an email successfully (this time and last time).

Also, in both cases, Plasma re-started successfully and I was able to continue working.

Until recently, Wayland was a "no-go" on my Thinkpad T510, but now it's working well! Except for this. But again, Plasma re-started without drama. So, overall, Kudos to the Plasma team!

The reporter is unsure if this crash is reproducible.

-- Backtrace (Reduced):
#6  std::__atomic_base<QThreadData*>::load(std::memory_order) const (__m=std::memory_order_acquire, this=<error reading variable: Cannot access memory at address 0x8>) at /usr/include/c++/11/bits/atomic_base.h:818
#7  std::atomic<QThreadData*>::load(std::memory_order) const (__m=std::memory_order_acquire, this=<error reading variable: Cannot access memory at address 0x8>) at /usr/include/c++/11/atomic:578
#8  QAtomicOps<QThreadData*>::loadAcquire<QThreadData*>(std::atomic<QThreadData*> const&) (_q_value=<error reading variable: Cannot access memory at address 0x8>) at ../../include/QtCore/../../src/corelib/thread/qatomic_cxx11.h:251
#9  QBasicAtomicPointer<QThreadData>::loadAcquire() const (this=<error reading variable: Cannot access memory at address 0x8>) at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:255
#10 QBasicAtomicPointer<QThreadData>::operator QThreadData*() const (this=<error reading variable: Cannot access memory at address 0x8>) at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:251


The reporter indicates this bug may be a duplicate of or related to bug 480474, bug 481876.

Reported using DrKonqi
Comment 1 Eric R 2024-02-27 02:53:46 UTC
Created attachment 166120 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.
Comment 2 Nate Graham 2024-02-27 19:49:09 UTC
*** This bug has been marked as a duplicate of bug 480474 ***