[systemd-devel] journalctl segfault in gcrypt code

[Lennart Poettering]

On Mon, 15.10.12 23:02, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> 
> On Mon, Oct 15, 2012 at 10:01:31PM +0200, Lennart Poettering wrote:
> > On Sat, 13.10.12 17:59, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> > 
> > > Hi,
> > > 
> > > I'm having trouble debugging the problem below. Maybe somebody has an
> > > idea...  When I run journalctl, on a specific (large) set of journal
> > > logs, it segfaults. Always in the same place.
> > 
> > Hmm, I have not see this so far. Have you tried valgrind on this?
> Yeah, but it didn't say anything useful.
> 
> ==32666== Invalid write of size 1
> ==32666==    at 0x5076B12: md_close (md.c:771)
> ==32666==    by 0x41282D: journal_file_close (journal-file.c:109)
> ==32666==    by 0x4110FE: sd_journal_close (sd-journal.c:1620)
> ==32666==    by 0x406DEA: main (journalctl.c:990)
> ==32666==  Address 0x402d000 is not stack'd, malloc'd or (recently) free'd
> ==32666== 
> ==32666== 
> ==32666== Process terminating with default action of signal 11 (SIGSEGV)
> ==32666==  Access not within mapped region at address 0x402D000
> ==32666==    at 0x5076B12: md_close (md.c:771)
> ==32666==    by 0x41282D: journal_file_close (journal-file.c:109)
> ==32666==    by 0x4110FE: sd_journal_close (sd-journal.c:1620)
> ==32666==    by 0x406DEA: main (journalctl.c:990)
> ==32666==  If you believe this happened as a result of a stack
> ==32666==  overflow in your program's main thread (unlikely but
> ==32666==  possible), you can try to increase the size of the
> ==32666==  main thread stack using the --main-stacksize= flag.
> ==32666==  The main thread stack size used in this run was 8388608.
> --32666-- Caught __NR_exit; running __libc_freeres()
> --32666-- Discarding syms at 0x33981230-0x3398887c in /usr/lib64/libnss_files-2.16.90.so due to munmap()
> ==32666== 
> ==32666== HEAP SUMMARY:
> ==32666==     in use at exit: 17,860,820 bytes in 57 blocks
> ==32666==   total heap usage: 73,740 allocs, 73,683 frees, 33,511,230,790 bytes allocated
> 
> When I compile with --disable-gcrypt, everything seems to work fine
> (no valgrind warnings). So the problem seems related to gcrypt,
> but I can't see anything wrong by looking at the code.

I wonder if valgrind actually tracks mmap()s properly. I wonder if the
mmap_cache is mistakingly unmapping a map it shoudln't. It might be
worth loking for munmap() invocations in mmap-cache.c and printing the
range unmapped and comparing that with the address valgrind mentions as
freed.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.