Bug 159532 - Crashes on startup while reading large ToDo attachements
Summary: Crashes on startup while reading large ToDo attachements
Status: RESOLVED DUPLICATE of bug 159247
Alias: None
Product: korganizer
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 165845 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-03-18 18:10 UTC by Michal Sojka
Modified: 2008-07-09 20:19 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Sojka 2008-03-18 18:10:12 UTC
Version:           3.5.9 (using 3.5.9, Debian Package 4:3.5.9.dfsg.1-2 (lenny/sid))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.24.2-rt1-loop

I have my calendar on the remote server accessed through sftp. I started using the new feature of 3.5.9 to create ToDo items from emails. After addind such a todo, I'm no longer able start KOrganizer and korgac.

I was able to recover from this by disabling the resource in .kde/share/config/kresources/calendar/stdrc, deleting the problematic record manually from .ics file and use the modified .ics file locally. If I copy the .ics file which works locally to the remote server, I still get the same crash, but that's probably some caching issue. Is it possible?

The backtrace of the crash is:

Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb5ff36c0 (LWP 29275)]
[KCrash handler]
#6  0xb7b1b2f3 in strlen () from /lib/i686/cmov/libc.so.6
#7  0xb7121d36 in QString::fromUtf8 (
    utf8=0xb4d9e008 <Address 0xb4d9e008 out of bounds>, len=-1)
    at tools/qstring.cpp:5804
#8  0xb79e6f71 in Attachment (this=0x892ba50, 
    base64=0xb4d9e008 <Address 0xb4d9e008 out of bounds>, mime=@0xb72b7580)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/attachment.cpp:47
#9  0xb7a0fab0 in KCal::ICalFormatImpl::readAttachment (this=0x8740738, 
    attach=0x840dd50)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/icalformatimpl.cpp:1246
#10 0xb7a15f43 in KCal::ICalFormatImpl::readIncidence (this=0x8740738, 
    parent=0x86c44b0, tz=0x0, incidence=0x892b6f0)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/icalformatimpl.cpp:1409
#11 0xb7a1683e in KCal::ICalFormatImpl::readTodo (this=0x8740738, 
    vtodo=0x86c44b0)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/icalformatimpl.cpp:899
#12 0xb7a16f5f in KCal::ICalFormatImpl::populate (this=0x8740738, 
    cal=0x8268e60, calendar=0x83e3238)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/icalformatimpl.cpp:2024
#13 0xb7a0c13a in KCal::ICalFormat::fromRawString (this=0xbff3665c, 
    cal=0x8268e60, text=@0xbff365ec)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/icalformat.cpp:184
#14 0xb7a0c777 in KCal::ICalFormat::load (this=0xbff3665c, 
    calendar=0x8268e60, fileName=@0xbff366c0)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/icalformat.cpp:98
#15 0xb7a37026 in KCal::FileStorage::load (this=0xbff366b4)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/filestorage.cpp:97
#16 0xb79fe434 in KCal::CalendarLocal::load (this=0x8268e60, 
    fileName=@0xbff36704, format=0x0)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/calendarlocal.cpp:66
#17 0xb7a4116c in KCal::ResourceCached::loadCache (this=0x8268e28)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/resourcecached.cpp:287
#18 0xb55f7bfe in KCal::ResourceRemote::doLoad (this=0x8268e28)
    at /tmp/buildd/kdepim-3.5.9/./kresources/remote/resourceremote.cpp:183
#19 0xb7a399bb in KCal::ResourceCalendar::load (this=0x8268e28)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/resourcecalendar.cpp:123
#20 0xb7a482ae in KCal::CalendarResources::load (this=0x82cc008)
    at /tmp/buildd/kdepim-3.5.9/./libkcal/calendarresources.cpp:143
#21 0x080522dc in KOrganizerApp::processCalendar (this=0xbff37098, 
    url=@0xbff369e0) at /tmp/buildd/kdepim-3.5.9/./korganizer/koapp.cpp:143
#22 0x080527e4 in KOrganizerApp::newInstance (this=0xbff37098)
    at /tmp/buildd/kdepim-3.5.9/./korganizer/koapp.cpp:89
#23 0xb7455166 in KUniqueApplication::processDelayed (this=0xbff37098)
    at /build/buildd/kdelibs-3.5.9.dfsg.1/./kdecore/kuniqueapplication.cpp:444
#24 0xb748fd33 in KUniqueApplication::qt_invoke (this=0xbff37098, _id=19, 
    _o=0xbff36bb4) at ./kuniqueapplication.moc:86
#25 0x08051faf in KOrganizerApp::qt_invoke (this=0xbff37098, _id=19, 
    _o=0xbff36bb4) at ./koapp.moc:77
#26 0xb6e5900d in QObject::activate_signal (this=0x809a0c0, clist=0x8099db8, 
    o=0xbff36bb4) at kernel/qobject.cpp:2359
#27 0xb71831be in QSignal::signal (this=0x809a0c0, t0=@0x809a0e8)
    at .moc/release-shared-mt/moc_qsignal.cpp:100
#28 0xb6e74967 in QSignal::activate (this=0x809a0c0) at kernel/qsignal.cpp:215
#29 0xb6e7ba33 in QSingleShotTimer::event (this=0x809a098)
    at kernel/qtimer.cpp:289
#30 0xb6dfb1ca in QApplication::internalNotify (this=0xbff37098, 
    receiver=0x809a098, e=0xbff36eb4) at kernel/qapplication.cpp:2638
#31 0xb6dfbfb6 in QApplication::notify (this=0xbff37098, receiver=0x809a098, 
    e=0xbff36eb4) at kernel/qapplication.cpp:2361
#32 0xb74abec2 in KApplication::notify (this=0xbff37098, receiver=0x809a098, 
    event=0xbff36eb4)
    at /build/buildd/kdelibs-3.5.9.dfsg.1/./kdecore/kapplication.cpp:550
#33 0xb6df05ae in QEventLoop::activateTimers (this=0x808ba60)
    at kernel/qapplication.h:523
#34 0xb6daa388 in QEventLoop::processEvents (this=0x808ba60, flags=4)
    at kernel/qeventloop_x11.cpp:392
#35 0xb6e11bc0 in QEventLoop::enterLoop (this=0x808ba60)
    at kernel/qeventloop.cpp:201
#36 0xb6e11a56 in QEventLoop::exec (this=0x808ba60)
    at kernel/qeventloop.cpp:148
#37 0xb6dfad3f in QApplication::exec (this=0xbff37098)
    at kernel/qapplication.cpp:2761
#38 0x08050760 in main (argc=)
    at /tmp/buildd/kdepim-3.5.9/./korganizer/main.cpp:58
#39 0xb7abb456 in __libc_start_main () from /lib/i686/cmov/libc.so.6
#40 0x08050571 in _start ()
Comment 1 Allen Winter 2008-03-18 19:42:59 UTC
I have been trying to fix this bug for the past couple days.
In-line attachments work.. sometimes.. then they don't.

My current best-guess is a problem somewhere in the 3rd-party
libical library.. or how we build it (maybe it isn't thread safe?)

Till: any ideas?
Comment 2 Till Adam 2008-03-18 19:51:25 UTC
Valgrind any help?
Comment 3 Allen Winter 2008-03-18 19:59:27 UTC
Not anymore than a bt.

Here's a valgrind output:
==21236== Invalid read of size 1
==21236==    at 0x4006278: strlen (mc_replace_strmem.c:246)
==21236==    by 0x4092657: qstrdup(char const*) (qbytearray.cpp:104)
==21236==    by 0x55D7BFE: KCal::Attachment::setData(char const*) (attachment.cpp:156)
==21236==    by 0x55D7E7E: KCal::Attachment::Attachment(char const*, QString const&) (attachment.cpp:95)
==21236==    by 0x5610A1D: KCal::ICalFormatImpl::readAttachment(icalproperty_impl*) (icalformat_p.cpp:1351)
==21236==    by 0x5612813: KCal::ICalFormatImpl::readIncidence(icalcomponent_impl*, KCal::Incidence*, KCal::ICalTimeZones*) (icalformat_p.cpp:1599)
==21236==    by 0x5613433: KCal::ICalFormatImpl::readTodo(icalcomponent_impl*, KCal::ICalTimeZones*) (icalformat_p.cpp:1013)
==21236==    by 0x5613D78: KCal::ICalFormatImpl::populate(KCal::Calendar*, icalcomponent_impl*) (icalformat_p.cpp:2357)
==21236==    by 0x560CC4E: KCal::ICalFormat::fromRawString(KCal::Calendar*, QByteArray const&) (icalformat.cpp:188)
==21236==    by 0x560D3A9: KCal::ICalFormat::load(KCal::Calendar*, QString const&) (icalformat.cpp:106)
==21236==    by 0x5630DDE: KCal::FileStorage::load() (filestorage.cpp:119)
==21236==    by 0x55FBC9A: KCal::CalendarLocal::load(QString const&, KCal::CalFormat*) (calendarlocal.cpp:105)
==21236==  Address 0xAC66028 is not stack'd, malloc'd or (recently) free'd
==21236==

etc.
Comment 4 Allen Winter 2008-07-06 13:53:47 UTC
*** Bug 165845 has been marked as a duplicate of this bug. ***
Comment 5 Thomas McGuire 2008-07-09 20:19:56 UTC

*** This bug has been marked as a duplicate of 159247 ***