Bug 1023009

Summary: [abrt] calendar-1.26-7.20110531cvs.fc20: isnow: Process /usr/bin/calendar was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Branislav Blaškovič <bblaskov>
Component: calendarAssignee: David Cantrell <dcantrell>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: bblaskov, dcantrell
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:9bbd5b1d70d5f414ac1ae90fe1dd586e52c3f839
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-23 15:14:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Branislav Blaškovič 2013-10-24 12:53:57 UTC 
Description of problem:
I've run:
$ calendar -f calendar.ics

Version-Release number of selected component:
calendar-1.26-7.20110531cvs.fc20

Additional info:
reporter:       libreport-2.1.8
backtrace_rating: 4
cmdline:        calendar -f calendar.ics
crash_function: isnow
executable:     /usr/bin/calendar
kernel:         3.11.4-301.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (2 frames)
 #0 isnow at day.c:405
 #1 cal at io.c:233
Comment 1 Branislav Blaškovič 2013-10-24 12:54:01 UTC 
Created attachment 815765 [details]
File: backtrace
Comment 2 Branislav Blaškovič 2013-10-24 12:54:04 UTC 
Created attachment 815766 [details]
File: cgroup
Comment 3 Branislav Blaškovič 2013-10-24 12:54:07 UTC 
Created attachment 815767 [details]
File: core_backtrace
Comment 4 Branislav Blaškovič 2013-10-24 12:54:14 UTC 
Created attachment 815768 [details]
File: dso_list
Comment 5 Branislav Blaškovič 2013-10-24 12:54:17 UTC 
Created attachment 815769 [details]
File: environ
Comment 6 Branislav Blaškovič 2013-10-24 12:54:20 UTC 
Created attachment 815770 [details]
File: exploitable
Comment 7 Branislav Blaškovič 2013-10-24 12:54:24 UTC 
Created attachment 815771 [details]
File: limits
Comment 8 Branislav Blaškovič 2013-10-24 12:54:27 UTC 
Created attachment 815772 [details]
File: maps
Comment 9 Branislav Blaškovič 2013-10-24 12:54:33 UTC 
Created attachment 815773 [details]
File: open_fds
Comment 10 Branislav Blaškovič 2013-10-24 12:54:36 UTC 
Created attachment 815774 [details]
File: proc_pid_status
Comment 11 Branislav Blaškovič 2013-10-24 12:54:39 UTC 
Created attachment 815775 [details]
File: var_log_messages
Comment 12 David Cantrell 2013-10-25 12:16:59 UTC 
Can you attach the calendar.ics file you were using when running calendar?
Comment 14 David Cantrell 2014-06-18 13:27:24 UTC 
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?
Comment 15 Branislav Blaškovič 2014-06-19 08:38:56 UTC 
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.
Comment 16 David Cantrell 2014-06-23 15:14:55 UTC 
I'm not really interested in changing up their parser too much because maintaining that patchset will just be more work.