[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Stefano Bonicatti changed: What|Removed |Added CC||smj...@gmail.com --- Comment #16 from Stefano Bonicatti --- I have tested with the test case attached in this bug report and i can confirm the issue. I can also confirm that running the same test case with the patch works, valgrind doesn't crash/complains about illegal instructions. Tested with an AMD FX 6300. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 362134] Alternative shortcuts breaks primary shortcuts in Krita 3.0 alpha.
https://bugs.kde.org/show_bug.cgi?id=362134 Stefano Bonicatti changed: What|Removed |Added CC||smj...@gmail.com --- Comment #2 from Stefano Bonicatti --- So i'm trying to fix this since yesterday, but all i can see is a mess with the action and shortcut dealing. We have a lot of duplicate code that does duplicate stuff and gets called multiple time to do (apparently the same?) thing. Namely KActionCollection writes the shortcut settings in kritashortcutsrc through writeSettings function when they are changed, though there it loops through the actions and it write both shortcuts (primary and alternate), with a format that is "actionName=primary; alternate". When Krita loads, readSettings gets called which internally calls loadCustomShortcuts of our KisActionRegistry class and here a first bell rang: we do have a writeCustomShortcuts function in KisActionRegistry but it's not used, moreover it writes the shortcut with a different format, namely only the custom shortcut is written. But then again even more confusion is added looking at ActionInfoItem, the struct used in writeCustomShortcuts and loadCustomShortcuts. Is defaultShortcut meant to be the primary shortcut or the actual defaultShortcut that is shown as a "default" option in the shortcut editor? And if the latter, since we only have one customShortcut key sequence, how can that deal with having a possible primary and alternate shortcut? And in the end, looking at KisShortcutsDialog_p.cpp, primarySequence and alternateSequence functions we see what the dialog (and probably the rest of the system) expexts, an action with TWO key sequences, but when we load the configs from our kritashortcutsrc we only load one, with the string "primary; alternate". -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361926] New: unhandled x86-solaris syscall: 84
https://bugs.kde.org/show_bug.cgi?id=361926 Bug ID: 361926 Summary: unhandled x86-solaris syscall: 84 Product: valgrind Version: 3.12 SVN Platform: Compiled Sources OS: Solaris Status: UNCONFIRMED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: smj...@gmail.com Solaris 11.3: ==2875== Memcheck, a memory error detector ==2875== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==2875== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==2875== Command: inficlose -v clusmir ==2875== --2875-- WARNING: unhandled x86-solaris syscall: 84 --2875-- You may be able to write your own handler. --2875-- Read the file README_MISSING_SYSCALL_OR_IOCTL. --2875-- Nevertheless we consider this a bug. Please report --2875-- it at http://valgrind.org/support/bug_reports.html. The missing syscall is SYS_sysfs. Reproducible: Always Steps to Reproduce: 1. Run valgrind on a binary using sysfs() system call. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 359217] Krita crashes after closing an extra view of a file with painting assistants
https://bugs.kde.org/show_bug.cgi?id=359217 Stefano Bonicatti changed: What|Removed |Added CC||smj...@gmail.com --- Comment #3 from Stefano Bonicatti --- I can confirm this too in Krita 3.0 4256943a1e17b52f61a5489b2f1a781379a2ed80. We also have a general issue with OpenGL and new views opened on the same image. First of all we destroy and recreate the opengl image texture too many times (once should be enough? but it happens like 3-4 times, due to separate events like connecting the canvas and setting the monitor profile). Then when closing the new view it crashes inside KisTextureTile::bindToActiveTexture with an access violation (the chain of calls comes from drawGL) most likely because that tile is actually being deleted and the canvas for some reason refers to an old opengl texture. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359344] New: Plasmashell crash while opening an application (Teamspeak)
https://bugs.kde.org/show_bug.cgi?id=359344 Bug ID: 359344 Summary: Plasmashell crash while opening an application (Teamspeak) Product: plasmashell Version: 5.5.3 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: smj...@gmail.com CC: bhus...@gmail.com, plasma-b...@kde.org Application: plasmashell (5.5.3) Qt Version: 5.5.1 Operating System: Linux 4.4.0-3-default x86_64 Distribution: "openSUSE Tumbleweed (20160117) (x86_64)" -- Information about the crash: - What I was doing when the application crashed: 1) Clicked on the application launcher 2) Searched for Teamspeak 3) Clicked the Teamspeak icon Teamspeak opened but plasmashell crashed (and the restored itself automatically). I cannot reproduce, but the crash happened randomly in other situations too, opening other applications. -- Backtrace: Application: Plasma (plasmashell), signal: Aborted Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fa59fa678c0 (LWP 2193))] Thread 24 (Thread 0x7fa5891b8700 (LWP 2194)): #0 0x7fa598fe824d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fa59debd432 in _xcb_conn_wait (__timeout=-1, __nfds=1, __fds=0x7fa5891b7c00) at /usr/include/bits/poll2.h:46 #2 0x7fa59debd432 in _xcb_conn_wait (c=c@entry=0x9879c0, cond=cond@entry=0x987a00, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:459 #3 0x7fa59debf007 in xcb_wait_for_event (c=0x9879c0) at xcb_in.c:693 #4 0x7fa58b307e29 in QXcbEventReader::run() (this=0x992080) at qxcbconnection.cpp:1229 #5 0x7fa5996d894f in QThreadPrivate::start(void*) (arg=0x992080) at thread/qthread_unix.cpp:331 #6 0x7fa5987ef4a4 in start_thread (arg=0x7fa5891b8700) at pthread_create.c:334 #7 0x7fa598ff0bdd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 23 (Thread 0x7fa58242a700 (LWP 2210)): #0 0x7fa595720539 in g_mutex_lock (mutex=mutex@entry=0x7fa57c000990) at gthread-posix.c:1338 #1 0x7fa5956dc300 in g_main_context_acquire (context=0x7fa57c000990) at gmain.c:3214 #2 0x7fa5956dd165 in g_main_context_iterate (context=context@entry=0x7fa57c000990, block=block@entry=1, dispatch=dispatch@entry=1, self=) at gmain.c:3790 #3 0x7fa5956dd39c in g_main_context_iteration (context=0x7fa57c000990, may_block=may_block@entry=1) at gmain.c:3901 #4 0x7fa5998fd52b in QEventDispatcherGlib::processEvents(QFlags) (this=0x7fa57c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #5 0x7fa5998a763a in QEventLoop::exec(QFlags) (this=this@entry=0x7fa582429cf0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #6 0x7fa5996d3b1c in QThread::exec() (this=this@entry=0xa71d80) at thread/qthread.cpp:503 #7 0x7fa59c9a39a5 in QQmlThreadPrivate::run() (this=0xa71d80) at /usr/src/debug/qtdeclarative-opensource-src-5.5.1/src/qml/qml/ftw/qqmlthread.cpp:141 #8 0x7fa5996d894f in QThreadPrivate::start(void*) (arg=0xa71d80) at thread/qthread_unix.cpp:331 #9 0x7fa5987ef4a4 in start_thread (arg=0x7fa58242a700) at pthread_create.c:334 #10 0x7fa598ff0bdd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 22 (Thread 0x7fa57540b700 (LWP 2219)): #0 0x7fa598fe824d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fa5956dd294 in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7fa570002e70, timeout=, context=0x7fa57990) at gmain.c:4135 #2 0x7fa5956dd294 in g_main_context_iterate (context=context@entry=0x7fa57990, block=block@entry=1, dispatch=dispatch@entry=1, self=) at gmain.c:3835 #3 0x7fa5956dd39c in g_main_context_iteration (context=0x7fa57990, may_block=may_block@entry=1) at gmain.c:3901 #4 0x7fa5998fd52b in QEventDispatcherGlib::processEvents(QFlags) (this=0x7fa578c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #5 0x7fa5998a763a in QEventLoop::exec(QFlags) (this=this@entry=0x7fa57540acf0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #6 0x7fa5996d3b1c in QThread::exec() (this=this@entry=0xc56780) at thread/qthread.cpp:503 #7 0x7fa59c9a39a5 in QQmlThreadPrivate::run() (this=0xc56780) at /usr/src/debug/qtdeclarative-opensource-src-5.5.1/src/qml/qml/ftw/qqmlthread.cpp:141 #8 0x7fa5996d894f in QThreadPrivate::start(void*) (arg=0xc56780) at thread/qthread_unix.cpp:331 #9 0x7fa5987ef4a4 in start_thread (arg=0x7fa57540b700) at pthread_create.c:334 #10 0x7fa598ff0bdd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 21 (Thread 0x7fa56fa64700 (LWP 2220)): #0 0x7fa598fe824d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fa5956dd294 in g_main_context_iterate (priority=2147483647, n_fds=1, fds=0x7fa568003070
