After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 566032 - Evolution crash when no hostname is set for CalDAV calendar
Evolution crash when no hostname is set for CalDAV calendar
Status: RESOLVED DUPLICATE of bug 566627
Product: evolution-data-server
Classification: Platform
Component: Calendar
2.24.x (obsolete)
Other All
: High critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[caldav]
Depends on:
Blocks:
 
 
Reported: 2008-12-30 10:15 UTC by Pascal Kreyer
Modified: 2009-03-31 17:26 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24

Attachments
Stack Trace after CalDAV calendar creation (3.54 KB, text/plain)
2008-12-30 15:33 UTC, Pascal Kreyer 		Details

Description Pascal Kreyer 2008-12-30 10:15:06 UTC 
Steps to reproduce:
1. switch to calendar view
2. right click on side pane to add new CalDAV calendar
3. put only an name for the calendar and then click on "ok" button


Stack trace:


Other information:
Comment 1 palfrey 2008-12-30 15:19:07 UTC 
Thanks for taking the time to report this bug.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 2 Pascal Kreyer 2008-12-30 15:33:18 UTC 
Created attachment 125531 [details]
Stack Trace after CalDAV calendar creation
Comment 3 Matthew Barnes 2008-12-30 15:53:25 UTC 
Solaris stack traces aren't very useful.  The crash is in the CalDAV backend in evolution-data-server.  Here's a better stack trace with line numbers:


Program received signal SIGSEGV, Segmentation fault.

+ Trace 211168

Thread 3083664272 (LWP 10062)

  • #0 caldav_server_open_calendar
    at e-cal-backend-caldav.c line 942
  • #1 caldav_do_open
    at e-cal-backend-caldav.c line 1874
  • #2 e_cal_backend_sync_open
    at e-cal-backend-sync.c line 186
  • #3 _e_cal_backend_open
    at e-cal-backend-sync.c line 706
  • #4 e_cal_backend_open
    at e-cal-backend.c line 643
  • #5 impl_Cal_open
    at e-data-cal.c line 80
  • #6 _ORBIT_skel_small_GNOME_Evolution_Calendar_Cal_open
    at Evolution-DataServer-Calendar-common.c line 44
  • #7 ORBit_POAObject_invoke
    at poa.c line 1148
  • #8 ORBit_OAObject_invoke
    at orbit-adaptor.c line 340
  • #9 ORBit_small_invoke_adaptor
    at orbit-small.c line 846
  • #10 ORBit_POAObject_handle_request
    at poa.c line 1357
  • #11 ORBit_POAObject_invoke_incoming_request
    at poa.c line 1427
  • #12 giop_thread_queue_process
    at giop.c line 792
  • #13 giop_request_handler_thread
    at giop.c line 502
  • #14 g_thread_pool_thread_proxy
    at gthreadpool.c line 265
  • #15 g_thread_create_proxy
    at gthread.c line 635
  • #16 start_thread
    at pthread_create.c line 297
  • #17 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 130 

And most importantly...

(gdb) p priv->uri
$2 = 0x9484dd8 "https:/"
(gdb) p message
$1 = (SoupMessage *) 0x0

So libsoup didn't like the invalid URI and returned a NULL message.
We then dereference the message pointer without checking for NULL.
Comment 4 Akhil Laddha 2009-02-04 04:41:12 UTC 
removing needinfo
Comment 5 Milan Crha 2009-03-31 17:26:57 UTC 
Thanks for taking the time to report this bug.
This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade.


*** This bug has been marked as a duplicate of 566627 ***