Red Hat Bugzilla – Bug 1023009
[abrt] calendar-1.26-7.20110531cvs.fc20: isnow: Process /usr/bin/calendar was killed by signal 11 (SIGSEGV)
Last modified: 2014-06-23 11:14:55 EDT
Description of problem:
$ calendar -f calendar.ics
Version-Release number of selected component:
cmdline: calendar -f calendar.ics
runlevel: N 5
Thread no. 1 (2 frames)
#0 isnow at day.c:405
#1 cal at io.c:233
Created attachment 815765 [details]
Created attachment 815766 [details]
Created attachment 815767 [details]
Created attachment 815768 [details]
Created attachment 815769 [details]
Created attachment 815770 [details]
Created attachment 815771 [details]
Created attachment 815772 [details]
Created attachment 815773 [details]
Created attachment 815774 [details]
Created attachment 815775 [details]
Can you attach the calendar.ics file you were using when running calendar?
Ah, ok, so the calendar(1) command cannot read .ics files. It reads its own configuration file. See the man page. It's sort of a special format. You use the #include directive to import common calendars in /usr/share/calendar. But then you define your own events, one event per line, with a date (supports a variety of formats), then one or more tab characters, then a description of the event.
Segfaulting is ugly, but you're also not losing data. calendar doesn't write anything, it just reads. The best we can hope for is detection of .ics files and exiting with an error indicating the file format is not supported. I have been working on a patch to do that, but it's ugly. And it diverges significantly from upstream. Since I rely on regularly importing code from OpenBSD, I try to keep my patch set small. And I'm not really liking where this patch is taking me.
How important is this to you? Consider calendar(1) will never support .ics files anyway, do you care?
I don't really need it it just ugly that it is segfaulting.
If you don't want to patch, just close it as WONTFIX.
I'm not really interested in changing up their parser too much because maintaining that patchset will just be more work.