Can you reproduce it everytime?
Without debug symbols I can't find out why is it crashing.

I rebuilt print-manager with debugging symbols, below goes a new backtrace. It crashes everytime plasma-desktop starts.

Application: Powłoka pulpitu Plazmy (plasma-desktop), signal: Segmentation fault
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0xb1234740 (LWP 29647))]

Thread 5 (Thread 0xad745b40 (LWP 29652)):
#0  0xb76e7424 in __kernel_vsyscall ()
#1  0xb209e84b in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2  0xb759b9bc in __pthread_cond_wait (cond=0xb31a08d0, mutex=0xb31a08b8) at forward.c:149
#3  0xb309def2 in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4
#4  0xb309df3f in ?? () from /usr/lib/i386-linux-gnu/libQtScript.so.4
#5  0xb209ad78 in start_thread (arg=0xad745b40) at pthread_create.c:311
#6  0xb758e01e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 4 (Thread 0xa6a5db40 (LWP 29655)):
#0  0xb75ca173 in __x86.get_pc_thunk.bx () from /lib/i386-linux-gnu/libc.so.6
#1  0xb759bbd8 in pthread_mutex_unlock (mutex=0xa6100558) at forward.c:194
#2  0xb1fc8be0 in g_mutex_unlock (mutex=mutex@entry=0xa61004e0) at /build/buildd/glib2.0-2.38.0/./glib/gthread-posix.c:232
#3  0xb1f85572 in g_main_context_check (context=context@entry=0xa61004e0, max_priority=2147483647, fds=fds@entry=0xa6102288, n_fds=n_fds@entry=1) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3554
#4  0xb1f85aea in g_main_context_iterate (context=context@entry=0xa61004e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3709
#5  0xb1f85c98 in g_main_context_iteration (context=0xa61004e0, may_block=1) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3773
#6  0xb5ff78df in QEventDispatcherGlib::processEvents (this=0xa6100468, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#7  0xb5fc69f3 in QEventLoop::processEvents (this=this@entry=0xa6a5d228, flags=...) at kernel/qeventloop.cpp:149
#8  0xb5fc6d19 in QEventLoop::exec (this=this@entry=0xa6a5d228, flags=...) at kernel/qeventloop.cpp:204
#9  0xb5eb5e3d in QThread::exec (this=this@entry=0x91732f0) at thread/qthread.cpp:542
#10 0xb5fa6e14 in QInotifyFileSystemWatcherEngine::run (this=0x91732f0) at io/qfilesystemwatcher_inotify.cpp:265
#11 0xb5eb872f in QThreadPrivate::start (arg=0x91732f0) at thread/qthread_unix.cpp:338
#12 0xb209ad78 in start_thread (arg=0xa6a5db40) at pthread_create.c:311
#13 0xb758e01e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 3 (Thread 0xa52ffb40 (LWP 29657)):
#0  g_mutex_get_impl (mutex=0xa5308d90) at /build/buildd/glib2.0-2.38.0/./glib/gthread-posix.c:123
#1  0xb1fc8b98 in g_mutex_lock (mutex=mutex@entry=0xa5308d90) at /build/buildd/glib2.0-2.38.0/./glib/gthread-posix.c:213
#2  0xb1f85b34 in g_main_context_poll (priority=2147483647, n_fds=1, fds=0xa49023a0, timeout=-1, context=0xa5308d90) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:4001
#3  g_main_context_iterate (context=0xa5308d90, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3707
#4  0xb1f8603b in g_main_loop_run (loop=0xa5308d58) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3906
#5  0xa5df20ea in gdbus_shared_thread_func (user_data=0xa5308d78) at /build/buildd/glib2.0-2.38.0/./gio/gdbusprivate.c:278
#6  0xb1fabc3a in g_thread_proxy (data=0x92247b0) at /build/buildd/glib2.0-2.38.0/./glib/gthread.c:798
#7  0xb209ad78 in start_thread (arg=0xa52ffb40) at pthread_create.c:311
#8  0xb758e01e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 2 (Thread 0xa10f5b40 (LWP 29660)):
#0  0xb76e7424 in __kernel_vsyscall ()
#1  0xb75a14d2 in clock_gettime (clock_id=1, tp=0xa10f5038) at ../sysdeps/unix/clock_gettime.c:115
#2  0xb5f133ec in do_gettime (frac=0xa10f5030, sec=0xa10f5028) at tools/qelapsedtimer_unix.cpp:123
#3  qt_gettime () at tools/qelapsedtimer_unix.cpp:140
#4  0xb5ff8c61 in QTimerInfoList::updateCurrentTime (this=this@entry=0xa530a35c) at kernel/qeventdispatcher_unix.cpp:354
#5  0xb5ff7b5e in timerSourceCheckHelper (src=0xa530a328) at kernel/qeventdispatcher_glib.cpp:150
#6  0xb1f8557f in g_main_context_check (context=context@entry=0xa530a160, max_priority=2147483647, fds=fds@entry=0xa530a3f0, n_fds=n_fds@entry=1) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3556
#7  0xb1f85aea in g_main_context_iterate (context=context@entry=0xa530a160, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3709
#8  0xb1f85c98 in g_main_context_iteration (context=0xa530a160, may_block=1) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3773
#9  0xb5ff78df in QEventDispatcherGlib::processEvents (this=0xa530a318, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#10 0xb5fc69f3 in QEventLoop::processEvents (this=this@entry=0xa10f5248, flags=...) at kernel/qeventloop.cpp:149
#11 0xb5fc6d19 in QEventLoop::exec (this=this@entry=0xa10f5248, flags=...) at kernel/qeventloop.cpp:204
#12 0xb5eb5e3d in QThread::exec (this=0x9a54d60) at thread/qthread.cpp:542
#13 0xa28911fe in KCupsConnection::run (this=0x9a54d60) at ../../libkcups/KCupsConnection.cpp:303
#14 0xb5eb872f in QThreadPrivate::start (arg=0x9a54d60) at thread/qthread_unix.cpp:338
#15 0xb209ad78 in start_thread (arg=0xa10f5b40) at pthread_create.c:311
#16 0xb758e01e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:131

Thread 1 (Thread 0xb1234740 (LWP 29647)):
[KCrash Handler]
#7  0xa28aa1e9 in JobModel::updateJob (this=0x8ad2448, pos=2, job=...) at ../../libkcups/JobModel.cpp:358
#8  0xa28a9896 in JobModel::getJobFinished (this=0x8ad2448) at ../../libkcups/JobModel.cpp:232
#9  0xa28abef1 in JobModel::qt_static_metacall (_o=0x8ad2448, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0xa5353bc8) at ./JobModel.moc:113
#10 0xb5fd977a in QMetaCallEvent::placeMetaCall (this=0xa533c138, object=0x8ad2448) at kernel/qobject.cpp:524
#11 0xb5fe158b in QObject::event (this=0x8ad2448, e=0xa533c138) at kernel/qobject.cpp:1194
#12 0xb54d8744 in QApplicationPrivate::notify_helper (this=0x8906a68, receiver=0x8ad2448, e=0xa533c138) at kernel/qapplication.cpp:4567
#13 0xb54df223 in QApplication::notify (this=0x88a73b0, receiver=receiver@entry=0x8ad2448, e=e@entry=0xa533c138) at kernel/qapplication.cpp:4353
#14 0xb663c024 in KApplication::notify (this=0x88a73b0, receiver=0x8ad2448, event=0xa533c138) at ../../kdeui/kernel/kapplication.cpp:311
#15 0xb5fc7eda in QCoreApplication::notifyInternal (this=0x88a73b0, receiver=receiver@entry=0x8ad2448, event=event@entry=0xa533c138) at kernel/qcoreapplication.cpp:946
#16 0xb5fcb6ad in sendEvent (event=0xa533c138, receiver=0x8ad2448) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#17 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x8872130) at kernel/qcoreapplication.cpp:1570
#18 0xb5fcbbbc in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1463
#19 0xb5ff7f6e in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236
#20 postEventSourceDispatch (s=s@entry=0x8906d98) at kernel/qeventdispatcher_glib.cpp:279
#21 0xb1f8582e in g_main_dispatch (context=0x8906d20, context@entry=0x88786c8) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3065
#22 g_main_context_dispatch (context=context@entry=0x8906d20) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3641
#23 0xb1f85bd8 in g_main_context_iterate (context=context@entry=0x8906d20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3712
#24 0xb1f85c98 in g_main_context_iteration (context=0x8906d20, may_block=1) at /build/buildd/glib2.0-2.38.0/./glib/gmain.c:3773
#25 0xb5ff78bf in QEventDispatcherGlib::processEvents (this=this@entry=0x8872ea8, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#26 0xb558d32e in QGuiEventDispatcherGlib::processEvents (this=0x8872ea8, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#27 0xb5fc69f3 in QEventLoop::processEvents (this=this@entry=0xbfd3b328, flags=...) at kernel/qeventloop.cpp:149
#28 0xb5fc6d19 in QEventLoop::exec (this=this@entry=0xbfd3b328, flags=...) at kernel/qeventloop.cpp:204
#29 0xb5fcc89e in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1218
#30 0xb54d6974 in QApplication::exec () at kernel/qapplication.cpp:3828
#31 0xb76a5947 in kdemain (argc=1, argv=0xbfd3b4c4) at ../../../../plasma/desktop/shell/main.cpp:126
#32 0x0804858b in main (argc=1, argv=0xbfd3b4c4) at plasma-desktop_dummy.cpp:3

thanks for the new backtrace

*** Bug 328235 has been marked as a duplicate of this bug. ***

*** Bug 328950 has been marked as a duplicate of this bug. ***

*** Bug 333993 has been marked as a duplicate of this bug. ***

I can confirm this bug. plasma-desktop crashed on every restart of KDE, until I removed the org.kde.printmanager entry from .kde/share/config/plasma-desktop-appletsrc. This solved the problem for me.

Created attachment 87557 [details]
New crash information added by DrKonqi

kde-print-queue (0.3.0) on KDE Platform 4.13.1 using Qt 4.8.6

Still present in KDE 4.13.1 on kubuntu 14.04

-- Backtrace (Reduced):
#6  0x00007fe968a876f2 in JobModel::updateJob(int, KCupsJob const&) () from /usr/lib/libkcupslib.so
#7  0x00007fe968a8b2b9 in JobModel::getJobFinished() () from /usr/lib/libkcupslib.so
[...]
#9  0x00007fe967312c1e in QObject::event (this=0xe01340, e=<optimized out>) at kernel/qobject.cpp:1194
#10 0x00007fe967f67e2c in QApplicationPrivate::notify_helper (this=this@entry=0xc16480, receiver=receiver@entry=0xe01340, e=e@entry=0x7fe95008e260) at kernel/qapplication.cpp:4567
#11 0x00007fe967f6e4a0 in QApplication::notify (this=this@entry=0x7ffff88072a0, receiver=receiver@entry=0xe01340, e=e@entry=0x7fe95008e260) at kernel/qapplication.cpp:4353

Confirmed. Same issue.
It was working ok until i upgraded some stuff.

The solution from Eggert worked for me https://bugs.kde.org/show_bug.cgi?id=326289#c7

*** Bug 375983 has been marked as a duplicate of this bug. ***

*** Bug 361999 has been marked as a duplicate of this bug. ***

*** Bug 325932 has been marked as a duplicate of this bug. ***

I had the same issue on 
Fedora 25 
kernel: 4.10.10-200.fc25.x86_64
KDE Plasma: 5.9.4
KDE Frameworks: 5.33.0
Qt: 5.7.1

Backtrace (sorry, no debug symbols):
#0  0x00007fff291c9d86 in JobModel::updateJob(int, KCupsJob const&) () at /lib64/libkcupslib.so
#1  0x00007fff291cc137 in JobModel::getJobFinished() () at /lib64/libkcupslib.so
#2  0x00007fff291d2335 in JobModel::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.7] () at /lib64/libkcupslib.so
#3  0x00007ffff1d717e9 in QObject::event(QEvent*) () at /lib64/libQt5Core.so.5
#4  0x00007ffff2615ecc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#5  0x00007ffff261d671 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#6  0x00007ffff1d496fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#7  0x00007ffff1d4bde0 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /lib64/libQt5Core.so.5
#8  0x00007ffff1d97653 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5Core.so.5
#9  0x00007fffe9ae4e52 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#10 0x00007fffe9ae51d0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#11 0x00007fffe9ae527c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#12 0x00007ffff1d976cf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#13 0x00007ffff1d4868a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#14 0x00007ffff1d5018c in QCoreApplication::exec() () at /lib64/libQt5Core.so.5
#15 0x0000555555571192 in main ()

Workaround:
temporary remove print manager until it's fixed:
# dnf remove kde-print-manager kde-print-manager-libs

*** Bug 381686 has been marked as a duplicate of this bug. ***

*** Bug 382244 has been marked as a duplicate of this bug. ***

Created attachment 112216 [details]
New crash information added by DrKonqi

plasmashell (5.12.4) using Qt 5.9.4

What I was doing when the application crashed: restarted cups service with one print job in the queue.
System experienced smth like kernel bug 12309 while that (copying data from sd card to ssd, everything was very slow).

-- Backtrace (Reduced):
#6  0x00007f25d75973c6 in JobModel::updateJob(int, KCupsJob const&) () at /lib64/libkcupslib.so
#7  0x00007f25d759bd0f in JobModel::getJobFinished() () at /lib64/libkcupslib.so
#9  0x00007f26a03c826a in QObject::event(QEvent*) () at /lib64/libQt5Core.so.5
#10 0x00007f26a14d192c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#11 0x00007f26a14d9174 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5

I can reliably reproduce this crash on Kubuntu 18.04. I tried to debug it using the Git version of print-manager. I’m not familiar with the code, so I don’t think I can submit a patch, but I think I can pinpoint the problem.

The crash occurs in line 328 in JobModel.cpp (in JobModel::updateJob()):
<https://github.com/KDE/print-manager/blob/9172f63f16a663b58de919e485579453e12d5560/libkcups/JobModel.cpp#L328>

The line is:

if (item(pos, ColStatus)->data(RoleJobState).toInt() != jobState) {

The expression item(pos, ColStatus) evaluates to NULL, hence the crash.

In my case, updateJob() is called from JobModel::getJobFinished() at line 202 within a branch described as "found at wrong position, take it and insert on the right position", see
<https://github.com/KDE/print-manager/blob/9172f63f16a663b58de919e485579453e12d5560/libkcups/JobModel.cpp#L202>

Perhaps this is already enough for one of the developers to come up with a solution. I’d be happy to help as much as I can.

Random idea:

If the job is not found, it first does a takeRow(), then an insertRow(). If the row to be removed is preceeding the row where to insert later, then the insert index "i" probably needs to be updated.

This is really odd, and sadly I could never reproduce it.

The code removes a row, inserts at another position and then crashes when updating it at the new position, it feels like the insert failed somehow...

I could add a check but that doesn't seem right :/

Git commit 5d3c5f7bc4174695af57cf5032a3d4117bd7577c by Daniel Nicoletti.
Committed on 06/06/2018 at 20:22.
Pushed by dantti into branch 'master'.

Possibly fix a crash by updating a row before moving it

This optimizes row updates and will update a row
before putting it in another position in order to
try to avoid a crash.

M  +63   -55   libkcups/JobModel.cpp

https://commits.kde.org/print-manager/5d3c5f7bc4174695af57cf5032a3d4117bd7577c

I'm not sure if this fixes the issue so please try...

Thanks so much for looking into this! Unfortunately, the crash is still there.

(Sorry for the late reply, but for some reason I wasn’t notified that this report had been updated.)

However, your changes made it a bit easier for me to continue debugging this. As it turns out, the problem appears to be that I have two jobs that have the same id. That is, within getJobFinished(), the 'jobs' variable (KCupsJobs) contains four jobs, and the first two have the same .id(). (They also have the  same .name().) I have four jobs in total.

Here is what happens inside the for loop over the KCupsJobs (the JobModel is initially empty, i.e. rowCount() == 0 at the start)

- Iteration/job 0: jobRow() for this KCupsJob returns -1, which means that the job isn’t in the model. The job is inserted at index 0.

- Iteration/job 1: jobRow() for this KCupsJob returns 0 because this KCupsJob has the same id as the one that was just inserted. updateJob() is called for row 0. Then the condition in "if (job_row != i)" is true ("found at wrong position") and the code tries to take row 0 and insert it at index 2. This fails for some reason so that there are actually no rows in the model anymore (rowCount() == 0). Perhaps insertRow() has undefined behavior when the given row index is greater than rowCount()?

- Iteration/job 2: jobRow() for this KCupsJob returns -1 as it is a different job. The code tries to insert it at index 2. insertJob() calls updateJob() with pos = 2, which crashes at some point because rowCount() is actually 0.

I have no idea why the duplicate jobs exist, but they are also visible on <http://localhost:631/jobs/>, so they’re real.

I’ve attempted to fix the problem in getJobFinished() by just inserting all jobs when the model is empty:

if (rowCount() == 0) {
    for (int i = 0; i < jobs.size(); ++i) {
        insertJob(i, jobs.at(i));
    }
} else {
    // (previous loop here)

For me, this avoids the crash during startup. (I’m not suggesting this is a proper fix.)

*** Bug 399400 has been marked as a duplicate of this bug. ***

Hi.

Today my KDE Plasma stopped booting normally. Got this libkcups.so core dumped error. Works fine after uninstalling cups package. Fedora 29

(In reply to saif1988 from comment #24)
> Hi.
> 
> Today my KDE Plasma stopped booting normally. Got this libkcups.so core
> dumped error. Works fine after uninstalling cups package. Fedora 29

Full stacktrace I got is here:
https://ask.fedoraproject.org/en/question/130338/kde-broken-after-fedora-upgrade/

A temporary fix should be to delete all queued print jobs because the problem occurs when there are multiple print jobs with the same id. Then you don’t have to uninstall cups and will still be able to print.

On the commandline, you should be able to delete all jobs by running "cancel -a". Or read <https://askubuntu.com/questions/350334/>.

I have not tested this on my machine as I want to be able to reproduce the crash when necessary.

(In reply to Marcel Martin from comment #26)
> A temporary fix should be to delete all queued print jobs because the
> problem occurs when there are multiple print jobs with the same id. Then you
> don’t have to uninstall cups and will still be able to print.
> 
> On the commandline, you should be able to delete all jobs by running "cancel
> -a". Or read <https://askubuntu.com/questions/350334/>.
> 
> I have not tested this on my machine as I want to be able to reproduce the
> crash when necessary.

Interesting, so you're saying that my boot problem was because there were jobs in the print queue?

> Interesting, so you're saying that my boot problem was because
> there were jobs in the print queue?

To be precise: The problem occurs whenever there are at least two jobs in your print queue with identical job ids. This should normally not happen, but it apparently does sometimes. 

When Plasma starts up, it loads various apps, including the one responsible for the printer status icon in the system tray. When that one is loaded, it goes through the jobs in the print queue and tries to gather information about them. When it does so and encounters two jobs with the same id, it crashes, taking Plasma with it. At least that is my theory so far.

Did you try 'cancel -a'? It would be interesting to know whether that fixes the problem.

(In reply to Marcel Martin from comment #28)
> > Interesting, so you're saying that my boot problem was because
> > there were jobs in the print queue?
> 
> To be precise: The problem occurs whenever there are at least two jobs in
> your print queue with identical job ids. This should normally not happen,
> but it apparently does sometimes. 
> 
> When Plasma starts up, it loads various apps, including the one responsible
> for the printer status icon in the system tray. When that one is loaded, it
> goes through the jobs in the print queue and tries to gather information
> about them. When it does so and encounters two jobs with the same id, it
> crashes, taking Plasma with it. At least that is my theory so far.
> 
> Did you try 'cancel -a'? It would be interesting to know whether that fixes
> the problem.

Interesting!. The consequences are super nasty though. My KDE desktop wouldn't boot at all. No wallpaper, no menus, nothing. Obvious debugging or first counter-measures won't work either (such as wiping out ~/.config/).

I haven't tried cancel -a now since the first thing I went through is re-installing cups completely which fixed the problem. Not sure how to reproduce it now.

Still, I was seconds away of installing other distro or something... This one should get fixed. I didn't do any weird stuff just user my printer a few times last night (and it worked fine)

> Perhaps insertRow() has undefined behavior when the given row index is greater than rowCount()?

The behaviour is actually well defined: It does nothing.

As the assumption that at each iteration of the loop there are at least "i" rows is wrong, it crashes.

Maybe the best option is to just skip jobs with duplicate ids?

*** Bug 409439 has been marked as a duplicate of this bug. ***

*** Bug 410124 has been marked as a duplicate of this bug. ***

*** Bug 410570 has been marked as a duplicate of this bug. ***

*** Bug 410509 has been marked as a duplicate of this bug. ***

FWIW.
That comment about that multiple jobs with the same id shouldn't exist.
I just decided to use the taskbar print-queue viewer (kde-print-queue) and selected "All Jobs".
At that point it crashed (but only it - plasma was OK).

But "lpstat -W completed" shows this - several multiple entries...

[parent]: lpstat -W completed
MFCJ4410DW-52           gml4410        8081408   Sun 01 Sep 2019 22:31:09 BST
MFCJ4410DW-51           gml4410        3419136   Sun 01 Sep 2019 22:28:35 BST
MFCJ4410DW-49           gml4410         667648   Sun 01 Sep 2019 22:20:14 BST
MFCJ4410DW-48           gml4410       12908544   Sun 01 Sep 2019 22:18:02 BST
MFCJ4410DW-47           gml4410         522240   Sun 01 Sep 2019 22:16:27 BST
MFCJ4410DW-46           gml4410         667648   Sun 01 Sep 2019 22:15:51 BST
MFCJ4410DW-45           gml4410         633856   Sun 01 Sep 2019 22:15:19 BST
MFCJ4410DW-44           gml4410        3618816   Sun 01 Sep 2019 22:13:56 BST
MFCJ4410DW-43           gml4410        3674112   Sun 01 Sep 2019 22:13:06 BST
MFCJ4410DW-40           gml4410        1386496   Sun 01 Sep 2019 21:48:04 BST
MFCJ4410DW-39           gml4410        1386496   Sun 01 Sep 2019 21:47:16 BST
MFCJ4410DW-38           gml4410        1199104   Sun 01 Sep 2019 21:44:59 BST
MFCJ4410DW-37           gml4410        1199104   Sun 01 Sep 2019 21:44:16 BST
MFCJ4410DW-36           gml4410        1832960   Sun 01 Sep 2019 21:42:29 BST
MFCJ4410DW-35           gml4410        5528576   Sun 01 Sep 2019 21:37:53 BST
MFCJ4410DW-33           gml4410        1867776   Sun 01 Sep 2019 21:32:38 BST
MFCJ4410DW-33           gml4410        1867776   Sun 01 Sep 2019 21:32:38 BST
MFCJ4410DW-31           gml4410         104448   Tue 13 Aug 2019 12:52:43 BST
MFCJ4410DW-31           gml4410         104448   Tue 13 Aug 2019 12:52:43 BST
MFCJ4410DW-30           gml4410         256000   Tue 06 Aug 2019 08:09:15 BST
MFCJ4410DW-30           gml4410         256000   Tue 06 Aug 2019 08:09:15 BST
MFCJ4410DW-29           gml4410        5049344   Tue 06 Aug 2019 08:08:49 BST
MFCJ4410DW-29           gml4410        5049344   Tue 06 Aug 2019 08:08:49 BST
MFCJ4410DW-28           gml4410         131072   Mon 05 Aug 2019 03:10:27 BST
MFCJ4410DW-28           gml4410         131072   Mon 05 Aug 2019 03:10:27 BST
MFCJ4410DW-27           gml4410         437248   Sat 03 Aug 2019 05:52:51 BST
MFCJ4410DW-27           gml4410         437248   Sat 03 Aug 2019 05:52:51 BST
MFCJ4410DW-26           gml4410         178176   Fri 02 Aug 2019 00:24:39 BST
MFCJ4410DW-26           gml4410         178176   Fri 02 Aug 2019 00:24:39 BST
MFCJ4410DW-25           gml4410         312320   Sat 15 Jun 2019 08:55:55 BST
MFCJ4410DW-25           gml4410         312320   Sat 15 Jun 2019 08:55:55 BST
MFCJ4410DW-24           gml4410        1629184   Sun 09 Jun 2019 18:51:18 BST
MFCJ4410DW-24           gml4410        1629184   Sun 09 Jun 2019 18:51:18 BST
MFCJ4410DW-23           gml4410         211968   Sun 02 Jun 2019 11:11:43 BST
MFCJ4410DW-23           gml4410         211968   Sun 02 Jun 2019 11:11:43 BST
MFCJ4410DW-22           gml4410         521216   Sun 02 Jun 2019 11:05:51 BST
MFCJ4410DW-22           gml4410         521216   Sun 02 Jun 2019 11:05:51 BST
MFCJ4410DW-21           gml4410          32768   Wed 15 May 2019 12:17:19 BST
MFCJ4410DW-21           gml4410          32768   Wed 15 May 2019 12:17:19 BST
MFCJ4410DW-20           gml4410         294912   Wed 15 May 2019 10:58:47 BST
MFCJ4410DW-20           gml4410         294912   Wed 15 May 2019 10:58:47 BST
MFCJ4410DW-19           gml4410         250880   Wed 15 May 2019 10:58:16 BST
MFCJ4410DW-19           gml4410         250880   Wed 15 May 2019 10:58:16 BST
MFCJ4410DW-18           gml4410          81920   Tue 14 May 2019 10:25:39 BST
MFCJ4410DW-18           gml4410          81920   Tue 14 May 2019 10:25:39 BST
MFCJ4410DW-14           gml4410         245760   Mon 13 May 2019 11:10:57 BST
MFCJ4410DW-14           gml4410         245760   Mon 13 May 2019 11:10:57 BST
MFCJ4410DW-14           gml4410         245760   Mon 13 May 2019 11:10:57 BST
MFCJ4410DW-13           gml4410         300032   Sat 11 May 2019 15:43:22 BST
MFCJ4410DW-13           gml4410         300032   Sat 11 May 2019 15:43:22 BST
MFCJ4410DW-13           gml4410         300032   Sat 11 May 2019 15:43:22 BST
MFCJ4410DW-12           gml4410        7809024   Sun 05 May 2019 01:04:45 BST
MFCJ4410DW-12           gml4410        7809024   Sun 05 May 2019 01:04:45 BST
MFCJ4410DW-12           gml4410        7809024   Sun 05 May 2019 01:04:45 BST
MFCJ4410DW-11           gml4410         137216   Wed 24 Apr 2019 18:56:44 BST
MFCJ4410DW-11           gml4410         137216   Wed 24 Apr 2019 18:56:44 BST
MFCJ4410DW-11           gml4410         137216   Wed 24 Apr 2019 18:56:44 BST
MFCJ4410DW-10           gml4410         137216   Wed 24 Apr 2019 18:53:34 BST
MFCJ4410DW-10           gml4410         137216   Wed 24 Apr 2019 18:53:34 BST
MFCJ4410DW-10           gml4410         137216   Wed 24 Apr 2019 18:53:34 BST
MFCJ4410DW-9            gml4410         325632   Sun 07 Apr 2019 01:16:05 BST
MFCJ4410DW-9            gml4410         325632   Sun 07 Apr 2019 01:16:05 BST
MFCJ4410DW-9            gml4410         325632   Sun 07 Apr 2019 01:16:05 BST
MFCJ4410DW-8            gml4410         601088   Sun 07 Apr 2019 01:14:51 BST
MFCJ4410DW-8            gml4410         601088   Sun 07 Apr 2019 01:14:51 BST
MFCJ4410DW-8            gml4410         601088   Sun 07 Apr 2019 01:14:51 BST
MFCJ4410DW-7            gml4410        4894720   Mon 25 Mar 2019 00:57:46 GMT
MFCJ4410DW-7            gml4410        4894720   Mon 25 Mar 2019 00:57:46 GMT
MFCJ4410DW-7            gml4410        4894720   Mon 25 Mar 2019 00:57:46 GMT
MFCJ4410DW-5            gml4410       10758144   Mon 25 Mar 2019 00:51:55 GMT
MFCJ4410DW-5            gml4410       10758144   Mon 25 Mar 2019 00:51:55 GMT
MFCJ4410DW-5            gml4410       10758144   Mon 25 Mar 2019 00:51:55 GMT
MFCJ4410DW-5            gml4410       10758144   Mon 25 Mar 2019 00:51:55 GMT
MFCJ4410DW-3            gml4410         294912   Thu 24 Jan 2019 00:01:01 GMT
MFCJ4410DW-3            gml4410         294912   Thu 24 Jan 2019 00:01:01 GMT
MFCJ4410DW-3            gml4410         294912   Thu 24 Jan 2019 00:01:01 GMT
MFCJ4410DW-3            gml4410         294912   Thu 24 Jan 2019 00:01:01 GMT
MFCJ4410DW-4            gml4410         301056   Wed 23 Jan 2019 20:39:40 GMT
MFCJ4410DW-4            gml4410         301056   Wed 23 Jan 2019 20:39:40 GMT
MFCJ4410DW-4            gml4410         301056   Wed 23 Jan 2019 20:39:40 GMT
MFCJ4410DW-4            gml4410         301056   Wed 23 Jan 2019 20:39:40 GMT
MFCJ4410DW-2            gml4410         302080   Wed 23 Jan 2019 12:18:43 GMT
MFCJ4410DW-2            gml4410         302080   Wed 23 Jan 2019 12:18:43 GMT
MFCJ4410DW-2            gml4410         302080   Wed 23 Jan 2019 12:18:43 GMT
MFCJ4410DW-2            gml4410         302080   Wed 23 Jan 2019 12:18:43 GMT

*** Bug 411153 has been marked as a duplicate of this bug. ***

Created attachment 123034 [details]
New crash information added by DrKonqi

plasmashell (5.16.5) using Qt 5.12.3

- What I was doing when the application crashed:
Usually after printing Plasma would crash but restarting from terminal using killall plasmashell followed by kstart plasmashell would work, now it just keeps on crashing, so it becomes unusable.
- Unusual behavior I noticed:
Whenever printing succeeded, plasma would crash but resume. If printing failed and job stayed in printing queue, plasma would crash and never resume. Manual restart of plasma would be necessary. This is no longer working.

-- Backtrace (Reduced):
#6  0x00007f6ae18e9c80 in JobModel::updateJob(int, KCupsJob const&) () at /usr/lib/x86_64-linux-gnu/libkcupslib.so
#7  0x00007f6ae18ebe68 in JobModel::insertJob(int, KCupsJob const&) () at /usr/lib/x86_64-linux-gnu/libkcupslib.so
#8  0x00007f6ae18ec46b in JobModel::getJobFinished(KCupsRequest*) () at /usr/lib/x86_64-linux-gnu/libkcupslib.so
#9  0x00007f6b32e203e2 in QObject::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007f6b3474d65c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

*** Bug 411870 has been marked as a duplicate of this bug. ***

*** Bug 412269 has been marked as a duplicate of this bug. ***

*** Bug 414058 has been marked as a duplicate of this bug. ***

*** Bug 414083 has been marked as a duplicate of this bug. ***

People that still have this crash. Can you please run 
lpstat -R

People that still have this crash and have the technical ability to test a patch, please test https://phabricator.kde.org/D25623

If we're quick enough we can get it into the 19.12 release of print-manager

I do experience the crash and 

$> lpstat -R
  0 printer-97            user          316416 Sun Sep 15 22:00:36 2019
  1 printer-97            user          316416 Sun Sep 15 22:00:36 2019
  2 printer-97            user          316416 Sun Sep 15 22:00:36 2019

Running on openSuse Thumbleweed on the latests updates. Experience this crash since a few days

(In reply to Meinhard Ritscher from comment #43)
> I do experience the crash and 
> 
> $> lpstat -R
>   0 printer-97            user          316416 Sun Sep 15 22:00:36 2019
>   1 printer-97            user          316416 Sun Sep 15 22:00:36 2019
>   2 printer-97            user          316416 Sun Sep 15 22:00:36 2019
> 
> Running on openSuse Thumbleweed on the latests updates. Experience this
> crash since a few days

Right, you have 3 print jobs with id 97, which is why this is crashing.

Do you remember what you did to end up with 3 print jobs with the same id? Was your printer off or on or it failed during printing or something?

Created attachment 124272 [details]
New crash information added by DrKonqi

plasmashell (5.17.3) using Qt 5.13.1

- What I was doing when the application crashed:
Logged in into KDE
- Unusual behavior I noticed:
Desktop appeard and went straight to a black screen and after a few seconds Dr. Konqi appeared.

-- Backtrace (Reduced):
#6  0x00007f0945c0b556 in JobModel::updateJob(int, KCupsJob const&) () at /usr/lib64/libkcupslib.so
#7  0x00007f0945c0d5f8 in JobModel::insertJob(int, KCupsJob const&) () at /usr/lib64/libkcupslib.so
#8  0x00007f0945c0dab9 in JobModel::getJobFinished(KCupsRequest*) () at /usr/lib64/libkcupslib.so
#9  0x00007f097747deea in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5
#10 0x00007f097800fc62 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5

(In reply to Albert Astals Cid from comment #44)
> Right, you have 3 print jobs with id 97, which is why this is crashing.
> 
> Do you remember what you did to end up with 3 print jobs with the same id?
> Was your printer off or on or it failed during printing or something?
Not really, no. I would assume the (network connected) printer was switched off. But I'm not certain.

Meanwhile I managed to remove the print jobs via lprm -U user x (iterating x from 0 to 2)

*** Bug 414652 has been marked as a duplicate of this bug. ***

Git commit c93f2f16c30d10fbd0f4bfb4c0bf0cec07a4c93b by Albert Astals Cid.
Committed on 02/12/2019 at 22:05.
Pushed by aacid into branch 'release/19.12'.

Fix crash when cups returns jobs with duplicate id

Summary:
For some reason my cups was giving me two withheld jobs with id 33 and two with id 40

That made the JobModel code crash, because it went like this

 * First job with id 33 found
 * insertRow with 0 called
 * Row 0 inserted
 * Job at row 0 updated (from inside insertRow)
 * Second job with id 33 found
 * The "oh i already have this job code triggers", updates the job, then takesRow 0 and inserts at row 1. QStandardItemModel doesn't like getting a row add at 1 inserted when empty
 * First job with id 40 found
 * insertRow with 2 called
 * Row 2 inserted, it fails, QStandardItemModel doesn't like getting a row add at 2 when empty
 * Job at row 2 updated (from iniside insertRow)
 * Crash because there's no row 2 in the model

Test Plan: Doesn't crash anymore with my weird cups list of pending jobs

Reviewers: dantti

Reviewed By: dantti

Subscribers: ngraham, marcelm, fvogt, broulik, nicolasfella, kmaterka, kde-utils-devel

Differential Revision: https://phabricator.kde.org/D25623

M  +21   -2    libkcups/JobModel.cpp

https://commits.kde.org/print-manager/c93f2f16c30d10fbd0f4bfb4c0bf0cec07a4c93b

Anyone knows what exactly happened on Cups side? Why there were jobs with duplicated Id? Maybe this should also be reported to Cups team?

>>> Anyone knows what exactly happened on Cups side?

I was wondering a similar thing. But rather what the "cups database" of past jobs looked like when it has multiple jobs with teh same id.
When I went looking the info was only in /var/spool/cups and the job number was taken from the filename, so what does this look like when there are multiple ids?

(In reply to Konrad Materka from comment #49)
> Maybe this should also be reported to Cups team?

Unless someone knows how to reproduce the duplicate ids issue i'm not sure it makes much sense, but feel free :) maybe they can think of a way this would happen

*** Bug 415239 has been marked as a duplicate of this bug. ***

*** Bug 415014 has been marked as a duplicate of this bug. ***

*** Bug 416215 has been marked as a duplicate of this bug. ***

*** Bug 416985 has been marked as a duplicate of this bug. ***

*** Bug 417601 has been marked as a duplicate of this bug. ***

Is there any workaround? I'm on 5.18.9? I was trying to use a wifi printer

A workaround is to cancel all jobs, or at least the duplicates(?).

See:

https://bugs.launchpad.net/ubuntu/+source/plasma-workspace/+bug/1770044/comments/82

*** Bug 417462 has been marked as a duplicate of this bug. ***

*** Bug 417537 has been marked as a duplicate of this bug. ***

*** Bug 418717 has been marked as a duplicate of this bug. ***

Created attachment 127232 [details]
New crash information added by DrKonqi

plasmashell (5.17.5) using Qt 5.13.2

- What I was doing when the application crashed:

I added a new HP printer earlier this day. Now, Plasma crashes at every login.
I created a new user with a brand new /home and Plasma crashes with that user as well.

-- Backtrace (Reduced):
#6  0x00007f809d42436a in JobModel::updateJob(int, KCupsJob const&) () from /lib64/libkcupslib.so
#7  0x00007f809d426418 in JobModel::insertJob(int, KCupsJob const&) () from /lib64/libkcupslib.so
#8  0x00007f809d4268d9 in JobModel::getJobFinished(KCupsRequest*) () from /lib64/libkcupslib.so
#9  0x00007f80c94b279a in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5
#10 0x00007f80c9f88ab6 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5

*** Bug 420576 has been marked as a duplicate of this bug. ***

*** Bug 424849 has been marked as a duplicate of this bug. ***

*** Bug 412639 has been marked as a duplicate of this bug. ***

Git commit 33a1a1dced51ab8d21bf766db45f45e14c448b99 by Albert Astals Cid.
Committed on 02/12/2019 at 22:04.
Pushed by aacid into branch 'arcpatch-D25623'.

Fix crash when cups returns jobs with duplicate id

Summary:
For some reason my cups was giving me two withheld jobs with id 33 and two with id 40

That made the JobModel code crash, because it went like this

 * First job with id 33 found
 * insertRow with 0 called
 * Row 0 inserted
 * Job at row 0 updated (from inside insertRow)
 * Second job with id 33 found
 * The "oh i already have this job code triggers", updates the job, then takesRow 0 and inserts at row 1. QStandardItemModel doesn't like getting a row add at 1 inserted when empty
 * First job with id 40 found
 * insertRow with 2 called
 * Row 2 inserted, it fails, QStandardItemModel doesn't like getting a row add at 2 when empty
 * Job at row 2 updated (from iniside insertRow)
 * Crash because there's no row 2 in the model

Test Plan: Doesn't crash anymore with my weird cups list of pending jobs

Reviewers: dantti

Reviewed By: dantti

Subscribers: ngraham, marcelm, fvogt, broulik, nicolasfella, kmaterka, kde-utils-devel

Differential Revision: https://phabricator.kde.org/D25623

M  +21   -2    libkcups/JobModel.cpp

https://invent.kde.org/utilities/print-manager/commit/33a1a1dced51ab8d21bf766db45f45e14c448b99