Calendar app crash

How can we get backtrace information from attached .crash file ?

I've installed some debug symbols and I can reproduce this very easily.

(gdb) cont
Continuing.
[Thread 0xa58b8450 (LWP 11518) exited]
[New Thread 0xa84ff450 (LWP 11559)]

Program received signal SIGSEGV, Segmentation fault.
findNode (akey=<optimized out>, this=0xe8c808) at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmap.h:287
287 /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmap.h: No such file or directory.
(gdb) bt full
#0 findNode (akey=<optimized out>, this=0xe8c808) at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmap.h:287
        lb = <optimized out>
        r = 0x19205c0
#1 remove (akey=<optimized out>, this=0xe3fde4) at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmap.h:894
No locals.
#2 RequestData::deleteLater (this=0xd38d50)
    at /build/buildd/qtorganizer5-eds-0.1.1+15.04.20150227/organizer/qorganizer-eds-requestdata.cpp:129
No locals.
#3 0xb0085cb2 in ?? () from /usr/lib/libecal-1.2.so.16
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Continuing.
[Thread 0xa484f450 (LWP 11839) exited]
[New Thread 0xa84ff450 (LWP 11916)]

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
44 ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
(gdb) bt full
#0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
No locals.
#1 0xb5d9ce5e in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
        _a1 = 0
        _a3tmp = 6
        _a1tmp = 0
        _a3 = 6
        _nametmp = 268
        _a2tmp = 11782
        _a2 = 11782
        _name = 268
        _sys_result = <optimized out>
        pd = 0xb6f05000
        pid = 0
        selftid = 11782
#2 0xb5d9db4e in __GI_abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {46539492, 5, 4, 3057934919, 0,
              3051753472, 15, 46539560, 5, 35675272, 46539336, 0, 46539336, 3, 16, 0, 46539476, 5, 54028648, 35906784, 0,
              49804248, 5, 39446680, 3200533276, 3200533144, 1, 1801810542, 5, 3069251344, 1801810542, 0}},
          sa_flags = -1243213824, sa_restorer = 0xbec44390}
        sigs = {__val = {32, 0 <repeats 31 times>}}
#3 0xb5dc5b9c in __libc_message (do_abort=<optimized out>, fmt=0xb5e43e50 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
        ap = {__ap = 0xbec443dc}
        fd = 2
        on_2 = <optimized out>
        list = <optimized out>
        nlist = <optimized out>
        cp = <optimized out>
        written = <optimized out>
#4 0xb5dc9a3a in malloc_printerr (action=1, str=0xb5e442a0 "malloc(): smallbin double linked list corrupted", ptr=<optimized out>)
    at malloc.c:4996
        buf = "02346b20"
        cp = <optimized out>
#5 0xb5dcb61e in _int_malloc (av=av@entry=0xb5e614e8 <main_arena>, bytes=bytes@entry=28) at malloc.c:3359
        p = <optimized out>
        fb = <optimized out>
        pp = <optimized out>
        nb = 32
        idx = <optimized out>
        bin = <optimized out>
        victim = <optimi...

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package qtorganizer5-eds - 0.1.1+15.04.20150309-0ubuntu1

---------------
qtorganizer5-eds (0.1.1+15.04.20150309-0ubuntu1) vivid; urgency=medium

  [ Renato Araujo Oliveira Filho ]
  * Fixed engine crash while destroying and requests still running. (LP:
    #1423185)
 -- CI Train Bot <email address hidden> Mon, 09 Mar 2015 13:48:42 +0000

ok to land this crasher fix

Seems to be gone on 0.4.623 (updated april 10th 2015)

Do I understand this bug correctly? It seems to have tasks for the image (qtorganizer5-eds) which are fixed in the 'ww13-ota' milestone. It then seems to be marked 'in progress' for the app itself.

I would conclude that this will still be broken on a test device running the OTA image and the calendar app in the store?

FWIW, have such a handset, and this bug reproduced easily if I selected a day prior to 'today' in the year view. It did not seem to reproduce with future dates.

As I understood, this was fixed. You may be experiencing a new bug, but I certainly can't reproduce it here.

Agree with Alan, it's same behavior but different root cause and i think it's related to heavy work for qml object creation during tab transition.

bt as following:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f595d15c033 in QtSharedPointer::ExternalRefCountData::getAndRef(QObject const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(gdb) bt
#0 0x00007f595d15c033 in QtSharedPointer::ExternalRefCountData::getAndRef(QObject const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1 0x00007f595e92e80c in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#2 0x00007f595e92a36e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#3 0x00007f595e92a813 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#4 0x00007f595e92af9d in QQmlIncubationController::incubateFor(int) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#5 0x00007f595ee8bdd8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6 0x00007f595d3330e3 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7 0x00007f595dfd516c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8 0x00007f595dfda41e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9 0x00007f595d30381b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5

Every time tab transition from "year" to "monthly" .
1.Qt.ResolveUrl("YearView") will create new qml object since YearView has been unloaded (Loader.source = "",garbage collected) when it swipes away.
2.EventlistModel will reload events due to startPeriodTime was changed(current Date/ current Month/ previous Month / Next Month), 4 times for Qt.createQmlObject for Timer to trigger event loading and destroy itself when event was loaded(garbage collected)

I think this issue exists in other tabs transitions and the reason why it's easier to reproduce from "year" to "monthly" lies in the complexity qml component creation in year view.
My testing device is on the way. I will test it with my patch to check if this issue is still existing and give feedback ASAP.