Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Apr 2011 14:42:44 +0100
From:      David Woodhouse <dwmw2@infradead.org>
To:        Matthias Apitz <guru@unixarea.de>
Cc:        gnome@freebsd.org, evolution-list@gnome.org
Subject:   Re: [Evolution] evolution-2.32.1 (FreeBSD HEAD) && calendar not working
Message-ID:  <1303998164.2912.123.camel@macbook.infradead.org>
In-Reply-To: <20110428131312.GA17412@sh4-5.1blu.de>
References:  <1303819852.6417.100.camel@macbook.infradead.org> <20110426122621.GB2913@sh4-5.1blu.de> <1303821491.6417.108.camel@macbook.infradead.org> <20110426135234.GA1336@sh4-5.1blu.de> <1303827472.6417.113.camel@macbook.infradead.org> <20110426145506.GA20059@sh4-5.1blu.de> <1303831016.6417.132.camel@macbook.infradead.org> <20110426213920.GA15678@sh4-5.1blu.de> <20110427062214.GA1159@sh4-5.1blu.de> <20110428073857.GB4359@sh4-5.1blu.de> <20110428131312.GA17412@sh4-5.1blu.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2011-04-28 at 15:13 +0200, Matthias Apitz wrote:
> 
> 
> but read_config () can't find the file /usr/local/etc/connector.conf
> and just returns (line 1412) to e2k_autoconfig_lookup_option() which
> makes the g_hash_table_lookup() crashing later;

I don't understand. The *first* think that read_config() does, before it
even tries to open the connector.conf file, is:

        config_options = g_hash_table_new (e2k_ascii_strcase_hash,
                                            e2k_ascii_strcase_equal);

So config_options should *never* be NULL and the call to
g_hash_table_lookup() should not crash.

When it crashes and it's sitting at a gdb prompt, can you type
 up
 up
 p config_options

> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 29804300 (LWP 100647/initial thread)]
> 0x29f582eb in e2k_http_parse_date (
>     date=0x29b31b00 "Thu, 28 Apr 2011 13:09:20 GMT") at _ctype.h:125
> 125             return (_c < 0 || _c >= 128) ? 0 :
> (gdb) 
> 
> (I don't understand why the gdb is presenting the code as at
> _ctype.h:125 ???)

Got a backtrace for this one too? At first glance I have no idea how any
of the code in the e2k_http_parse_date() function would end up using
ctype functions either.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1303998164.2912.123.camel>