I can resolve the problem by removing the line "Country=us" from /home/luke-jr/.kde3.3/share/config/kdeglobals

KOrganizer bug

Any debug output?

What do you mean by "(from 3.2.3)"? The Version string suggests that you are using CVS HEAD.

Does the crash also occur when KOrganizer is started stand-alone?

I mean that I suspected the bug to be a problem importing old data from KDE 3.2.3. The Version string was created by Bugzilla when I selected KDE 3.3 beta 1.
I'm quite sure it occured when KOrg was started standalone, also.
IIRC, I worked around the problem by unsetting my KDE locale (in which case it doesn't try to load holidays)

I have the same problem here with KOrganizer from a very recent CVS. I have this in kdeglobals:

[Locale]
Country=si
Language=sl_SI
NegativePrefixCurrencySymbol=false
PositivePrefixCurrencySymbol=false

If I try to start from console I get this:

korganizer: KOApp::newInstance()
korganizer: AlarmClient::AlarmClient()
korganizer: KOrganizer::KOrganizer()
korganizer: CalendarView::CalendarView( Calendar )
korganizer: ----- time zone: Europe/Ljubljana
korganizer: KOPrefs::usrReadConfig()
libkdepim: KPimPrefs::usrReadConfig()
korganizer: CalendarView::updateConfig()
korganizer: CalendarView::CalendarView() done
korganizer: KOrganizer::init() resources
libkdepim: system timezone from /etc/localtime is Europe/Ljubljana
libkcal: CalendarResources::init
korganizer: CalendarResources used by KOrganizer:
korganizer:   Default Calendar
korganizer: loadCalendarDecoration: library: libkorg_holidays
ERROR: Communication problem with korganizer, it probably crashed.

Is there anything else I could do to help?

I also enabled debugging in kdepim and glibc and now I get this:

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 20109)]
[KCrash handler]
#4  0x0000002a9e2c2ed3 in Holidays::getHoliday(QDate const&) (this=0x8144e0, 
    qd=@0x8087d0) at holidays.cpp:103
#5  0x0000002a9e2c2d70 in Holidays::shortText(QDate const&) (this=0x8144e0, 
    date=@0x8087d0) at holidays.cpp:74
#6  0x0000002a958544fc in KOCore::holiday(QDate const&) (this=0x6fb4e0, 
    date=@0x8087d0) at kocore.cpp:309
#7  0x0000002a958582f5 in KODayMatrix::updateView(QDate) (this=0x808330, 
    actdate={jd = 0}) at kodaymatrix.cpp:257
#8  0x0000002a958581a3 in KODayMatrix::updateView() (this=0x808330)
    at kodaymatrix.cpp:216
#9  0x0000002a957dc73c in KDateNavigator::updateView() (this=0x7ec960)
    at kdatenavigator.cpp:189
#10 0x0000002a957ddb2e in DateNavigatorContainer::updateView() (this=0x7ec560)
    at datenavigatorcontainer.cpp:104
#11 0x0000002a957eb84f in CalendarView::updateView(QDate const&, QDate const&)
    (this=0x6fc300, start=@0x76b900, end=@0x76b900) at calendarview.cpp:693
#12 0x0000002a957eb897 in CalendarView::updateView() (this=0x6fc300)
    at calendarview.cpp:701
#13 0x0000002a957f4f94 in KOViewManager::showView(KOrg::BaseView*) (
    this=0x6fc970, view=0x78db10) at koviewmanager.cpp:130
#14 0x0000002a957f56f5 in KOViewManager::showAgendaView() (this=0x6fc970)
    at koviewmanager.cpp:275
#15 0x0000002a957f4cbe in KOViewManager::readSettings(KConfig*) (
    this=0x6fc970, config=0x669b40) at koviewmanager.cpp:83
#16 0x0000002a957eac03 in CalendarView::readSettings() (this=0x6fc300)
    at calendarview.cpp:466
#17 0x0000002a9585f999 in ActionManager::createCalendarResources() (
    this=0x82e370) at actionmanager.cpp:185
#18 0x000000000040beb0 in KOrganizer::init(bool) (this=0x6f0bd0, 
    document=false) at korganizer.cpp:123
#19 0x000000000040dea9 in KOrganizerApp::processCalendar(KURL const&) (
    this=0x7fbffff310, url=@0x7fbfffea30) at koapp.cpp:115
#20 0x000000000040dcce in KOrganizerApp::newInstance() (this=0x7fbffff310)
    at koapp.cpp:90
#21 0x0000002a9866aeae in KUniqueApplication::processDelayed() ()
   from /usr/kde/cvs/lib/libkdecore.so.4
#22 0x0000002a9866b038 in KUniqueApplication::qt_invoke(int, QUObject*) ()
   from /usr/kde/cvs/lib/libkdecore.so.4
#23 0x000000000040e13f in KOrganizerApp::qt_invoke(int, QUObject*) (
    this=0x7fbffff310, _id=18, _o=0x7fbfffec80) at koapp.moc:77
#24 0x0000002a9939b098 in QObject::activate_signal(QConnectionList*, QUObject*)
    () from /usr/qt/3/lib/libqt-mt.so.3
#25 0x0000002a99677bb6 in QSignal::signal(QVariant const&) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#26 0x0000002a993b18ad in QSignal::activate() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#27 0x0000002a993b7f68 in QSingleShotTimer::event(QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#28 0x0000002a993427ed in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#29 0x0000002a99342b70 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#30 0x0000002a985c71e1 in KApplication::notify(QObject*, QEvent*) ()
   from /usr/kde/cvs/lib/libkdecore.so.4
#31 0x0000002a99337905 in QEventLoop::activateTimers() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#32 0x0000002a992f93bd in QEventLoop::processEvents(unsigned) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#33 0x0000002a99356875 in QEventLoop::enterLoop() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#34 0x0000002a993567d2 in QEventLoop::exec() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#35 0x000000000040b1f6 in main (argc=1, argv=0x7fbffff5b8) at main.cpp:58
Current language:  auto; currently c

I have this problem after upgrading to 3.3 as well:
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)

I am going to try building under gcc 3.4 to see if that changes anything.

Using host libthread_db library "/lib/libthread_db.so.1".
[KCrash handler]
#4  0x0000002a9bffcf58 in Holidays::getHoliday(QDate const&) (
    this=0x7fbfffde30, qd=@0x8fa160) at holidays.cpp:103
#5  0x0000002a9bffce39 in Holidays::shortText(QDate const&) (this=0xa, 
    date=@0x3fffffc6) at holidays.cpp:74
#6  0x0000002a95839e97 in KOCore::holiday(QDate const&) (this=0x7476c0, 
    date=@0x8fa160) at kocore.cpp:309
#7  0x0000002a9583d3f1 in KODayMatrix::updateView(QDate) (this=0x8f9d30, 
    actdate={jd = 0}) at kodaymatrix.cpp:257
#8  0x0000002a9583d30f in KODayMatrix::updateView() (this=0x5c)
    at kodaymatrix.cpp:216
#9  0x0000002a957d61e2 in KDateNavigator::updateView() (this=0x845a60)
    at kdatenavigator.cpp:189
#10 0x0000002a957d72b7 in DateNavigatorContainer::updateView() (this=0x769c88)
    at datenavigatorcontainer.cpp:104
#11 0x0000002a957e2929 in CalendarView::updateView(QDate const&, QDate const&)
    (this=0x7478b0, start=@0x8141c0, end=@0x8141c0) at calendarview.cpp:693
#12 0x0000002a957e2986 in CalendarView::updateView() (this=0x7478b0)
    at calendarview.cpp:701
#13 0x0000002a957eae60 in KOViewManager::showView(KOrg::BaseView*) (
    this=0x7480a0, view=0xa) at koviewmanager.cpp:130
#14 0x0000002a957eb3d6 in KOViewManager::showAgendaView() (this=0x7480a0)
    at koviewmanager.cpp:275
#15 0x0000002a957eac8a in KOViewManager::readSettings(KConfig*) (
    this=0x7480a0, config=0x6a8c20) at koviewmanager.cpp:83
#16 0x0000002a957e1da4 in CalendarView::readSettings() (this=0x7478b0)
    at calendarview.cpp:466
#17 0x0000002a958436ee in ActionManager::createCalendarResources() (
    this=0x8785a0) at actionmanager.cpp:186
#18 0x000000000040be91 in KOrganizer::init(bool) (this=0x52c6c0, 
    document=false) at korganizer.cpp:123
#19 0x000000000040d59f in KOrganizerApp::processCalendar(KURL const&) (
    this=0x7fbfffeb60, url=@0x7fbfffe300) at koapp.cpp:115
#20 0x000000000040d4c6 in KOrganizerApp::newInstance() (this=0x7fbfffeb60)
    at koapp.cpp:87
#21 0x0000002a986bab6a in KUniqueApplication::processDelayed() (
    this=0x7fbfffeb60) at kuniqueapplication.cpp:438
#22 0x0000002a986baeef in KUniqueApplication::qt_invoke(int, QUObject*) (
    this=0x7fbfffeb60, _id=18, _o=0x7fbfffe510) at kuniqueapplication.moc:86
#23 0x000000000040d769 in KOrganizerApp::qt_invoke(int, QUObject*) (this=0x5c, 
    _id=10, _o=0x3fffffc6) at koapp.moc:77
#24 0x0000002a99302f08 in QObject::activate_signal(QConnectionList*, QUObject*)
    () from /usr/qt/3/lib/libqt-mt.so.3
#25 0x0000002a995d8a76 in QSignal::signal(QVariant const&) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#26 0x0000002a993195ed in QSignal::activate() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#27 0x0000002a9931fc78 in QSingleShotTimer::event(QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#28 0x0000002a992aa99d in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#29 0x0000002a992aad20 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#30 0x0000002a986332a5 in KApplication::notify(QObject*, QEvent*) (
    this=0x7fbfffeb60, receiver=0x73c300, event=0x7fbfffe890)
    at kapplication.cpp:495
#31 0x0000002a9929fac3 in QEventLoop::activateTimers() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#32 0x0000002a9926159d in QEventLoop::processEvents(unsigned) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#33 0x0000002a992be9d5 in QEventLoop::enterLoop() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#34 0x0000002a992be932 in QEventLoop::exec() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#35 0x000000000040b2f7 in main (argc=1, argv=0x7fbfffee08) at main.cpp:58

You are all on Gentoo, right? Could this have something to do with optimizations done by the compiler? Does the problem still occur with less aggressive optimization?

I can't reproduce the problem here.

Yes I am on Gentoo too and I compile using GCC 3.4.1 and for AMD64. I use these optimizations: "-march=athlon64 -pipe -O2 -fomit-frame-pointer -frename-registers" but when I built for debuging (and I still get the crash) I used: "-march=athlon64 -pipe -O2 -g".

Well, let's put it this way: kdepim-3.2.3 works fine (-O2) but something broke on 3.3-beta2 (-O2) and it might be related to amd64.  It does not, at least, appear to related to gcc version or C/CXXFLAGS -- since -O2 by itself should be OK.

Also -- yes, the Korganizer crash happens both from Kontact and running standalone.  Luke-jr's locale workaround in comment #4 didn't work for me.

I'm seeing a lot of these crashes that have /lib/libthread_db.so.1 at the top in KDE 3.3.0. For example when I try to set additional options for Samba sharing (clicking More Samba Options when sharing a folder), then when I try to search for a word in PO Compendium dictionary in KBabel Dictionary. All was working just fine in old KDE with same options for compiler. What do all this have in common? Do they use any speciall KDE component that it the same for them?

libthread_db is just part of glibc.

If any KDE devs want access to a machine (w/symbols) to troubleshoot this, email me or jabber absinthe@retrovertigo.com.  

So if I (correctly) enabled debugging for glibc and kdepim it should show all the needed info? Or should I also enable debugging in other KDE 3.3 packages and qt/arts?

OK this is what makes it work for me without crash. As I said, I have my system set to Slovenian locale: sl. So in these crashes I see some function that I guess it has something to do with holidays. So what i did is find the file with slovenian holidays. I found it in:
/usr/kde/cvs/share/apps/korganizer/holiday_si
I then deleted this file and korganizer then started just fine. Just to check it out again I put back the same file and korganizer crashes again.
So it looks like korganizer has some problems reading the holiday definition files or something.

Good work!  I have confirmed this (holiday_us) as well.  Removing the file makes it work for me too.

Any news about fixing this crash?

I still can't reproduce the crash. Seems to be a Gentoo-specific problem.

Could you then make a bug report to Gentoo as you probably know a lot more then me as to what is going on. I don't exactly know what is going on, only that there is something wrong with reading holiday files and as they tell it is not crashing in libthread_db but in kde code. Or tell me here what to write in the bug report. Can I just link to this bug report?

OK I opened a bug on Gentoo Bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=58899
If anyone can add any comment please do so.

There was already an open bug in Gentoo.  

Cornelius, how do you come to the conclusion this is a Gentoo only bug?  Because you're not able to reproduce it on your x86 machine?  Have you tried reproducing the problem on an amd64 machine?   Doesn't it seem a little suspect that this problem is related to the holiday files?  Does that seem like a platform bug to you?  

Nobody has yet contacted me about my offer to provide a machine for troubleshooting, complete with symbols.

Hi Dylan,

On Friday 30 July 2004 19:34, Dylan Carlson wrote:
> Cornelius, how do you come to the conclusion this is a Gentoo only bug? 
> Because you're not able to reproduce it on your x86 machine?  

Mainly, yes. Experience has taught us that if there is some very wierd 
behaviour or a crash, we better check if the user is running Gentoo. Usually, 
that's the case.

For example, we had several users complaining that for them the events were 
not aligned at the event start / end time, but the boxes were squares. Guess 
which Distribution all these users were using? yes, Gentoo. And we had some 
other occasions where only Gentoo-users had such weird problems.

> Have you 
> tried reproducing the problem on an amd64 machine?   Doesn't it seem a
> little suspect that this problem is related to the holiday files?  

No, not really. Weird crashes can happen everywhere ;-)

> Does that seem like a platform bug to you?

Yes, either a Gentoo-specific problem, or a problem with the compiler for 
amd64. KOrganizer's code seems to work fine on all other platforms, so what 
else than a compiler problem can it be? Please understand that we just lack 
the time for debugging compiler-specific problems.

> Nobody has yet contacted me about my offer to provide a machine for
> troubleshooting, complete with symbols.

Maybe that's because there are just two (sometimes three) people working on 
KOrganizer (Cornelius and me, sometimes also Bram), and we all have daytime 
jobs, and Cornelius needs to get Kitchensync in shape, while trying to manage 
his family, too.
Also, this is the last week for getting things in shape for the kde 3.3 
release, and to be honest, there are lots of things that are much more 
important than this bug.

I hope you understand this.

Cheers,
Reinhold

Oh, I forgot to add that for KDE 3.3 I recently converted the holiday plugin 
and all data files to UTF8. Maybe that already solves the problem...

Cheers,
Reinhold

Hm a crash that prevents you to use the entire korganizer is quite a big issue if you ask me :(

I agree that this is a major problem, but as there exists a workaround it's not critical.

The holiday file is parsed by a bison generated parser in a plugin, so this could well be caused by Gentoo specifics, especially as I'm not aware of any non-Gentoo system showing the problem.

I don't know if this could be a general amd64 problem, but I haven't had any reports about amd64 problems on non-Gentoo systems. I might be able to check if it generally works on amd64 next week.

Okay, Adriaan de Groot confirmed the crash on an amd64 machine running FreeBSD, so it's nothing Gentoo-specific, rather amd64-specific. Here's the IRC log:

<[ade]> so, just enable holiday plugin?
<[ade]> and select something other than australia, perhaps
<[ade]> ok, if i select italy, ferragosto (15-8) appears in the korganizer window.
<[ade]> quit korg, then restart and it segvs
<[ade]> korganizer: loadCalendarDecoration: library: libkorg_holidays
<[ade]> kdecore (KConfigSkeleton): Creating KConfigSkeleton (0x968b80)
<[ade]> kdecore (KConfigSkeleton): KConfigSkeleton::readConfig()
<[ade]> kdecore (KConfigSkeleton): KConfigSkeleton::readConfig()
<[ade]> ERROR: Communication problem with korganizer, it probably crashed.
<[ade]> that's the debug output - and drkonqui is totally broken on fbsd, always has been
<[ade]> running it in gdb now
<[ade]> (gdb) bt
<[ade]> #0  0x0000000206adddc3 in Holidays::getHoliday (this=0x987500, qd=@0x965ed0)
<[ade]>    at /mnt/src/kde-HEAD/kdepim/korganizer/plugins/holidays/holidays.cpp:103
<[ade]> #1  0x0000000206addc58 in Holidays::shortText (this=0x987500, date=@0x965ed0)
<[ade]>    at /mnt/src/kde-HEAD/kdepim/korganizer/plugins/holidays/holidays.cpp:74
<[ade]> #2  0x000000020082abdc in KOCore::holiday (this=0x6b5e00, date=@0x965ed0)
<[ade]>    at /mnt/src/kde-HEAD/kdepim/korganizer/kocore.cpp:309
<[ade]> #3  0x000000020082ac5c in KOCore::isWorkDay (this=0x6b5e00, date=@0x965ed0)
<[ade]>    at /mnt/src/kde-HEAD/kdepim/korganizer/kocore.cpp:319


Reinhold

I recompiled glibc with NPTL support and KDE with QT 3.3.3 and now I get a bit different backtrace:

Using host libthread_db library "/lib/libthread_db.so.1".
0x0000002a9a5a2a16 in waitpid () from /lib/libpthread.so.0
#0  0x0000002a9a5a2a16 in waitpid () from /lib/libpthread.so.0
#1  0x0000002a988b24be in KCrash::defaultCrashHandler (sig=11)
    at kcrash.cpp:246
#2  0x0000002a9a9e2200 in killpg () from /lib/libc.so.6
#3  0x0000000000000000 in ?? ()
#4  0x0000000000000000 in ?? ()
#5  0x0000000000000000 in ?? ()
#6  0x0000007f00000002 in ?? ()
#7  0x0000000000000000 in ?? ()
#8  0x00000000008cc1a0 in ?? ()
#9  0x0000000000000651 in ?? ()
#10 0x0000000000000650 in ?? ()
#11 0x0000000000000206 in ?? ()
#12 0x0000002a9e6f7820 in yacc_daycolor ()
   from /usr/kde/cvs/lib/kde3/libkorg_holidays.so
#13 0x000000000076d7a8 in ?? ()
#14 0x0000007fbfffe500 in ?? ()
#15 0x0000000000733210 in ?? ()
#16 0x00000000002cc935 in ?? ()
#17 0x0000000000000001 in ?? ()
#18 0x000000000081bb80 in ?? ()
#19 0x0000007fbfffe430 in ?? ()
#20 0x000000003fffffc6 in ?? ()
#21 0xfffffffc000003b0 in ?? ()
#22 0x00000000000005fc in ?? ()
#23 0x0000007fbfffe420 in ?? ()
#24 0x0000002a9e5ebe64 in Holidays::getHoliday (this=0x7fbfffe430, 
    qd=@0x81bb80) at holidays.cpp:103
#25 0x0000002a999eab73 in QGList::removeRef (this=) at tools/qglist.cpp:559

Hallo,

I use SuSE 9.1 professional with x86-64 AMD Kernel and KDE 3.3.0 (from SuSE mirror). Since update I've the same problem. The panal applet works fine. But if I whould start korganizer application, it crashes with Signal 11.

I use before KDE 3.2.3 from same Server and it works fine.

If I open kcontrol and change KDE-Resources to calendar, a message box pops up and says me (in german) that no standard resource exists. But in the field is the original resource file selected and writeable (I checkted aditional the file). But one diferant I see, the Calendar Format is marked as iCalendar but in the file shows:
BEGIN:VCALENDAR
...
END:VCALENDAR
If I change the marker to vCalendar, it has no efect. But if I add another entry in this list, and mark it as standard, it has also not effect.

**** Command line output ****
> korganizer
ERROR: Communication problem with korganizer, it probably crashed.
KCrash: Application 'korganizer' crashing...

**** Debug output ****
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 182988421664 (LWP 27392)]
[KCrash handler]
#3  0x0000002a9c2b61ec in Holidays::getHoliday ()
   from /opt/kde3/lib64/kde3/libkorg_holidays.so
#4  0x0000002a9c2b6289 in Holidays::shortText ()
   from /opt/kde3/lib64/kde3/libkorg_holidays.so
#5  0x0000002a95812c1e in KOCore::holiday ()
   from /opt/kde3/lib64/libkorganizer.so.1
#6  0x0000002a958134c3 in KODayMatrix::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#7  0x0000002a9581356f in KODayMatrix::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#8  0x0000002a95838a52 in KDateNavigator::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#9  0x0000002a95838b77 in DateNavigatorContainer::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#10 0x0000002a95838bea in CalendarView::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#11 0x0000002a95838c58 in CalendarView::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#12 0x0000002a9582c7f0 in KOViewManager::showView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#13 0x0000002a9585adb5 in KOViewManager::showAgendaView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#14 0x0000002a9585b02d in KOViewManager::readSettings ()
   from /opt/kde3/lib64/libkorganizer.so.1
#15 0x0000002a9585b1f0 in CalendarView::readSettings ()
   from /opt/kde3/lib64/libkorganizer.so.1
#16 0x0000002a9585b8d4 in ActionManager::createCalendarResources ()
   from /opt/kde3/lib64/libkorganizer.so.1
#17 0x000000000040d871 in KOrganizer::init ()
#18 0x000000000040dd35 in KOrganizerApp::processCalendar ()
#19 0x000000000040df4e in KOrganizerApp::newInstance ()
#20 0x0000002a9831d40f in KUniqueApplication::processDelayed ()
   from /opt/kde3/lib64/libkdecore.so.4
#21 0x0000002a98322ab8 in KUniqueApplication::qt_invoke ()
   from /opt/kde3/lib64/libkdecore.so.4
#22 0x000000000040c7c9 in KOrganizerApp::qt_invoke ()
#23 0x0000002a98fa7f3d in QObject::activate_signal ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#24 0x0000002a992cbae7 in QSignal::signal ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#25 0x0000002a98fc3351 in QSignal::activate ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#26 0x0000002a98fc9e4e in QSingleShotTimer::event ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#27 0x0000002a98f4a5c6 in QApplication::internalNotify ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#28 0x0000002a98f499e8 in QApplication::notify ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#29 0x0000002a98310f55 in KApplication::notify ()
   from /opt/kde3/lib64/libkdecore.so.4
#30 0x0000002a98ee26e4 in QApplication::sendEvent ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#31 0x0000002a98f39b05 in QEventLoop::activateTimers ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#32 0x0000002a98ef4316 in QEventLoop::processEvents ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#33 0x0000002a98f5d4ba in QEventLoop::enterLoop ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#34 0x0000002a98f5d3b5 in QEventLoop::exec ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#35 0x0000002a98f4a6de in QApplication::exec ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#36 0x000000000040e568 in main ()

**** dmesg ****
no output

PS: I use the /home from NFS-Server. The same setings works on a Notebook with standard kernel (x386) without problems.

Ciao
Ulf

*** Bug 87781 has been marked as a duplicate of this bug. ***

The duplicate got a crash

CVS commit by kainhofe: 

Commit Patch by Michael Buchau, which prevents the crash. Not sure it fixes the actual cause of the crash. Coolo also says it works, so trust him...

CCMAIL: 84979@bugs.kde.org


  M +2 -2      holidays.cpp   1.13


--- kdepim/korganizer/plugins/holidays/holidays.cpp  #1.12:1.13
@@ -92,5 +92,5 @@ QString Holidays::getHoliday(const QDate
   int lastYear = 0;
 
-  if (mHolidayFile.isEmpty()) return QString::null;
+  if (mHolidayFile.isEmpty() || qd.isNull()) return QString::null;
 
   //if ((lastYear == 0) || (qd.year() != lastYear)) {

*** Bug 88094 has been marked as a duplicate of this bug. ***

I'm running SuSE 9.1 Professional 64-Bit and updated from KDE 3.2(64-Bit) to KDE 3.3(64-Bit) via the RPM-packages provided by SuSE.
Now Korganizer crashs on startup, so this is not only a Gentoo Problem...
Is there a workaround, yet? Could someone post this workaround please?

I post my traceback, maybe this helps:
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 182988421664 (LWP 13033)]
[KCrash handler]
#3  0x0000002a9c10e1ec in Holidays::getHoliday ()
   from /opt/kde3/lib64/kde3/libkorg_holidays.so
#4  0x0000002a9c10e289 in Holidays::shortText ()
   from /opt/kde3/lib64/kde3/libkorg_holidays.so
#5  0x0000002a95812c1e in KOCore::holiday ()
   from /opt/kde3/lib64/libkorganizer.so.1
#6  0x0000002a958134c3 in KODayMatrix::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#7  0x0000002a9581356f in KODayMatrix::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#8  0x0000002a95838a52 in KDateNavigator::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#9  0x0000002a95838b77 in DateNavigatorContainer::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#10 0x0000002a95838bea in CalendarView::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#11 0x0000002a95838c58 in CalendarView::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#12 0x0000002a9582c7f0 in KOViewManager::showView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#13 0x0000002a9585adb5 in KOViewManager::showAgendaView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#14 0x0000002a9585b02d in KOViewManager::readSettings ()
   from /opt/kde3/lib64/libkorganizer.so.1
#15 0x0000002a9585b1f0 in CalendarView::readSettings ()
   from /opt/kde3/lib64/libkorganizer.so.1
#16 0x0000002a9585b8d4 in ActionManager::createCalendarResources ()
   from /opt/kde3/lib64/libkorganizer.so.1
#17 0x000000000040d871 in KOrganizer::init ()
#18 0x000000000040dd35 in KOrganizerApp::processCalendar ()
#19 0x000000000040df4e in KOrganizerApp::newInstance ()
#20 0x0000002a9831d40f in KUniqueApplication::processDelayed ()
   from /opt/kde3/lib64/libkdecore.so.4
#21 0x0000002a98322ab8 in KUniqueApplication::qt_invoke ()
   from /opt/kde3/lib64/libkdecore.so.4
#22 0x000000000040c7c9 in KOrganizerApp::qt_invoke ()
#23 0x0000002a98fa7f3d in QObject::activate_signal ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#24 0x0000002a992cbae7 in QSignal::signal ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#25 0x0000002a98fc3351 in QSignal::activate ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#26 0x0000002a98fc9e4e in QSingleShotTimer::event ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#27 0x0000002a98f4a5c6 in QApplication::internalNotify ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#28 0x0000002a98f499e8 in QApplication::notify ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#29 0x0000002a98310f55 in KApplication::notify ()
   from /opt/kde3/lib64/libkdecore.so.4
#30 0x0000002a98ee26e4 in QApplication::sendEvent ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#31 0x0000002a98f39b05 in QEventLoop::activateTimers ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#32 0x0000002a98ef4316 in QEventLoop::processEvents ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#33 0x0000002a98f5d4ba in QEventLoop::enterLoop ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#34 0x0000002a98f5d3b5 in QEventLoop::exec ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#35 0x0000002a98f4a6de in QApplication::exec ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#36 0x000000000040e568 in main ()

*** Bug 88004 has been marked as a duplicate of this bug. ***

I hope that as a result of this, people are not so quick to jump to conclusions about bugs being Gentoo-specific in the future.  It's really counterproductive to balkanize the distros in that manner.   Even in cases where the toolchain is ahead of what KDE developers are using, they are still legit bugs; they will have to be fixed sooner or later.  

On Tuesday 31 August 2004 10:04, Dylan Carlson wrote:
> ------- I hope that as a result of this, people are not so quick to jump to
> conclusions about bugs being Gentoo-specific in the future.  

Okay, but then bug reporters also need to learn to include more important 
information into the reports. For example, the crucial issue that the bug 
happened on an AMD 64 system was never mentioned. Only in comment #10 to the 
report did one person casually mention it.
If a report just says, KOrganizer crashes on Linux Gentoo with compiler 3.4, 
of course we are assuming it's intel i386 unless something different is 
written in the report.

> It's really counterproductive to balkanize the distros in that manner.  

Pleas look at it from the other side. We get a bug report of a crash on Linux 
Gentoo with gcc 3.4. Two other people (also running Gentoo) confirm this, but 
we are unable to reproduce the problem here with Debian Linux and gcc 3.3.x 
(of course on i386, but then the bug report didn't say something different). 
What would be your conclusion?


Reinhold

Perhaps the bug tracker should be asking for arch along w/ userland and compiler... No reason I see to assume everyone runs x86. Most bugs are also likely to be arch-inspecific, so there's no obvious reason to supply arch if it's not asked for.

Yup I agree. Bugzilla should be changed to make it possible to specify platform/architecture. See these bug:
http://bugs.kde.org/show_bug.cgi?id=76367
I think this is exactly about this problem.

On Wednesday 01 September 2004 12:34 pm, Reinhold Kainhofer wrote:
> Pleas look at it from the other side. We get a bug report of a crash on
> Linux Gentoo with gcc 3.4. Two other people (also running Gentoo)
> confirm this, but we are unable to reproduce the problem here with
> Debian Linux and gcc 3.3.x (of course on i386, but then the bug report
> didn't say something different). What would be your conclusion?

I did look at it from your side.  What I'm specifically addressing is (what 
I perceive) as some anti-gentoo comments/conclusions...  None of which are 
valid in this case, and I suspect are unwarranted in most cases.

Specifically the remark:  "Experience has taught us that if there is some 
very wierd  behaviour or a crash, we better check if the user is running 
Gentoo."  ... as if weird behavior never happens on other distributions!  

I acknowledge that Gentoo tends to be bleeding-edge in terms of running new 
tool versions; however, it's unfair to compare us to Debian -- which by 
anyone's standards is late moving to new versions of anything, including 
the toolchain (although yes, Debian is a more predictable operating system 
than Gentoo).  

What I'm trying to say here is, the bugs that Gentoo users report are no 
less valid simply because we find them first.  Someone would end up 
tripping over these bugs first -- it just happens to be us.   If we're 
stable on a gcc version that you don't support yet, I'm satisfied with an 
answer that states:  "your gcc version is not supported, this bug will be 
deferred for a future release.  please try building under supported gcc 
version <foo> and report back."  That's fine, and we will certainly 
accommodate that request.

In this case, I specifically tested for the bug two versions of gcc (3.3 
and 3.4), on two different archs (i386, and amd64), and offered machines 
w/symbols and ssh/vnc for KDE devs to test the problem themselves.  I 
appreciate that you folks are busy, and you're doing a wonderful job with 
the application itself, but I don't know how much more I (and we @ gentoo) 
can do for you in these bugs.

I want a good, mutually beneficial working relationship between Gentoo and 
KDE.  Let me know what we're supposed to do to avoid being treated like a 
redheaded stepchild in these bug reports.

We certainly don't want to treat bug reports of Gentoo users as some kind of second-class reports. Not at all. But as Reinhold said the experience actual shows that Gentoo users hit weirder problems than the rest of us and it's often hard to make sense of these bug reports, because Gentoo systems are so inhomogenous.

My advice for Gentoo users would be to very specifically state what kind of system the bug appears on and maybe also try to reproduce the bug with other settings or on another system to better help to identify what could cause or trigger the bug.

It's my fault that I didn't catch the lack of amd64 designation until #10, but all the same nobody made the false conclusion it was Gentoo-specific until #19.

Again, I did go through steps of reproducing it with different compiler versions and on different archs before those conclusions were made.  Jure was very helpful in finding a workaround with regard to the holiday files.  I offered machines for KDE devs to examine.   All of this activity and effort predated your comments.   

If I had felt that it was a problem related to an unsupported gcc version, I would have opened a separate bug for consideration in a future KDE release, instead of chasing this one down.  As an OS developer I'm very sensitive to not wasting the time of the application developers, and I feel like we weren't given appropriate consideration here.  It was only until Adrian confirmed the problem on FreeBSD that this was considered a legitimate bug.

I'm not looking for an apology, I'm just hoping that we will be given more respectful consideration in the future.

On Wednesday 01 September 2004 21:17, Dylan Carlson wrote:
> On Wednesday 01 September 2004 12:34 pm, Reinhold Kainhofer wrote:
> > Pleas look at it from the other side. We get a bug report of a crash on
> > Linux Gentoo with gcc 3.4. Two other people (also running Gentoo)
> > confirm this, but we are unable to reproduce the problem here with
> > Debian Linux and gcc 3.3.x (of course on i386, but then the bug report
> > didn't say something different). What would be your conclusion?
>
> I did look at it from your side.  What I'm specifically addressing is (what
> I perceive) as some anti-gentoo comments/conclusions...  

Believe me, I spend really a lot of time trying to reproduce the problem. 
Since I was never able to reproduce it with the information given, I blamed 
it on the only known difference (after 

> None of which are 
> valid in this case, and I suspect are unwarranted in most cases.
>
> Specifically the remark:  "Experience has taught us that if there is some
> very wierd  behaviour or a crash, we better check if the user is running
> Gentoo."  ... as if weird behavior never happens on other distributions!

Well, gentoo by default (or is it the users that set them? I don't know gentoo 
too much) uses much more aggressive optimization settings for the compiler. 
And I still had the memory of the bug report with squared events in memory:
http://bugs.kde.org/show_bug.cgi?id=73718
and it's dozens of duplicates like:
http://bugs.kde.org/show_bug.cgi?id=81738

Actually, one person also had that problem also on Debian unstable, but he 
explicitly used a more aggressive optimization (and was aware of this), while 
it seems that Gentoo automatically does that and the users might not even be 
aware of it. 
A good example of a useful bug report is 81738 (mentioned above), which 
included all version numbers and compiler flags, so no vital information is 
left out.

> I acknowledge that Gentoo tends to be bleeding-edge in terms of running new
> tool versions; however, it's unfair to compare us to Debian -- which by
> anyone's standards is late moving to new versions of anything, including
> the toolchain (although yes, Debian is a more predictable operating system
> than Gentoo).

Actually, I'm using Debian "unstable" (which means it's about as stable as a 
typical RedHat or SUSE release), which uses mainstream packages.

> What I'm trying to say here is, the bugs that Gentoo users report are no
> less valid simply because we find them first.  Someone would end up
> tripping over these bugs first -- it just happens to be us.   If we're
> stable on a gcc version that you don't support yet, I'm satisfied with an
> answer that states:  "your gcc version is not supported, this bug will be
> deferred for a future release.  please try building under supported gcc
> version <foo> and report back."  That's fine, and we will certainly
> accommodate that request.

Actually, I don't even know which compiler I use myself. We just can't test 
with more gcc versions than just the one that we use ourselves. 

> I want a good, mutually beneficial working relationship between Gentoo and
> KDE.  Let me know what we're supposed to do to avoid being treated like a
> redheaded stepchild in these bug reports.

I want a good relationship, too. It's just that I sometimes get quite 
frustrated, when I really try hard, but cannot reproduce a problem with the 
information given. 

Some things, which of course always help are:
-) all version numbers/flags as mentioned above.
-) check if the problem still appears with less aggressive optimization (see 
comment #8 to bug 73718).
-) Also mention in the bug report what you have already tried, but didn't 
solve the problem (e.g. you just said that you also checked it on an x86 
machine, but I couldn't find any reference in the bug comments).

Cheers,
Reinhold

PS: Have you tried korganizer from CVS HEAD with the patch from bug report 
87781 (the commit message is comment #33 to bug 84979)? Does that fix the 
crash? If so, we'll have to backport the fix to the 3.3 branch.

On Wednesday 01 September 2004 22:11, Dylan Carlson wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=84979
>
>
>
>
> ------- Additional Comments From absinthe gentoo org  2004-09-01 22:11
> ------- It's my fault that I didn't catch the lack of amd64 designation
> until #10, but all the same nobody made the false conclusion it was
> Gentoo-specific until #19.
>
> Again, I did go through steps of reproducing it with different compiler
> versions and on different archs before those conclusions were made.  Jure
> was very helpful in finding a workaround with regard to the holiday files. 
> I offered machines for KDE devs to examine.   All of this activity and
> effort predated your comments.
>
> If I had felt that it was a problem related to an unsupported gcc version,
> I would have opened a separate bug for consideration in a future KDE
> release, instead of chasing this one down.  As an OS developer I'm very
> sensitive to not wasting the time of the application developers, and I feel
> like we weren't given appropriate consideration here.  It was only until
> Adrian confirmed the problem on FreeBSD that this was considered a
> legitimate bug.

I considered it a legitimate bug report as soon as I was aware that amd64 is a 
different platform (yes, I didn't know this before, I'm just a mathematician 
and spare-time kde developer, but I'm quite ignorant about hardware - as long 
as my machine works I'm fine). Actually, that's why I bugged Adriaan on IRC 
to check it on his machine (although he was really in a hurry for a summer 
school).

Actually, the bug report was never considered an illegitimate bug report, 
because then it would have been closed as INVALID. Every crash is considered 
a problem, but when we can't reproduce it, we can't do anything about it.

Cheers,
Reinhold

I do understand your reticence to handle bug reports from Gentoo users, given the amount of variation from one user's system to another.

I'm not going to go so far as to suggest a policy here.  I'm not a member of the KDE team @ Gentoo (that is primarily Caleb and Carsten).  I am on the AMD64 team.  In both of those bug reports you cited as examples, there were no comments/interactions with Gentoo developers (that I noticed).  I hope that anytime a Gentoo developer comments on a bug that we are given the benefit of the doubt.  Why?  Gentoo developers generally try to debug it ourselves first.  That's our burden:  making sure the bug is not due to our packaging/configuration before reporting it upstream.

Gentoo allows for a lot of flexibility in how users build their systems.  Yes, that means people can specify aggressive compiler settings and use beta versions of tools/dependencies.   We can't prevent Gentoo users from posting bugs here on KDE's bugzilla -- although we would *hope* they file bugs in our Bugzilla first.  This is what we encourage them to do whenever possible.   Most of our users are smart enough to avoid posting bugs when they know they are using unsupported settings.

As a general rule, Gentoo devs believe everything should compile & work as expected with CFLAGS=-O2.  We advise users to use other CFLAGS at their own risk.  Debian follows the same practice (-O2) when building it's packages, IIRC.  So if we meet the correct gcc version requirement, meet the dependency requirements, and compile with -O2 we expect the same results that other distros experience.  If some basic troubleshooting beyond that fails, and we reproduce the bug with more users, we will bounce it upstream to you, definitely.  

I will confirm the correctness of the patch in #33 within 24 hrs.

After all the problems with KDEPIM compillation with automake were fixed I was finally able to compile the package. All I can say is that the patch works for me. No more crash at startup. Thanks!

Jure says the patch fixed the problem. Patch was created by a third person, who also doesn't experience crashes any more, so I assume the patch has really fixed the problem.

Cheers,
Reinhold

I think this should be reopened.

System: AMD64, SUSE 9.1 - vanilla install, fully patched.

Just upgraded to KDE 3.3 via SuSE RPMs from the KDE site and get the same problem.

Here is a a stack trace:-

Using host libthread_db library "/lib64/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 182988422912 (LWP 5729)]
[KCrash handler]
#3  0x0000002a9c0b71ec in Holidays::getHoliday ()
   from /opt/kde3/lib64/kde3/libkorg_holidays.so
#4  0x0000002a9c0b7289 in Holidays::shortText ()
   from /opt/kde3/lib64/kde3/libkorg_holidays.so
#5  0x0000002a95812c1e in KOCore::holiday ()
   from /opt/kde3/lib64/libkorganizer.so.1
#6  0x0000002a958134c3 in KODayMatrix::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#7  0x0000002a9581356f in KODayMatrix::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#8  0x0000002a95838a52 in KDateNavigator::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#9  0x0000002a95838b77 in DateNavigatorContainer::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#10 0x0000002a95838bea in CalendarView::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#11 0x0000002a95838c58 in CalendarView::updateView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#12 0x0000002a9582c7f0 in KOViewManager::showView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#13 0x0000002a9582e4dd in KOViewManager::showTodoView ()
   from /opt/kde3/lib64/libkorganizer.so.1
#14 0x0000002a9585b020 in KOViewManager::readSettings ()
   from /opt/kde3/lib64/libkorganizer.so.1
#15 0x0000002a9585b1f0 in CalendarView::readSettings ()
   from /opt/kde3/lib64/libkorganizer.so.1
#16 0x0000002a9585b8d4 in ActionManager::createCalendarResources ()
   from /opt/kde3/lib64/libkorganizer.so.1
#17 0x000000000040d871 in KOrganizer::init ()
#18 0x000000000040dd35 in KOrganizerApp::processCalendar ()
#19 0x000000000040df4e in KOrganizerApp::newInstance ()
#20 0x0000002a9831d40f in KUniqueApplication::processDelayed ()
   from /opt/kde3/lib64/libkdecore.so.4
#21 0x0000002a98322ab8 in KUniqueApplication::qt_invoke ()
   from /opt/kde3/lib64/libkdecore.so.4
#22 0x000000000040c7c9 in KOrganizerApp::qt_invoke ()
#23 0x0000002a98fa7f3d in QObject::activate_signal ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#24 0x0000002a992cbae7 in QSignal::signal ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#25 0x0000002a98fc3351 in QSignal::activate ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#26 0x0000002a98fc9e4e in QSingleShotTimer::event ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#27 0x0000002a98f4a5c6 in QApplication::internalNotify ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#28 0x0000002a98f499e8 in QApplication::notify ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#29 0x0000002a98310f55 in KApplication::notify ()
   from /opt/kde3/lib64/libkdecore.so.4
#30 0x0000002a98ee26e4 in QApplication::sendEvent ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#31 0x0000002a98f39b05 in QEventLoop::activateTimers ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#32 0x0000002a98ef4316 in QEventLoop::processEvents ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#33 0x0000002a98f5d4ba in QEventLoop::enterLoop ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#34 0x0000002a98f5d3b5 in QEventLoop::exec ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#35 0x0000002a98f4a6de in QApplication::exec ()
   from /usr/lib/qt3/lib64/libqt-mt.so.3
#36 0x000000000040e568 in main ()

Non 64 bit system (still SuSE 9.1) not affected.

Read the comments. The patch was applied after 3.3 was released. Either patch your 3.3 sources and recompile or wait for the next version.

Sorry my fault, didn't read all the comments in detail

I just installed KDE 3.3.1 on another AMD64 computer. And it looks like KOrganizer is still crashing on startup there. Has the patch been included for version 3.3.1 or is it only in CVS HEAD? If so it would be very nice to at least include the patch for upcoming version 3.3.2.

*** Bug 88489 has been marked as a duplicate of this bug. ***

Yup I just tried it again. The patch is applied in CVS but not in 3.3.1. Could someone please backport it to 3.3, please.

Hi Jure,
I backported the fix almost 4 weeks ago to the KDE_3_3_BRANCH. However, it didn't make it into kde 3.3.1, but it will be finally released in 3.3.2 fore sure.

Cheers,
Reinhold

Great! Thanks for info and thanks for all the hard work!