[systemd-devel] journalctl segfault in gcrypt code

[Zbigniew Jędrzejewski-Szmek]

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.

Zbyszek