2

I'M still trying to make biber work after switching my bibtex .tex files to UTF-8 and importing some new entries.

INFO - This is Biber 1.9
INFO - Config file is '/Users/myname/.biber.conf'
INFO - Logfile is 'Diss.blg'
INFO - Reading 'Diss.bcf'
INFO - Using all citekeys in bib section 0
INFO - Processing section 0
INFO - Looking for bibtex format file 'references.bib' for section 0
INFO - Decoding LaTeX character macros into UTF-8
INFO - Found BibTeX data source 'references.bib'
WARN - Overwriting field 'year' with year value from field 'date' for entry '1991'
WARN - Overwriting field 'year' with year value from field 'date' for entry 'Thomas-Vielma2008'
FATAL - Caught signal: SEGV
Likely your .bib has a very bad entry which causes libbtparse to crash:

I already cleaned a lot in my bibtex file, but I still don't get a bibliography in my pdf, cause biber seems to have a problem with something, but in the .blg log file I don't find a hint on the problematic line.

  • Is there another log file which could tell me what's going wrong here?
  • How can I fix the problem as quick as possible?
  • It seems that biber processes all entries, even if they are not cited - is this correct?
  • Is there an option for biber which makes it less "picky" about the entries and still produces at least a bibliography for those who work?
  • In the .bib file there are about 3000 entries, so testing by hand for each one is not an option. Is there a way to automate this testing process or print out the last processed entry?
MostlyHarmless
  • 12,160
  • As long as we cannot see the data, it is basically impossible to help or advise. – daleif Feb 24 '15 at 11:22
  • @daleif: thank you for your comment. Neither can I nor do I want to publish my complete references list here online. So my question is: how can I reduce the number of possible entries. Is there no option or verbose log for biber which can at least tell me which line in the .bib file or which entry caused this failure? – MostlyHarmless Feb 24 '15 at 11:34
  • I usually do not use biber. So your only chance is to make a new empty bib file, and the manually transfer each items manually, recompiling each time. – daleif Feb 24 '15 at 11:53
  • 2
    Comment one half of your bib-file. You can also try the option --nodieonerror – Ulrike Fischer Feb 24 '15 at 11:59
  • As suggested, don't test one-by-one. Test half then the other half. Repeat for the problematic half until you find the problem. – cfr Feb 24 '15 at 13:08
  • You have INFO - Using all citekeys in bib section 0. So you are using them all with something like \nocite{*}? – cfr Feb 24 '15 at 13:11
  • @cfr: thanks a lot for this comment! Indeed a copy of the nocite command had slipped in my tex file... So I'm right, that biber/biblatex normally only would process the items that are cited, right? – MostlyHarmless Feb 24 '15 at 15:37
  • @Martin I think so. I'm not sure but that's what it seems to me that it seems to do. – cfr Feb 24 '15 at 16:06
  • 1
    With exported .bib files very often the abstract is the culprit (sometimes other non standard fields are also non-well formed, in your other MWE you had a M3 field). Maybe you can suppress the abstract being exported - it would be better to make sure only the fields you really need are exported and well formed. A SEGV is really nasty and notoriously hard to debug, so the half-half method is probably the only way to isolate the troublemaker. – moewe Feb 24 '15 at 18:46
  • @cfr: as I am lazy (and the bib file very large) I found a semi-automatic method (see my answer below) for finding the problematic entry. My programming skills in bash are very very limited, but it worked. :-) – MostlyHarmless Feb 25 '15 at 05:05
  • @UlrikeFischer: thanks! I was too lazy to do the splitting of the bibliography by hand and found a semi-automated way for solving the problem (see my answer below) – MostlyHarmless Feb 25 '15 at 05:06
  • 1
    This error may also appear if the .bib file was generated from Zotero and an author field contains only a first name (probably resulting in excessive commas in the Author field like shown in the accepted answer). – ngmir Nov 08 '21 at 14:21

2 Answers2

11

Systematic automated approach for finding the problematic entry

It was suggested to eliminate half of the bibtex entries and this way reduce the number of suspects further.

As I am lazy (and would not know how to do that in an easy way), I used the following semi-automatic method (all done in Terminal in MacOS X 10.6:

  • created a copy of my .bib file in an empty directory
  • mkdir bibentries
    created a new directory named bibentries
  • split -p @ -a 4 mybibfilename.bib ./bibentries/
    split my bib file into one file per entry, all created in the bibentries directory
  • cd bibentries
    switched to bibentries directory
  • for old in *; do mv $old $old.bib; done
    added extension .bib to all files in bibentries directory
  • rm -rfbiber --cache``
    cleared biber cache
  • sh ~/bin/batchbiber.sh
    run biber on all files (see bash script below)

Script batchbiber.sh (located in my home path ~/bin/ )

(If you don't have ~/bin/ in your home path, you can create it using mkdir bin.)

#!/bin/bash
# script processes all .bib files in current direcory with "biber --tool"
let n=0 # counter for files
# count files and print their number
for j in *.bib; do 
let n=n+1
done
echo $n bibtex files found
# process files one by one with biber --tool
for j in *.bib; do 
biber --tool $j
done
  • grep -i SEGV *.blg
    search for error message in the created .blg files

... and bingo, I found one entry with this error and easily spotted the problem: one excessive comma:

 Author                   = {Liao,Hongmei and Coyle, ,Thomas W.},

:-)

Guido Vanden Wyngaerd
  • 240
MostlyHarmless
  • 12,160
  • 2
    Neat idea - lazyness is useful ;-). With your example I created a faulty test bib. Running biber --tool --debug bib.bib gave me in the resulting bib.bib.blg as last lines [496] bibtex.pm:1029> DEBUG - Parsing namestring 'Coyle, ,Thomas W.' [496] bibtex.pm:94> FATAL - Caught signal: SEGV and so identified the faulty entry. – Ulrike Fischer Feb 25 '15 at 08:20
  • why does your log file look so different? Mine is missing the very interesting bibtex.pm:XY> part - even if I explicitly add the --debug option? Having the line number in the .bib file would have made my hack obsolete. – MostlyHarmless Feb 25 '15 at 09:09
  • 1
    Probably because I used also the --tool option. Also the line numbers don't refer to the bib so are not really useful in this case. The helpful part is the explicit name. – Ulrike Fischer Feb 25 '15 at 09:14
  • hm, ok, but I used both options --tool and --debug and still get the output like shown in my question above without the explicit problematic text. :-( I've asked a question here: http://tex.stackexchange.com/questions/230046/how-to-make-biber-1-9-also-print-the-debug-information-in-the-log-file – MostlyHarmless Feb 25 '15 at 09:28
  • tl;dr Avoid double commas , , in your author entries such as Author = {Liao,Hongmei and Coyle, ,Thomas W.}, – tommy.carstensen Dec 08 '17 at 01:01
  • @tommy.carstensen: well, you're exactly paraphrasing the solution I pointed out in the answer to my question: "one excessive comma" – MostlyHarmless Dec 10 '17 at 21:34
1

Have tweaked the answer of MostlyHarmless for Windows, cuz the split command with the git bash dont support -p @ parameter. The batchbiber.sh script works fine after this :) 

mkdir bibentries
split -t @ -l 1 -a 4 mybibfilename.bib ./bibentries/
cd bibentries
for old in *; do mv $old $old.bib; done
for file in *; do
  sed -z -i "1s/^/@/" "$file" &&
  truncate -s-1 $file
done
rm aaaa.bib
rm -rfbiber --cache

Because -t makes a seperation after @, we need to add @ at the first position in each file and del the last character (also @) at the end of the file

for file in *; do
  sed -z -i "1s/^/@/" "$file" &&
  truncate -s-1 $file
done

Because the first file (aaa.bib) will only contain @ we delete it 

rm aaaa.bib
MostlyHarmless
  • 12,160
mennchen22
  • 11
  • 1