messageHeader results in segfault

[romanofski]

I've tried composing messages with more than just a subject and it ended in a core dump. Basically this:

Mail <$> messageHeader "Subject" m <> messageHeader "To" m<> messageHeader "From" m

ends up in a segfault. Maybe I'm referencing the wrong headers? I did not manage to get a back trace, but I'm kind of hoping you might know where the problem lies?

[frasertweedale]

On Fri, Jul 21, 2017 at 11:52:21AM +0000, Roman Joost wrote:

I've tried composing messages with more than just a subject and it ended in a core dump. Basically this:

Mail <$> messageHeader "Subject" m <> messageHeader "To" m<> messageHeader "From" m

ends up in a segfault. Maybe I'm referencing the wrong headers? I did not manage to get a back trace, but I'm kind of hoping you might know where the problem lies?

I'll try and look into it over weekend. No obvious reason jumping out at me but FFI can be tricksy.

[frasertweedale]

On Fri, Jul 21, 2017 at 11:52:21AM +0000, Roman Joost wrote:

I've tried composing messages with more than just a subject and it ended in a core dump. Basically this:

Mail <$> messageHeader "Subject" m <> messageHeader "To" m<> messageHeader "From" m

ends up in a segfault. Maybe I'm referencing the wrong headers? I did not manage to get a back trace, but I'm kind of hoping you might know where the problem lies?

@romanofski can you please post the complete example program that triggers the segfault? (Add it to the purebred repo if you think it's appropriate).

[romanofski]

I've tried to get a reproducer, but doing exactly what I've tried above by hacking the Main.hs on hs-notmuch yields no problems. It was late yesterday, maybe if I look back at my code it'll turn out that it was just a simple PEBKAC. I see if I can reproduce it again on my purebred fork.

[romanofski]

See https://github.com/romanofski/purebred/commit/f00be4bba18fd1c3585069e40aa2b4dea2907ff2 for a reproducer. I'm compiling with:

• notmuch-devel-0.24.2-1.fc26.x86_64
• libtalloc-devel-2.1.9-1.fc26.x86_64

I'd be interested in how to debug the issue. I'll continue looking into it what is going wrong, if I have time.

[frasertweedale]

On Fri, Jul 21, 2017 at 07:38:14PM -0700, Roman Joost wrote:

I've tried to get a reproducer, but doing exactly what I've tried above by hacking the Main.hs on hs-notmuch yields no problems. It was late yesterday, maybe if I look back at my code it'll turn out that it was just a simple PEBKAC. I see if I can reproduce it again on my purebred fork.

I've got a reproducer. It's not deterministic but it can be reproduced quite reliably. I think the GC is nuking something it shouldn't. The use of talloc's heirarcical allocation makes this particularly tricky :)

[romanofski]

I'd be interested in how you debug it. So far all my attempts on getting debug symbols have failed.

[frasertweedale]

On Fri, Jul 21, 2017 at 11:15:41PM -0700, Roman Joost wrote:

I'd be interested in how you debug it. So far all my attempts on getting debug symbols have failed.

Yeah it's bloody hard... a bit of printf debugging combined with gdb to get some introspection into what's happening in the notmuch lib.

I tracked down where the segfault is coming, and there will be a small change to API to handle the error case properly. But why it occurs at all needs more investigation.

At first I was suspicious of GC cleaning something up underneath the program (because talloc) but now I am not so sure.

I'll push the notmuch update shortly. But you will probably see the symptoms of the underlying bug once the program is no longer crashing :)

[frasertweedale]

On Fri, Jul 21, 2017 at 11:15:41PM -0700, Roman Joost wrote:

I'd be interested in how you debug it. So far all my attempts on getting debug symbols have failed.

@romanofski purebred-mua/hs-notmuch:fcec008

[romanofski]

Nice! Thanks for the fix!

[romanofski]

related: [PATCH] lib: return "" rather than NULL from notmuch_thread_get_authors