[KDE/Mac] Fwd: [MacPorts] #44282: patch to enable ktimetracker in kdepim4

Mon Jul 28 11:00:56 UTC 2014

I've been trying to get ktimetracker to build (and run...) on OS X. The initial building block for which I submitted a patch is an X11 dependency; ktimetracker uses something from xscreensaver for time keeping. That's supposed to be optional, and indeed with my patch it builds and launches.

The next obstacle was something about the ktimetracker kpart not being loaded. That seems to be something related to the compiler; when I changed

{{{
        m_part = dynamic_cast<ktimetrackerpart*>( factory->create<KParts::ReadWritePart>( this ) );
}}}

into

{{{
        static KParts::ReadWritePart *rwp = factory->create<KParts::ReadWritePart>( this );
        static ktimetrackerpart *mp = dynamic_cast<ktimetrackerpart*>( rwp );
        m_part = dynamic_cast<ktimetrackerpart*>( rwp );
}}}

and compiled with gcc-4.8 (from MacPorts), m_part does get a non-NULL value and the app launches correctly. (Curiously, rwp and mp both evaluate to <ktimetrackerpart*> when printed with `kError() <<` so I'm not sure the dynamic_cast is actually required.)

App launching correctly here implies that there is no database (.kde/share/apps/ktimetracker/ktimetracker.ics) available, and you don't get to see the times in newly created tasks (except through the "modify times" editor). When you reopen the app with a database in place, it deadlocks, and lldb shows the following backtrace (gdb and ggdb both fail):

{{{
(lldb) bt all
* thread #1: tid = 0x2d03, 0x00007fff85ef8dc2 libSystem.B.dylib`semaphore_wait_signal_trap + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff85ef8dc2 libSystem.B.dylib`semaphore_wait_signal_trap + 10
    frame #1: 0x00007fff85efe40d libSystem.B.dylib`pthread_mutex_lock + 469
    frame #2: 0x00000001032b0214 libical.0.dylib`icaltimezone_load_builtin_timezone + 58 at icaltimezone.c:1800
    frame #3: 0x00000001032af2d5 libical.0.dylib`icaltimezone_get_component + 38 at icaltimezone.c:1251
    frame #4: 0x000000010329a3f5 libical.0.dylib`icalcomponent_remove_component + 156 at icalcomponent.c:597
    frame #5: 0x00000001032b0385 libical.0.dylib`icaltimezone_load_builtin_timezone + 427 at icaltimezone.c:1863
    frame #6: 0x00000001032af20c libical.0.dylib`icaltimezone_get_tzid + 38 at icaltimezone.c:1183
    frame #7: 0x00000001001e1063 libkcalcore.4.dylib`KCalCore::ICalTimeZoneSource::icalTzidPrefix() + 51 at icaltimezones.cpp:1439
    frame #8: 0x00000001001e1beb libkcalcore.4.dylib`KCalCore::ICalTimeZoneSource::parse(icalcomponent_impl*) + 859 at icaltimezones.cpp:970
    frame #9: 0x00000001001e176f libkcalcore.4.dylib`KCalCore::ICalTimeZoneSource::parse(icalcomponent_impl*, KCalCore::ICalTimeZones&) + 79 at icaltimezones.cpp:897
    frame #10: 0x00000001001d9504 libkcalcore.4.dylib`KCalCore::ICalFormatImpl::populate(QSharedPointer<KCalCore::Calendar> const&, icalcomponent_impl*, bool, QString const&) + 1620 at icalformat_p.cpp:2693
    frame #11: 0x00000001001c32bb libkcalcore.4.dylib`KCalCore::ICalFormat::fromRawString(QSharedPointer<KCalCore::Calendar> const&, QByteArray const&, bool, QString const&) + 779 at icalformat.cpp:187
    frame #12: 0x00000001001c23e9 libkcalcore.4.dylib`KCalCore::ICalFormat::load(QSharedPointer<KCalCore::Calendar> const&, QString const&) + 281 at icalformat.cpp:100
    frame #13: 0x00000001001bd30a libkcalcore.4.dylib`KCalCore::FileStorage::load() + 106 at filestorage.cpp:112
    frame #14: 0x000000011dcac24d ktimetrackerpart.so`KTimeTracker::KTTCalendar::reload() + 365 at kttcalendar.cpp:69
    frame #15: 0x000000011dc815eb ktimetrackerpart.so`timetrackerstorage::load(TaskView*, QString const&) + 619 at timetrackerstorage.cpp:146
    frame #16: 0x0000000000000036 ktimetracker
    frame #17: 0x0000000400000006
    frame #18: 0x000000011dc873e0 ktimetrackerpart.so`QHash<QString, Task*>::duplicateNode(QHashData::Node*, void*) + 32
    frame #19: 0x00401f0f90c30789

  thread #2: tid = 0x3003, 0x00007fff85f11c0a libSystem.B.dylib`kevent + 10
    frame #0: 0x00007fff85f11c0a libSystem.B.dylib`kevent + 10
    frame #1: 0x00007fff85f13add libSystem.B.dylib`_dispatch_mgr_invoke + 154
    frame #2: 0x00007fff85f137b4 libSystem.B.dylib`_dispatch_queue_invoke + 185
    frame #3: 0x00007fff85f132de libSystem.B.dylib`_dispatch_worker_thread2 + 252
    frame #4: 0x00007fff85f12c08 libSystem.B.dylib`_pthread_wqthread + 353
    frame #5: 0x00007fff85f12aa5 libSystem.B.dylib`start_wqthread + 13

  thread #3: tid = 0x3103, 0x00007fff85f12a2a libSystem.B.dylib`__workq_kernreturn + 10
    frame #0: 0x00007fff85f12a2a libSystem.B.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff85f12e3c libSystem.B.dylib`_pthread_wqthread + 917
    frame #2: 0x00007fff85f12aa5 libSystem.B.dylib`start_wqthread + 13

  thread #4: tid = 0x3203, 0x00007fff85f3c932 libSystem.B.dylib`select$DARWIN_EXTSN + 10
    frame #0: 0x00007fff85f3c932 libSystem.B.dylib`select$DARWIN_EXTSN + 10
    frame #1: 0x00007fff80459468 CoreFoundation`__CFSocketManager + 824
    frame #2: 0x00007fff85f31fd6 libSystem.B.dylib`_pthread_start + 331
    frame #3: 0x00007fff85f31e89 libSystem.B.dylib`thread_start + 13

}}}

This is where I disconnect for now :-/ but I don't think this deadlock has anything to do with missing X11 functionality! In fact, if I had to guess I'd say libical isn't initialised properly given how none of the background threads seem to be related to libical.

Begin forwarded message:

> From: MacPorts <noreply at macports.org>
> Date: July 20, 2014 11:52:32 CEST
> 
> #44282: patch to enable ktimetracker in kdepim4
> --------------------------+----------------------
>  Reporter:  rjvbertin@…  |      Owner:  nicos@…
>      Type:  defect       |     Status:  new
>  Priority:  Normal       |  Milestone:
> Component:  ports        |    Version:  2.3.1
> Resolution:               |   Keywords:  haspatch
>      Port:  kdepim4      |
> --------------------------+----------------------
> Changes (by mk@…):
> 
> * cc: mk@… (added)
> 
> 
> Comment:
> 
> Replying to [comment:3 rjvbertin@…]:
>> In fact (and correct me if I'm wrong), I assume that most KDE-mac
> developers will be using MacPorts
> 
> Well, I wouldn't be so sure about that. :)
> 
> I've actually spotted this ticket only because I opened our
> [https://trac.macports.org/wiki/KDEProblems/KDETickets/KDE4-Category large
> KDE ticket table] just now (which I do every now and then only)!
> 
> I am afraid it's better to bring this to the KDE-DEVEL mailing list.
> 
> -- 
> Ticket URL: <https://trac.macports.org/ticket/44282#comment:4>
> MacPorts <http://www.macports.org/>
> Ports system for OS X