Bug 1825 - Application 'Dates' can not be launched with 20111207 build
Summary: Application 'Dates' can not be launched with 20111207 build
Status: VERIFIED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: graphics (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: ---
Assignee: Edwin Zhai
QA Contact:
URL:
Whiteboard: patch out. Dec16
Depends on:
Blocks:
 
Reported: 2011-12-12 19:32 UTC by Yi Zhao
Modified: 2012-01-12 23:09 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yi Zhao 2011-12-12 19:32:59 UTC
Tree/branch: poky/1.2_M1
Commit: b9d3a5224c7f76f273d5919a88b7460d35ad2574
Image location:
http://autobuilder.pokylinux.org/pub/nightly/20111207-2/machines/

When I click the 'Dates' icon on the desktop, there is no response. The application could not be launched.

This issue happens on qemuarm/mips, beagleboard and doesn't happen with Yocto 1.1.
Comment 1 Richard Purdie 2011-12-13 08:35:01 UTC
I think this may be related to 1711 since if dbus gets messed up (messagebus user not set on dbus files) then dbus might fail to load and dates is dependent on dbus being working. Could we check the permissions in the images and see if they're correct in some and not correct in others?
Comment 2 Saul Wold 2011-12-13 22:05:15 UTC
This may be related to the libical update
Comment 3 Edwin Zhai 2011-12-14 17:20:54 UTC
After revert the libical upgrade, dates can be launched. Libical provides 3 lib : libicalss.so, libicalvcal.so, and libical.so. Just taking place of libical.so by the one from old libical can fix it.

gdb showed some dates_view instance initialization failure and cause dates runs crazy from that time.
Comment 4 Edwin Zhai 2011-12-15 06:17:27 UTC
A big static function make debug difficult, and sometimes the bug disappear with gdb attached:(

Now suspicious function is icaltimezone_get_utc_offset @ dates_view.c:893(jana_ecal_utils_guess_location)

Continue on debugging...
Comment 5 Edwin Zhai 2011-12-16 00:12:52 UTC
hang in dates is as following:
dates_view_init ( as initialise function called by g_object_new )
=> dates_view_config_get_tzid
=> jana_ecal_utils_guess_location
---------- libical----------
=> icaltimezone_get_tznames
=> icaltimezone_load_builtin_timezone

where, a new mutex is added to support pthread in 0.47, but not unlocked properly in some case.

So the root cause is that this function was called without releasing mutex, then 2nd call in above tracing lead deadlock.

Patch already out, will push upstream also.

Hang point doesn't show any useful info. Huge inline code make debug very difficult, as the line no. reported by gdb is not reliable. I have to go through assembly to locate the right place. Next time, should remove inline function first to speed up debug...
Comment 7 Yi Zhao 2012-01-12 23:07:38 UTC
Verified with 1.2 M2 RC1 
'Dates' works now.

Tree/Branch: poky/1.2_M1
Poky Commit: b806f726b1db2cb605869c1022ef727c1110255b
Comment 8 Yi Zhao 2012-01-12 23:09:30 UTC
(In reply to comment #7)
> Verified with 1.2 M2 RC1 
> 'Dates' works now.
> 
> Tree/Branch: poky/1.2_M1
> Poky Commit: b806f726b1db2cb605869c1022ef727c1110255b

Sorry, I made a mistake with gitinfo. Should be:
Tree/branch: poky/1.2_M2
Commit: 0f4d99d207b224bb9ce23de00a48f795ae20b3a0