This is what I think:

In fact, such feature will help us to not have that much duplicates of "common crashes" on the same account.

The problem is how to implement it: having a "local backtrace database" will mean implement a "exact backtrace matching" logic, and a database management + an util/tool/daemon to clear this database after some time.
This could also fail as two backtrace with slighty different details may still refer to the same crash.

A simple approach I was thinking about could be: use the current duplicates page (which already searchs for really-similar backtraces in the reports) and add some kind of mark (an icon?) to show that bug was reported by the same user. So would check it and it would be probably really related, the same. 

It is not a full solution, but a little help in order to "implement" the whole "fix"/idea.

- What do you think about it ?

(My idea is simple to implement, in fact, I already did it in my local copy)

Regards

(In reply to comment #1)
> The problem is how to implement it: having a "local backtrace database" will
> mean implement a "exact backtrace matching" logic, and a database management +
> an util/tool/daemon to clear this database after some time.
> This could also fail as two backtrace with slighty different details may still
> refer to the same crash.
>
We can default to storing the crash files in /tmp/kde-$USER.
Many distros have policy to clean the /tmp/ folder on reboots. Others (like Debian) don't do a complete clean. Instread they look for the atime of the files. And also there are apps like tmpreaper for this purpose.
So, Dr. Konqi could store the kcrash files in /tmp and not worry about cleaning it up. 

Now, the matching part. Yes, it cannot be a 100% but sure can do better.
Let's take a kcrash sample:

Application: KNotify (knotify4), signal: Aborted
[Current thread is 1 (Thread 0xb6412920 (LWP 5059))]

Thread 144 (Thread 0xb2fc7b90 (LWP 5344)):
#0  0xb7f5e424 in __kernel_vsyscall ()
#1  0xb661a292 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:179
#2  0xb6b5e8b4 in __pthread_cond_timedwait (cond=0x8a0a5e0, mutex=0x8a0a5c8, abstime=0xb2fc736c) at forward.c:152
#3  0xb40ff8c3 in metronom_sync_loop (this=0x8a0a580) at metronom.c:870
#4  0xb66164b5 in start_thread (arg=0xb2fc7b90) at pthread_create.c:300
#5  0xb6b4fa5e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Thread 143 (Thread 0xb2718b90 (LWP 5345)):
#0  0xb66e3fec in *__GI_clock_gettime (clock_id=-1234272268, tp=0xb27181b8) at ../sysdeps/unix/clock_gettime.c:100
#1  0xb77ec51b in QTimerInfoList::getTime (this=0x8a0c034, t=...) at kernel/qeventdispatcher_unix.cpp:339
#2  0xb77ec6e1 in QTimerInfoList::updateCurrentTime (this=0x8a0c034) at kernel/qeventdispatcher_unix.cpp:297
#3  0xb77ee41c in QTimerInfoList::timerWait (this=0x8a0c034, tm=...) at kernel/qeventdispatcher_unix.cpp:420
#4  0xb77ee620 in QEventDispatcherUNIX::processEvents (this=0x894a3c8, flags=...) at kernel/qeventdispatcher_unix.cpp:891
#5  0xb77be01a in QEventLoop::processEvents (this=0xb27182f0, flags=...) at kernel/qeventloop.cpp:149
#6  0xb77be462 in QEventLoop::exec (this=0xb27182f0, flags=...) at kernel/qeventloop.cpp:201
#7  0xb76cb2c9 in QThread::exec (this=0x8987d60) at thread/qthread.cpp:487
#8  0xb414d2ba in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so
#9  0xb76ce582 in QThreadPrivate::start (arg=0x8987d60) at thread/qthread_unix.cpp:188
#10 0xb66164b5 in start_thread (arg=0xb2718b90) at pthread_create.c:300
#11 0xb6b4fa5e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

After passing it through the sanitizer, it could be represented as:

in *__GI_clock_gettime (clock_id=, tp=) at ../sysdeps/unix/clock_gettime.c:100
in QTimerInfoList::getTime (this=, t=) at kernel/qeventdispatcher_unix.cpp:339
 in QTimerInfoList::updateCurrentTime (this=) at kernel/qeventdispatcher_unix.cpp:297
 in QTimerInfoList::timerWait (this=, tm=) at kernel/qeventdispatcher_unix.cpp:420
in QEventDispatcherUNIX::processEvents (this=, flags=) at kernel/qeventdispatcher_unix.cpp:891
 in QEventLoop::processEvents (this=, flags=) at kernel/qeventloop.cpp:149
in QEventLoop::exec (this=, flags=) at kernel/qeventloop.cpp:201
in QThread::exec (this=) at thread/qthread.cpp:487
in ?? () from /usr/lib/qt4/plugins/phonon_backend/phonon_xine.so
in QThreadPrivate::start (arg=) at thread/qthread_unix.cpp:188
in start_thread (arg=) at pthread_create.c:300
in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

This would be the sanitized output which will be used to find a probable match.
So we could take sanitized outputs from the current and previous crash and see if their sanitized lines match.
If yes, we mark it as "Probably already reported" and let the user do a second check before clicking on Submit.

In most common application crashes, half of the backtrace lines would be common, related to kdelibs et cetera.

I think once you have a parser, then we can think of a number like when to mark the crash report as "Probably duplicate", after looking at what percentage of the backtrace is usually common.

> A simple approach I was thinking about could be: use the current duplicates
> page (which already searchs for really-similar backtraces in the reports) and
> add some kind of mark (an icon?) to show that bug was reported by the same
> user. So would check it and it would be probably really related, the same. 
>
That's a good one and will make results much better.
The only catch is that not all users are always online. I too sometimes just save the crash file and report it later. For this use case (which I think a very low number of users fall under), we could use the first point that I've explained.
  
> (My idea is simple to implement, in fact, I already did it in my local copy)
Thanks. Dr.Konqi is something very nice and am sure will help improve KDE overall.

If we go with local kcrash lookup for matching, we also might want to limit to N-2 local kcrashes only.
A user could have hundreds of kcrash files and we might not want to run through them all.