[ksmserver] [Bug 383341] ksmserver crashes when closing long-running Eclipse instances
https://bugs.kde.org/show_bug.cgi?id=383341 Kai Wb. changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #3 from Kai Wb. --- Works in the meantime again and I dropped Eclipse anyway. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected
https://bugs.kde.org/show_bug.cgi?id=356225 Kai Wb. changed: What|Removed |Added CC|cu...@debian.org| -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 396319] KWin fails to accept large window icons leading to X11 errors and applications not starting
https://bugs.kde.org/show_bug.cgi?id=396319 --- Comment #2 from Kai Wb. --- (In reply to Martin Flöser from comment #1) > Is xprop able to retrieve the icon I think I'm not following you: wouldn't I need a running application/window for xprop to work? With the shipped (large) icon file the application is not starting. I can just see the window border for a split second and then the application dies with that X error. Or do you mean "can xprop retrieve the manually scaled down icon"? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 396319] New: KWin fails to accept large window icons leading to X11 errors and applications not starting
https://bugs.kde.org/show_bug.cgi?id=396319
Bug ID: 396319
Summary: KWin fails to accept large window icons leading to X11
errors and applications not starting
Product: kwin
Version: 5.12.5
Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: platform-x11-standalone
Assignee: kwin-bugs-n...@kde.org
Reporter: cu...@debian.org
Target Milestone: ---
Flags: X11+, Gallium3D+, Mesa+
I came across a commercial application which tries to set a really large
application icon (2100×1500 pixels). This leads to an X11 error with KWin:
> X Error of failed request: BadLength (poly request too large or internal
> Xlib length error)
> Major opcode of failed request: 146 ()
> Minor opcode of failed request: 74
> Serial number of failed request: 168
> Current serial number in output stream: 168
With xtrace (and setting LIBGL_DRI3_DISABLE=true, without this xtrace was stuck
before logging the error) I was able to dig out the following failing request:
> 003:<: Warning: buffer filled!
> 003:<: Warning: Waiting for rest of package (yet got 65524 of 17640036)!
>003:<: Warning: buffer filled!
>003:<:009d:17640036: Request(18): ChangeProperty mode=Replace(0x00)
>>window=0x0745 property=0x152("_NET_WM_ICON") type=0x6("CARDINAL")
>data=0x0834,0x0834,0x,0x000,[...]
Manually scaling the window icon file down, let me start the application.
Now, according to
https://specifications.freedesktop.org/wm-spec/latest/ar01s05.html#idm139870829941264
it is the window managers job to scale the image down and that no maximum size
is mandated by the spec for _NET_WM_ICON. This seems to indicate to me, that an
application is actually free to set such a ridiculously large icon and the
window manager should just scale it down.
[NB: I can trigger this bug also with the Windows version of the application,
if I run it through Wine. This seems to indicate, that Wine isn't scaling the
image down either and also expects the window manager to deal with it.]
Let me know if you need anything else.
--
You are receiving this mail because:
You are watching all bug changes.
[ksmserver] [Bug 383341] New: ksmserver crashes when closing long-running Eclipse instances
https://bugs.kde.org/show_bug.cgi?id=383341 Bug ID: 383341 Summary: ksmserver crashes when closing long-running Eclipse instances Product: ksmserver Version: 5.8.7 Platform: Debian testing OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: l.lu...@kde.org Reporter: cu...@debian.org Target Milestone: --- Created attachment 107185 --> https://bugs.kde.org/attachment.cgi?id=107185=edit KCrash report for the When I close a long-running eclipse instance I can reliably see the crash shown in the attached KCrash report, which obviously takes the whole session with it. This has been happening for a while over different versions (well before the Debian Stretch release, but I just now got around to install all required debugging symbols) of Plasma, Qt, Eclipse and OpenJDK and since I'm only seeing this once a day, it hasn't been too annoying. According to the backtrace it seems to be a double free or memory corruption error. Let me know if you need anything else. -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 378854] Konversation crashes randomly
https://bugs.kde.org/show_bug.cgi?id=378854 Kai Wb. <cu...@debian.org> changed: What|Removed |Added CC||cu...@debian.org --- Comment #4 from Kai Wb. <cu...@debian.org> --- Any chance for a soonish release containing this fix? Without it, Konversation is almost unusable for me. Thanks for considering. -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 381066] Konversation crashes with a segmentation fault
https://bugs.kde.org/show_bug.cgi?id=381066 Kai Wb. <cu...@debian.org> changed: What|Removed |Added CC|cu...@debian.org| --- Comment #12 from Kai Wb. <cu...@debian.org> --- (In reply to Christoph Feck from comment #11) > Comment #10 is bug 378854. Thanks for the pointer! -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 381066] Konversation crashes with a segmentation fault
https://bugs.kde.org/show_bug.cgi?id=381066 Kai Wb. <cu...@debian.org> changed: What|Removed |Added CC||cu...@debian.org --- Comment #10 from Kai Wb. <cu...@debian.org> --- I've a similar looking crash. I just have to idle for a while with a couple of Freenode and one Snoonet channels open and eventually it'll crash (most often, when Konversation is in the background, sometimes when it does get focus). My system: - Debian GNU/Linux, Testing - Qt: 5.7.1 (5.7.1+dfsg-3+b1) - Konversation: 1.7.2 (1.7.2-1) My backtrace is: > Application: Konversation (konversation), signal: Segmentation fault > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [Current thread is 1 (Thread 0x7f44a27b2fc0 (LWP 7509))] > > Thread 4 (Thread 0x7f449d882700 (LWP 7512)): > #0 0x7f44ae92363d in poll () at ../sysdeps/unix/syscall-template.S:84 > #1 0x7f44a9b9cc16 in g_main_context_poll (priority=, > n_fds=1, fds=0x7f4494002e70, timeout=, context=0x7f4494000990) > at ././glib/gmain.c:4271 > #2 g_main_context_iterate (context=context@entry=0x7f4494000990, > block=block@entry=1, dispatch=dispatch@entry=1, self=) at > ././glib/gmain.c:3967 > #3 0x7f44a9b9cd2c in g_main_context_iteration (context=0x7f4494000990, > may_block=may_block@entry=1) at ././glib/gmain.c:4033 > #4 0x7f44af53b06b in QEventDispatcherGlib::processEvents > (this=0x7f44940008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 > #5 0x7f44af4e49ca in QEventLoop::exec (this=this@entry=0x7f449d881c80, > flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 > #6 0x7f44af3120f3 in QThread::exec (this=) at > thread/qthread.cpp:507 > #7 0x7f44af316da8 in QThreadPrivate::start (arg=0x55c9e7fff270) at > thread/qthread_unix.cpp:368 > #8 0x7f44ad272494 in start_thread (arg=0x7f449d882700) at > pthread_create.c:333 > #9 0x7f44ae92ca8f in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 > > Thread 3 (Thread 0x7f449ecc3700 (LWP 7511)): > #0 0x7f44ae92363d in poll () at ../sysdeps/unix/syscall-template.S:84 > #1 0x7f44a9b9cc16 in g_main_context_poll (priority=, > n_fds=1, fds=0x7f449001c830, timeout=, context=0x7f449990) > at ././glib/gmain.c:4271 > #2 g_main_context_iterate (context=context@entry=0x7f449990, > block=block@entry=1, dispatch=dispatch@entry=1, self=) at > ././glib/gmain.c:3967 > #3 0x7f44a9b9cd2c in g_main_context_iteration (context=0x7f449990, > may_block=may_block@entry=1) at ././glib/gmain.c:4033 > #4 0x7f44af53b06b in QEventDispatcherGlib::processEvents > (this=0x7f4498c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 > #5 0x7f44af4e49ca in QEventLoop::exec (this=this@entry=0x7f449ecc2c50, > flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 > #6 0x7f44af3120f3 in QThread::exec (this=this@entry=0x7f44af7c1d60 > <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at > thread/qthread.cpp:507 > #7 0x7f44af74c6d5 in QDBusConnectionManager::run (this=0x7f44af7c1d60 > <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at > qdbusconnection.cpp:178 > #8 0x7f44af316da8 in QThreadPrivate::start (arg=0x7f44af7c1d60 > <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at > thread/qthread_unix.cpp:368 > #9 0x7f44ad272494 in start_thread (arg=0x7f449ecc3700) at > pthread_create.c:333 > #10 0x7f44ae92ca8f in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 > > Thread 2 (Thread 0x7f44a067f700 (LWP 7510)): > #0 0x7f44ae92363d in poll () at ../sysdeps/unix/syscall-template.S:84 > #1 0x7f44abcf5150 in poll (__timeout=-1, __nfds=1, __fds=0x7f44a067eb80) > at /usr/include/x86_64-linux-gnu/bits/poll2.h:46 > #2 _xcb_conn_wait (c=c@entry=0x55c9e7f87940, cond=cond@entry=0x55c9e7f87980, > vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:479 > #3 0x7f44abcf6ee9 in xcb_wait_for_event (c=0x55c9e7f87940) at > ../../src/xcb_in.c:693 > #4 0x7f44a23a3b69 in QXcbEventReader::run (this=0x55c9e7f920c0) at > qxcbconnection.cpp:1343 > #5 0x7f44af316da8 in QThreadPrivate::start (arg=0x55c9e7f920c0) at > thread/qthread_unix.cpp:368 > #6 0x7f44ad272494 in start_thread (arg=0x7f44a067f700) at > pthread_create.c:333 > #7 0x7f44ae92ca8f in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 > > Thread 1 (Thread 0x7f44a27b2fc0 (LWP 7509)): > [KCrash Handler] > #6 0x7f44af39d00f in std::__atomic_base::load > (__m=std::memory_order_relaxed, this=) at > /usr
[plasmashell] [Bug 356225] Panel moves to wrong screen when external monitor is connected
https://bugs.kde.org/show_bug.cgi?id=356225 Kai Wb. <cu...@debian.org> changed: What|Removed |Added CC||cu...@debian.org --- Comment #120 from Kai Wb. <cu...@debian.org> --- I can confirm this bug (the bug 356720 variant in my case) with 5.6.4 as part of Debian testing (in fact I would say it has become more frequent after the most recent update). (In reply to comment #115) > I'm subscribed to this bug-- and have been using a workaround partially > comprised of other people's workarounds for weeks. Since, all I ever see are > "me too" posts and I haven't spent any time really fixing the problem > either-- well, I thought I'd share my dirty little secret. That seems rather dirty and might change the settings of plugins I'd like to leave untouched. I found it easier to just look for the right containment and set the correct lastScreen value there. For me it's easy to identify by the dimensions the wallpaper plugin saves in ~/.config/plasma-org.kde.plasma.desktop-appletsrc and is indeed screen 0. For whatever reason it likes to jump to lastScreen=1 (the left-most screen) from time to time. If you don't make changes that often to your screen configuration it might be easier to create an (immutable) backup file you restore during session init or on your shortcut. Note for others, who like me see this issue not on every login and therefore change the config manually and run the plasmashell from a terminal: you can detach the process from said terminal either by invoking it directly with nohup or afterwards with disown, once the job is in the background. -- You are receiving this mail because: You are watching all bug changes.
