| Summary: | CalDAV option KOrganizer causes KOrganizer to crash | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Kris <krisgamrat> |
| Component: | tdepim | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | bda, bugwatch, darrella, krisgamrat, slavek.banko, trinity |
| Priority: | P5 | ||
| Version: | 3.5.13 [Trinity] | ||
| Hardware: | All | ||
| OS: | Debian Squeeze | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | KOrganizer/Kontact | |
| Attachments: | KCrash backtrash | ||
|
Description
Kris
2011-11-16 15:40:56 CST
For Google Calendar users, a workaround is to log in from your web browser, go to your Calendar settings, and copy the XML Private Link. In KOrganizer,instead of CalDAV, choose "Calendar in Remote File" and paste in your link there. Can you post a backtrace for the crash? What's a backtrace, and where do I find it? I should have explained this more clearly, sorry about that. A backtrace is essentially a snapshot of the code paths that caused the crash to occur. It is extremely helpful to developers when they attempt to fix the cause of a crash, as it lets them know why the code ended up in a spot where it could crash. You need to have the debugging packages installed, in your case kdepim-trinity-dbg, for the backtrace to be of any use to use. To grab it, simply wait for the DrKonqui crash dialog to pop up, then click on the Backtrace tab. Save the backtrace using the button provided, and attach it to this bug report. Created attachment 130 [details]
KCrash backtrash
Here is the backtrace
Thanks! I will take a look at this bug once GIT reopens for business. This is very unusual; the caldav resource appears to be crashing on startup while attempting to initialize the logfile. The actual crash is due to an assert in tdelibs as far as I can tell. Is there any way that you can install the nightly builds on a testing box and try to reproduce the bug there? I will see what I can do on this end as well. I should mention that I can reproduce the bug here from GIT as well. Fixed in GIT hashes 9a38884 and 9e6ec3a. Thanks for reporting! (In reply to comment #7) <snip> > Is there any way that you can install the nightly builds on a testing box and > try to reproduce the bug there? I will see what I can do on this end as well. I cannot install nightlies on any box. I only have one that is working, and it currently (still) lacks a hard disk, so requires a very small flash drive to boot. As such, I will only run stable until I have funds to do some repairs. (Odpověď na komentář #10)
> (In reply to comment #7)
> <snip>
> > Is there any way that you can install the nightly builds on a testing box and
> > try to reproduce the bug there? I will see what I can do on this end as well.
>
> I cannot install nightlies on any box. I only have one that is working, and it
> currently (still) lacks a hard disk, so requires a very small flash drive to
> boot. As such, I will only run stable until I have funds to do some repairs.
I applied the patches and packages included into prepared updates. So you can try out packages with stable 3.5.13.
(In reply to comment #11) > (Odpověď na komentář #10) > > (In reply to comment #7) > > <snip> > > > Is there any way that you can install the nightly builds on a testing box and > > > try to reproduce the bug there? I will see what I can do on this end as well. > > > > I cannot install nightlies on any box. I only have one that is working, and it > > currently (still) lacks a hard disk, so requires a very small flash drive to > > boot. As such, I will only run stable until I have funds to do some repairs. > > I applied the patches and packages included into prepared updates. So you can > try out packages with stable 3.5.13. Thanks. Will the updates be available with a normal dist-upgrade in Debian, or are your updates available in another repo? They haven't shown up yet, though I don't know how long it takes to rebuild and redistribute to the mirrors. (no rush, not really that important for me personally, it would just be nice to update my calendar without opening my browser :-) ) (Odpověď na komentář #12) > Thanks. Will the updates be available with a normal dist-upgrade in Debian, or > are your updates available in another repo? They haven't shown up yet, though I > don't know how long it takes to rebuild and redistribute to the mirrors. (no > rush, not really that important for me personally, it would just be nice to > update my calendar without opening my browser :-) ) See http://trinity-users.pearsoncomputing.net/?0::2776 There already contain a few other patches. And some more still to follow - such as an update to the patch for bug #690. Was this fix included in the latest stable release, because I'm seeing the errant behavior there? Here are the versions I have installed: TDE: 3.5.13.1 Kontact: 1.2.9 (enterprise35 ...) Korganizer: 3.5.9 Kaddressbook: 3.5.11 (Odpověď na komentář #14)
> Was this fix included in the latest stable release, because I'm seeing the
> errant behavior there?
>
> Here are the versions I have installed:
> TDE: 3.5.13.1
> Kontact: 1.2.9 (enterprise35 ...)
> Korganizer: 3.5.9
> Kaddressbook: 3.5.11
Yes, both here mentioned patches are applied in the current stable release (3.5.13.1).
(In reply to comment #15) > (Odpověď na komentář #14) > > Was this fix included in the latest stable release, because I'm seeing the > > errant behavior there? > > > > Here are the versions I have installed: > > TDE: 3.5.13.1 > > Kontact: 1.2.9 (enterprise35 ...) > > Korganizer: 3.5.9 > > Kaddressbook: 3.5.11 > > Yes, both here mentioned patches are applied in the current stable release > (3.5.13.1). When I was on the 3.5.13.1 repo (before it was pushed as an official release), Caldav no longer crashed Kontact/Korganizer, though I was unable to get Google's Caldav to work (with neither of the instructions they provided, I think one was iCal and one was something else). |