[tex-live] crash using bibtex on large .bib files

Vincent Danen vdanen at redhat.com
Tue Aug 4 22:42:29 CEST 2009

Hello, texlive developers.

I've got a quick question/report to make regarding how bibtex crashes on
large .bib files.  This was originally reported to Debian [1] a few
months back and a bug report is open in the Red Hat bugzilla [2] as
well, including the reproducer to trigger the issue.

There is a string pool size limit per one reallocation that is defined
to 65000, and a large .bib file will exceed this.  The result is a

[vdanen at odvfc10]~/tmp/bibtex-crash% bibtex livre_fp.aux 
This is BibTeX, Version 0.99c (Web2C 7.5.6)
The top-level auxiliary file: livre_fp.aux
A level-1 auxiliary file: ch_introduction.aux
A level-1 auxiliary file: ch_definitions.aux
A level-1 auxiliary file: ch_formats.aux
A level-1 auxiliary file: ch_smallalgs.aux
A level-1 auxiliary file: ch_fma.aux
A level-1 auxiliary file: ch_summation.aux
A level-1 auxiliary file: ch_languages.aux
A level-1 auxiliary file: ch_algorithms.aux
A level-1 auxiliary file: ch_hard.aux
A level-1 auxiliary file: ch_soft.aux
A level-1 auxiliary file: ch_elemfun.aux
A level-1 auxiliary file: ch_correctrounding.aux
A level-1 auxiliary file: ch_certifying.aux
A level-1 auxiliary file: ch_extending.aux
A level-1 auxiliary file: ch_nttools.aux
The style file: plain.bst
Database file #1: biblio.bib
*** glibc detected *** bibtex: realloc(): invalid next size: 0x08afbd08 ***
======= Backtrace: =========
======= Memory map: ========
00327000-00328000 r-xp 00327000 00:00 0          [vdso]
00588000-005a8000 r-xp 00000000 fd:00 73972      /lib/ld-2.9.so
005a9000-005aa000 r--p 00020000 fd:00 73972      /lib/ld-2.9.so
005aa000-005ab000 rw-p 00021000 fd:00 73972      /lib/ld-2.9.so
005ad000-0071b000 r-xp 00000000 fd:00 73979      /lib/libc-2.9.so
0071b000-0071d000 r--p 0016e000 fd:00 73979      /lib/libc-2.9.so
0071d000-0071e000 rw-p 00170000 fd:00 73979      /lib/libc-2.9.so
0071e000-00721000 rw-p 0071e000 00:00 0 
00723000-0074a000 r-xp 00000000 fd:00 76570      /lib/libm-2.9.so
0074a000-0074b000 r--p 00026000 fd:00 76570      /lib/libm-2.9.so
0074b000-0074c000 rw-p 00027000 fd:00 76570      /lib/libm-2.9.so
00755000-00767000 r-xp 00000000 fd:00 388387     /usr/lib/libkpathsea.so.4.0.0
00767000-00768000 rw-p 00012000 fd:00 388387     /usr/lib/libkpathsea.so.4.0.0
00768000-0076a000 rw-p 00768000 00:00 0 
050d5000-050e2000 r-xp 00000000 fd:00 76578      /lib/libgcc_s-4.3.2-20081105.so.1
050e2000-050e3000 rw-p 0000c000 fd:00 76578      /lib/libgcc_s-4.3.2-20081105.so.1
08047000-08060000 r-xp 00000000 fd:00 389943     /usr/bin/bibtex
08060000-08061000 rw-p 00019000 fd:00 389943     /usr/bin/bibtex
08061000-08129000 rw-p 08061000 00:00 0 
08af1000-08cd0000 rw-p 08af1000 00:00 0          [heap]
b7f00000-b7f21000 rw-p b7f00000 00:00 0 
b7f21000-b8000000 ---p b7f21000 00:00 0 
b8025000-b80df000 rw-p b8025000 00:00 0 
b80f1000-b80f4000 rw-p b80f1000 00:00 0 
bfa4b000-bfa60000 rw-p bffeb000 00:00 0          [stack]
zsh: abort      bibtex livre_fp.aux

This affects texlive and tetex both.  Our maintainer upped the string
pool size limit from 65,000 to 650,000 but obviously that isn't a
sufficient fix; it's just a work-around.

What we would like to know is if this is a simple crash or if there are
some security ramifications here.  This could be a considerd a simple
crash, or it could be a memory corruption issue -- I honestly don't know
which it might be.  Do you feel this is a security issue that needs to
be addressed, or merely a bug that needs correcting?

I'm not subscribed to the list, so if you could kindly keep my cc'd on
any messages I would appreciate it.  It looks as though the Debian
maintainers were going to be forwarding this upstream, but I can't find
any evidence that they actually every did, so I'm not sure if you are
already aware of this.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520920
[2] https://bugzilla.redhat.com/show_bug.cgi?id=492136

Vincent Danen / Red Hat Security Response Team 

More information about the tex-live mailing list