On 2012-01-21T11:25:39, David Bremner wrote:
>On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto
>wrote:
>> g_mime_init already check for multiple initializations.
>> ---
>> lib/index.cc |4
>> lib/message-file.c |4
>
>I'm going to
On 2012-01-21T11:25:39, David Bremner wrote:
On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto kaz@gmail.com wrote:
g_mime_init already check for multiple initializations.
---
lib/index.cc |4
lib/message-file.c |4
I'm going to mark this obsolete for now
On Fri, Jan 20, 2012 at 12:26:05PM +0100, Justus Winter wrote:
> Quoting Patrick Totzke (2012-01-20 11:40:41)
> >I suspect you don't split the config value and thus afew ended up
> >with a false tag "new;". its just cosmetics but nevertheless..
>
> Hm, actually it does exactly that:
>
> def
On Fri, Jan 20, 2012 at 12:26:05PM +0100, Justus Winter wrote:
Quoting Patrick Totzke (2012-01-20 11:40:41)
I suspect you don't split the config value and thus afew ended up
with a false tag new;. its just cosmetics but nevertheless..
Hm, actually it does exactly that:
def
On Tue, Jan 17, 2012 at 12:56:39AM +0100, Thomas Jost wrote:
> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.
I tested this with gmime
On Tue, Jan 17, 2012 at 12:56:39AM +0100, Thomas Jost wrote:
There are lots of API changes in gmime 2.6 crypto handling. By adding
preprocessor directives, it is however possible to add gmime 2.6 compatibility
while preserving compatibility with gmime 2.4 too.
I tested this with gmime 2.4.31
On 2011-12-31T00:55:59, David Bremner wrote:
>On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto
>wrote:
>> g_mime_init already check for multiple initializations.
>> ---
>> lib/index.cc |4
>> lib/message-file.c |4
>> 2 files c
As reported in
id:"CAEbOPGyuHnz4BPtDutnTPUHcP3eYcRCRkXhYoJR43RUMw671+g at mail.gmail.com"
sometimes gmime try to access a NULL pointer, e.g. g_mime_iconv_open()
try to access iconv_cache that is NULL if g_mime_init() is not called.
This cause notmuch to segfault when calling gmime functions.
I'm resending the PATCH 2/2 as a standalone, leaving the matter of
removing the checks for the future. I added a more detailed commit too.
This is the only patch needed to fix the segfault I reported.
Kazuo Teramoto (1):
lib: call g_mime_init() from notmuch_database_open()
lib/database.cc
On 2011-12-30T23:16:47, Patrick Totzke wrote:
>It seeminly doesn't break things either and I'm all in favour of doing
>things right?.
And talking about doing things right, we probably need to call
g_mime_shutdown() too, one for every time we call g_mime_init(). I will
send a patch after I do
We need to call g_mime_init to correct initialize the structures needed
by gmime before using it.
---
lib/database.cc |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index d11dfaf..07ca3fd 100644
--- a/lib/database.cc
+++
g_mime_init already check for multiple initializations.
---
lib/index.cc |4
lib/message-file.c |4
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/lib/index.cc b/lib/index.cc
index d8f8b2b..6764929 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -419,12
don't need to explicit
check for an already initialized gmime.
This make possible to call g_mime_init again in lib/database.cc and this
call really solve the OP segmentation fault in python bindings.
Kazuo Teramoto (2):
lib: Remove unnecessary checks when calling g_mime_init
lib: call g_mime_init
this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, 'id:4efc743a.3060...@april.org')
for t in q_new.search_threads():
pass
Message-ID
of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, 'id:4efc743a.3060...@april.org')
for t in q_new.search_threads():
pass
4EFC743A
of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, 'id:4efc743a.3060...@april.org')
for t in q_new.search_threads():
pass
4EFC743A
don't need to explicit
check for an already initialized gmime.
This make possible to call g_mime_init again in lib/database.cc and this
call really solve the OP segmentation fault in python bindings.
Kazuo Teramoto (2):
lib: Remove unnecessary checks when calling g_mime_init
lib: call g_mime_init
g_mime_init already check for multiple initializations.
---
lib/index.cc |4
lib/message-file.c |4
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/lib/index.cc b/lib/index.cc
index d8f8b2b..6764929 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -419,12
We need to call g_mime_init to correct initialize the structures needed
by gmime before using it.
---
lib/database.cc |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index d11dfaf..07ca3fd 100644
--- a/lib/database.cc
+++
On 2011-12-30T23:16:47, Patrick Totzke wrote:
It seeminly doesn't break things either and I'm all in favour of doing
things right™.
And talking about doing things right, we probably need to call
g_mime_shutdown() too, one for every time we call g_mime_init(). I will
send a patch after I do some
On 2011-12-31T00:55:59, David Bremner wrote:
On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto kaz@gmail.com wrote:
g_mime_init already check for multiple initializations.
---
lib/index.cc |4
lib/message-file.c |4
2 files changed, 0 insertions(+), 8 deletions
I'm resending the PATCH 2/2 as a standalone, leaving the matter of
removing the checks for the future. I added a more detailed commit too.
This is the only patch needed to fix the segfault I reported.
Kazuo Teramoto (1):
lib: call g_mime_init() from notmuch_database_open()
lib/database.cc
As reported in
id:caebopgyuhnz4bptdutntpuhcp3eycrcrkxhyojr43rumw67...@mail.gmail.com
sometimes gmime try to access a NULL pointer, e.g. g_mime_iconv_open()
try to access iconv_cache that is NULL if g_mime_init() is not called.
This cause notmuch to segfault when calling gmime functions.
Calling
ch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
-- next part --
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 201 bytes
Desc: not available
URL:
<http://notmuchma
ut gmime or
notmuch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
-- next part --
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 202 bytes
Desc: not available
URL:
<http://notmuchma
ut gmime or
notmuch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
-- next part --
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, '
On 2011-12-16T14:01:42, David Bremner wrote:
>Also, there is the question of common text like search-terms, which
>could be included in every page, or maybe contained in man notmuch.
>
What about continuing the git-foo analogy and creating a notmuch search
terms page. Like how git-log page
On 2011-12-16T08:28:37, Patrick Totzke wrote:
>
>Hmm.. Is anybody using Arch willing to look into this? Or can anybody
>suggest a painless and quick way for me to set up an Arch installation
>in a Virtualbox or so to be able to reproduce this?
>
I'm using Arch and I have debugging log. I'm using
On 2011-12-16T08:28:37, Patrick Totzke wrote:
Hmm.. Is anybody using Arch willing to look into this? Or can anybody
suggest a painless and quick way for me to set up an Arch installation
in a Virtualbox or so to be able to reproduce this?
I'm using Arch and I have debugging log. I'm using the
On 2011-12-16T14:01:42, David Bremner wrote:
Also, there is the question of common text like search-terms, which
could be included in every page, or maybe contained in man notmuch.
What about continuing the git-foo analogy and creating a notmuch search
terms page. Like how git-log page reference
an universal tagging solution with some fancy features
From: Kazuo Teramoto <kaz@gmail.com>
In-Reply-To:
On 2011-12-14T08:42:36, Justus Winter wrote:
>I'd like to introduce my initial tagging approach, afew tags:
>
>https://github.com/teythoon/afew
>
Very good!
an universal tagging solution with some fancy features
From: Kazuo Teramoto kaz@gmail.com
In-Reply-To: e1ramig-0003si...@thinkbox.jade-hamburg.de
On 2011-12-14T08:42:36, Justus Winter wrote:
I'd like to introduce my initial tagging approach, afew tags:
https://github.com/teythoon/afew
Hi!
Following an alot bug report [1] I created a small python script that
causes a segmentation fault in notmuch:
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new =
Hi!
Following an alot bug report [1] I created a small python script that
causes a segmentation fault in notmuch:
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new =
34 matches
Mail list logo
