Access to freed memory in timezone handling causes crash
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Libical |
Unknown
|
Unknown
|
|||
libical (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
When I start evolution and then click the button at the bottom of the left pane to switch to the calendar, evolution crashes. If I right-click on the evolution icon in Unity and click on "Calendar" to go straight to the calendar, evolution also crashes. This reproduced on my machine 31 out of 32 attempts, and produces a variety of backtraces (attached, summary below). For privacy reasons, I regret that I am not willing to post the core dumps.
I have searched through previous bugs and found a number of bugs that I believe are the same problem. For example: bug 900534, bug 951201, bug 952368, bug 954220, bug 900534.
Although I am still on Oneiric, looking at the existing bugs the same crash appears to also be present in Precise.
The problem seems to be that calendar items have a builtin_timezone field set that is not initialised. I have not yet managed to figure out where it is supposed to be initialised. For example:
#5 0x00007f2f479925a6 in e_calendar_
cells_x=7, start_weekday=3, month=2, year=2012, col=0, row=0,
cr=
height=
1485 today_tm = (*calitem-
(gdb) p ((GnomeCalendar *)(((ECalShellView *)calitem-
$49 = (icaltimezone *) 0x2000000020
I've found this in modules/
/* XXX Pre-load all built-in timezones in libical.
*
* Built-in time zones in libical 0.43 are loaded on demand,
* but not in a thread-safe manner, resulting in a race when
* multiple threads call icaltimezone_
* on the same time zone. Until built-in time zone loading
* in libical is made thread-safe, work around the issue by
* loading all built-in time zones now, so libical's internal
* time zone array will be fully populated before any threads
* are spawned.
*/
As this bug is so difficult to reproduce and I can reproduce it reliably at the moment, I will try and get to the bottom of this. Any help would be appreciated.
Here are my 31 crash stack frames:
#0 0x00007f1c0ca611ad in icaltimezone_
#0 0x00007f4a000007e1 in ?? ()
#0 0x00007fb420a511ad in icaltimezone_
#0 0x00007fbc08d94ac7 in icaltimezone_
#0 0x00007fc23a37eac7 in icaltimezone_
#0 0x00007feb4a4401ad in icaltimezone_
#0 __strcmp_sse42 () at ../sysdeps/
#0 icalarray_free (array=
#0 icalcomponent_
#0 icalcomponent_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 icaltimezone_
#0 pvl_head (L=0x42555347e0
Backtraces of all of these are attached.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: evolution 3.2.2-0ubuntu0.1
ProcVersionSign
Uname: Linux 3.0.0-16-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Fri Mar 16 10:25:02 2012
ProcEnviron:
LC_COLLATE=C
PATH=(custom, user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: evolution
UpgradeStatus: Upgraded to oneiric on 2011-09-03 (194 days ago)
This is not a trivial bug. It looks like a memory corruption issue.
What I have found so far:
An important data structure is an ECalShellView *cal_shell_view. The specific instance I care about (I suspect there may be only one) is as it appears in the first argument when e-cal-shell- view-private. c:e_cal_ shell_view_ private_ constructed is called.
The bug is being triggered some time after ((GnomeCalendar *)cal_shell_ view->priv- >cal_shell_ content- >priv-> calendar) ->priv- >model- >priv-> zone->builtin_ timezone is corrupted.
Setting a watch to detect the point when it is corrupted gives me the example backtrace attached. I can't think why malloc would overwrite this memory area unless it is treating that memory as freed. I have tried setting breakpoints to catch something freeing view->priv- >cal_shell_ content- >priv-> calendar) ->priv- >model- >priv-> zone but haven't had any success there.
((GnomeCalendar *)cal_shell_
Any ideas?