Bad ECalComponent somehow wound up in a TrayIconData structure, but the structure was freshly created moments before, and the ECalComponent passed to display_notification() looks valid:

+ Trace 209732

So somehow between line 1519:

        tray_data->comp = g_object_ref (e_cal_component_clone (comp));

and line 1551:

        open_alarm_dialog (tray_data);

something got corrupted.

Could be same issue as bug #557616, but I'm still looking for the event causing this (I think it depends on the event, even no clue for that yet).

I found this today, do not know if it is same or not.


Distribution: openSUSE 11.1 (x86_64)
Gnome Release: 2.24.1 2008-12-03 (SUSE)
BugBuddy Version: 2.24.1

System: Linux 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 10502000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Glider
Icon Theme: Tango

Memory status: size: 502521856 vsize: 502521856 resident: 20795392 share: 15421440 rss: 20795392 rss_rlim: 18446744073709551615
CPU usage: start_time: 1233057321 rtime: 30 utime: 23 stime: 7 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/lib64/evolution-alarm-notify'

[?1034h[Thread debugging using libthread_db enabled]
[New Thread 0x7f9df4c22950 (LWP 26684)]
[New Thread 0x7f9df7468950 (LWP 26606)]
0x00007f9dfb0f85af in __libc_waitpid (pid=26691, stat_loc=0x7fff11627450, 
    options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:41
	in ../sysdeps/unix/sysv/linux/waitpid.c

+ Trace 211928

Current language:  auto; currently asm
Current language:  auto; currently c
The program is running.  Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal]


----------- .xsession-errors (360 sec old) ---------------------
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005b0 specified for 0x3a005b5 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005b0 specified for 0x3a005b5 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005b0 specified for 0x3a005c6 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005b0 specified for 0x3a005c6 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005b0 specified for 0x3a005b5 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005b0 specified for 0x3a005c6 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005d5 specified for 0x3a005da (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005d5 specified for 0x3a005da (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005d5 specified for 0x3a005da (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005e8 specified for 0x3a005ed (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005e8 specified for 0x3a005ed (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005e8 specified for 0x3a005ed (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005fb specified for 0x3a00600 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3a005fb specified for 0x3a00600 (Incoming M).
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x3809bd1 specified for 0x3809dd4 (Delete acc).
--------------------------------------------------

1549:	open_alarm_dialog (tray_data);
1550:	gtk_window_stick (GTK_WINDOW (alarm_notifications_dialog->dialog));
1551: } else {

That seems like the same issue, only shown a bit later. Are you able to reproduce it reliably, please?

Nope, not consistently. Is there anything you want me to try? or when it happens again?

The code suggests the problem is that the alarm_notification_dialog is NULL at the moment of the call, or some broken pointer. I do not expect you've this running under gdb and can check for that, though. But if you can make some observation, like whether you have shown the notification dialog already, when it crashes, or whether it was shown at all, or this is the first attempt to show it, then that may influence it too, maybe.

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

last dupe in 2.28.x

I would like to ask whether is anyone able to reproduce this in actual development version (coming 2.91.92) or the actual stable (2.32.2), though the git master is preferable, because it'll became stable version soon. Thanks in advance.

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!