Finding duplicates

Welcome to Bugsquad's Dark Arts

Crasher bugs

If the bug has a (good) stack trace, you can find duplicates by clicking the "Trace" link. That leads, e.g. to https://bugzilla.gnome.org/page.cgi?id=trace.html&trace_id=217317 which will try to find duplicates for you. The duplicate-finder is not perfect, always compare the stacktraces before marking a bug as a duplicate (see below).

If one of the duplicates found has a function name in brackets, this is the master copy that you should mark bugs duplicates of. For example:

 Panel crash [gdk_events_apply_filters] 

means it is collecting duplicates of panel crashes with a trace that fairly unqiuely contains the gdk_events_apply_filters function.

How to compare stack traces manually

A stack trace is a list of function calls that were performed and lead up to an application crash. If you read them from top to bottom you read them in reversed chronological order, i.e. backwards.
To compare traces, consider the topmost thread of each trace. A trace of a thread starts with

#0 0x...
#1 0x...

Ignore the rubbish above the first thread. In these threads, consider the topmost function names. The important functions are the few ones just before the first signal handler. Signal/crash handlers are denoted by green text colouring and are usually named like

<signal handler called>, g_log() ....

Now, look for the bottommost signal handler call (marked by green text) within the thread . Then compare the following lines of both traces. If the first 5 or more function names match then it is most likely a duplicate. Go and mark the bug with less information/comments the duplicate of the other.

If some or all of them miss function names, i.e. you see double question marks ??, you need to ask for a better stack trace or even one with debugging symbols (or supply one yourself). Point the reporter to GettingTraces .

Example 1

GNOME Bug 302338

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb748248b in __waitpid_nocancel ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7f9dd97 in libgnomeui_module_info_get ()
   from /usr/lib/libgnomeui-2.so.0
#3  <signal handler called>
#4  0xffffe410 in __kernel_vsyscall ()
#5  0xb72f6175 in raise () from /lib/tls/i686/cmov/libc.so.6
#6  0xb72f77d8 in abort () from /lib/tls/i686/cmov/libc.so.6
#7  0xbfffe3a0 in ?? ()
#8  0x00000000 in ?? ()
#9  0x00000020 in ?? ()
#10 0x00000000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000000 in ?? ()
#13 0x00000000 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()

Examing bottom up, the first signal handler is in frame #3. The important functions are below it. Anyways, kernel_vsyscall , raise() and abort() should always be ignored. As you can see, we are clearly missing almost all frames, there are only useless question marks. Hence Comment #1 asks for a good stack trace (that is one of the ../StockResponses !).

"Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so."

Example 2

GNOME Bug 611997

#0  __libc_waitpid
at ../sysdeps/unix/sysv/linux/waitpid.c line 41
#1 IA__g_spawn_sync
at /tmp/buildd/glib2.0-2.22.4/glib/gspawn.c line 386
#2 IA__g_spawn_command_line_sync
at /tmp/buildd/glib2.0-2.22.4/glib/gspawn.c line 700
#3 ??
from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so
#4 <signal handler called>
#5 boxed_nodes_cmp
at /tmp/buildd/glib2.0-2.22.4/gobject/gboxed.c line 79
#6 g_bsearch_array_lookup_fuzzy
at /tmp/buildd/glib2.0-2.22.4/glib/gbsearcharray.h line 163
#7 boxed_proxy_collect_value
at /tmp/buildd/glib2.0-2.22.4/gobject/gboxed.c line 360
#8 IA__g_signal_emit_valist
at /tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c line 2955
#9 IA__g_signal_emit
at /tmp/buildd/glib2.0-2.22.4/gobject/gsignal.c line 3037
...

The trace is good and does not lack any function names. Good requisites to take a look at the potential stacktrace duplicates by clicking on "Trace 220831" in that report and examining the results.

Traces with a similar stack:
In Evolution:
    * Trace 220491 (Quality: 4.9) on Bug 609386:RESOLVED DUPLICATE of bug 599345
    * Trace 219997 (Quality: 4.8) on Bug 606608:RESOLVED DUPLICATE of bug 599345
    * Trace 220164 (Quality: 4.4) on Bug 607596:RESOLVED DUPLICATE of bug 599345
    * Trace 219039 (Quality: 4.1) on Bug 601639:RESOLVED DUPLICATE of bug 599345

Looks like we have found some duplicate candidates ("candidates" because it is a similar stack, but not an identical stack). Click the link to Bug #599345. Open the trace of original Bug #599345 in a separate browser tab/window and start comparing downwards. As you can see, quite some names do match and we have very likely found a duplicate.

No surprise, the original report is marked as a DUPLICATE.

Other bugs

You need to go to the Bugzilla Query Page, select the correct product, ensure all bug statuses are selected (from UNCONFIRMED to CLOSED) and then type keywords into the Description field. You need to find a word that describes this bug fairly specifically and use it to find other bugs that may already be in the database.

You can also ask on IRC (#bugs) if anyone has seen a certain bug before; if it's been reported before, someone may know where duplicates are filed.