Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 May 2011 12:45:29 +0200
From:      Matthias Apitz <guru@unixarea.de>
To:        David Woodhouse <dwmw2@infradead.org>
Cc:        gnome@freebsd.org, evolution-list@gnome.org
Subject:   Re: [Evolution] evolution-2.32.1 (FreeBSD HEAD) && calendar not working
Message-ID:  <20110504104528.GA24928@sh4-5.1blu.de>
In-Reply-To: <1304502723.6400.114.camel@macbook.infradead.org>
References:  <20110428073857.GB4359@sh4-5.1blu.de> <20110428131312.GA17412@sh4-5.1blu.de> <1303998164.2912.123.camel@macbook.infradead.org> <20110428140106.GA5664@sh4-5.1blu.de> <1303999409.2912.129.camel@macbook.infradead.org> <20110428145451.GA25158@sh4-5.1blu.de> <1304003620.4772.16.camel@macbook.infradead.org> <20110429084846.GA2763@sh4-5.1blu.de> <20110504094447.GA30294@sh4-5.1blu.de> <1304502723.6400.114.camel@macbook.infradead.org>

next in thread | previous in thread | raw e-mail | index | archive | help
El día Wednesday, May 04, 2011 a las 10:52:03AM +0100, David Woodhouse escribió:

> On Wed, 2011-05-04 at 11:44 +0200, Matthias Apitz wrote:
> > I have inserted some fprintf's in read_conf() to print in hex the memory
> > of the hash_table (see below); it matches what gdb reads about the
> > hash_table (values marked with ^^^);  
> 
> Was that *right* after the g_hash_table_new() call?

No, but now I added additional prints right after the call of
g_hash_table_new(), it is not buggered in read_conf(): 

Server is up and running...
DEBUG e2k-autoconfig: entered read_config()
DEBUG e2k-autoconfig: right after g_hash_table_new() 
DEBUG e2k-autoconfig: read_config() config_options=2995dd50:
00000008 00000007 00000007 00000000 00000000 2995f5e0 29ed1f3b 29ed1f09 
DEBUG e2k-autoconfig: read_config() return, fd=-1
DEBUG e2k-autoconfig: read_config() config_options=2995dd50:
00000008 00000007 00000007 00000000 00000000 2995f5e0 29ed1f3b 29ed1f09 

> That would seem to imply that your hash table was buggered from the very
> beginning. If you really can't get gdb to work properly and use a
> hardware watchpoint, try littering similar printfs all the way through
> g_hash_table_new() so you can find out why it isn't being set to the
> function you *provided*.

will do ...

	matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <guru@unixarea.de> - w http://www.unixarea.de/



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