Man beachte diese beiden Heisemeldungen:

1. 05.05.2014 20:47: Springer: Google, Facebook & Co. "wollen uns Verlage vernichten"

2. 06.05.2014 08:23: Axel Springer erwirtschaftet erstmals mehr als die Hälfte seines Umsatzes digital

Offensichtlich setzen die zu viele unbezahlte Praktikanten in ihrer PR-Abteilung ein. Demagogengesindel.

Kostenlos:

Ich habe am Wochenende angefangen, die PCP Library (libpcp) threadsafe zu machen. Zu diesem Zweck habe ich ein Context-Objekt eingeführt, in dem vormals globale Variablen abgelegt werden (Fehler und Schlüssellisten). Jetzt habe ich nach der Änderung (die tiefgreifend ist) das erste Mal die Unittests durchlaufen lassen und einer der Tests ist fehlgeschlagen:

  executing prepare command: while :; do cp testfuzzP.orig testfuzzP.pub; ./mangle testfuzzP.pub; 
                             if ! diff testfuzzP.* > /dev/null 2>&1; then break; fi; done
echo no | ../src/pcp1 -V vf -K -I testfuzzP.pub -x a
ok 81 - check-fuzz-binary-pubkey-loop-0
Abnormal program termination
Core was generated by `pcp1’.
Program terminated with signal 6, Aborted.
#0  0x0000000800db9d6c in kill () from /lib/libc.so.7
#0  0x0000000800db9d6c in kill () from /lib/libc.so.7
#1  0x0000000800db899b in abort () from /lib/libc.so.7
#2  0x0000000000407f8c in final (fmt=Variable “fmt” is not available.
) at context.c:102
#3  0x00000000004100f2 in buffer_get_chunk (b=0x80149b100, buf=0x80149c080, len=3932164) at buffer.c:132
#4  0x00000000004122d3 in _check_sigsubs (blob=0x80149b100, p=0x801407c00, subheader=0x8014a7060) at mgmt.c:103
#5  0x00000000004126bf in pcp_import_pub_rfc (ptx=0x801417040, blob=0x80149b100) at mgmt.c:265
#6  0x0000000000403e34 in pcp_import (vault=0x80141a060, in=0x8010099d0, passwd=0x801419104 “a”) at keymgmt.c:577
#7  0x0000000000402df2 in main (argc=0, argv=0x7fffffffd170) at pcp.c:440
Last failed check: check-fuzz
1..81
To run a single test only, type: ‘make test CHECK=testname’

Ich hab das Problem jetzt noch nicht näher untersucht. Spannend ist aber, dass es der Fuzzytest war, der hier fehlgeschlagen ist (hat wahrscheinlich nichts mit der Contextänderung zu tun). Bei einem Fuzzytest wird randomisiertes Input erzeugt und das zu testende Programm damit gefüttert. Idealerweise sollte es mit solchem Zeug klarkommen. In diesem Fall ist pcp1 aber gestorben.

Noch wesentlich interessanter ist warum. Und zwar habe ich - gleichzeitig - in der Bufferklasse eine Änderung gemacht, bei der potentielle Bufferoverflows, die dort abgefangen werden, nicht via fatal() über den normalen Programmfluß reportet werden, sondern ich habe an der Stelle ein abort() eingebaut. Und an der Stelle ist dieser Fuzzytest hier gescheitert. Man kann das besser erkennen, wenn man den Test manuell ausführt:

echo no | ../src/pcp1 -V vf -K -I testfuzzP.pub -x a
ABORT: [buffer importblob] attempt to read 3932164 bytes data from buffer with 204 bytes left at offset 113
Abort trap: 6 (Speicherabzug geschrieben)

Die Fehlermeldung wird in libpcp/buffer.c erzeugt. Woher das kommt, ist mir im Moment zwar noch nicht ganz klar. Es sieht verdächtig nach Integer Overflow aus: in der zu importierenden Schlüsseldatei gibt es normalerweise Felder für Email, Name und dergleichen (Notations, siehe RFC 4880). In der Notation ist die Länge des Strings angegeben und durch das kaputte Inputfile (das wird mit mangle.c, oben verlinkt, erzeugt) steht an der Stelle wahrscheinlich eine ziemlich grosse Zahl. Und offensichtlich prüft meine Importroutine nicht, ob diese Zahlenangabe Sinn macht. Aber das spielt an der Stelle erstmal keine Rolle. Der Fehler zeigt jedenfalls eindrucksvoll, wie wertvoll und nützlich solche Fuzzytests sind. Zum Glück hab ich die eingebaut! Wer weiss, ob ich den Fehler andernfalls je gefunden hätte. Uff.

Fies, aber schön :)

Der Vollständigkeit halber: in diesem Commit kann man ab Zeile 73 die Änderungen sehen, mit denen ich das Problem behoben habe.

Da wir hier einige Diskussionen über die richtige Luftfeuchtigkeit bei der Bartagamenhaltung hatten, habe ich mal das Verbreitungsgebiet der Tiere mit tatsächlichen Meßwerten korreliert. Das Ergebnis ist klar: ausserhalb der Winterzeit (wo die Tiere sowieso in Winterruhe sind) sind tagsüber 20-30% relative Luftfeuchte in Ordnung.

Quelle Klimadaten: Australian Government, Bureau of Meteorology.

Quelle Pogona Vitticeps Verbreitungsgebiet: Wikipedia.

2014-05-01 - Luftfeuchtigkeit Australien im Sommer, nachmittags:

2014-05-01 - Luftfeuchtigkeit Australien im Sommer, vormittags:

2014-05-01 - Luftfeuchtigkeit Australien im Winter, nachmittags:

2014-05-01 - Luftfeuchtigkeit Australien im Winter, vormittags:

Hach, das ist ja mal eine kuriose Nummer, dieser Bug. Aber von vorn: gestern habe ich (in der Arbeit) wegen einem Perlproblem herumgegoogelt und eines der Suchergebnisse war ein Posting bei Perlmonks wegen einem Config::General Problem. In dem Posting hatte jemand Schwierigkeiten, ein Makefile mit meinem Modul zu parsen, in dem sich "line continuations" befanden. Die entsprechende Stelle in dem Makefile sah so aus:

THIS_BREAKS     = \
MULTILINE       = 

Foo     

Bar     

Baz

Config::General hat dann nach dem Parsen das hier ausgespuckt:

THIS_BREAKS  => "MULTILINE\t= Foo\tBar\tBaz",

was der Fragesteller als Fehler betrachtete. Peter Jaquiery hat dann für mein Modul einen Bug eröffnet: 39814. In der Fehlerbeschreibung hat er aber von dem oben beschriebenen Problem nichts erwähnt, sondern nur gemeint, ein chop() Aufruf sei falsch. Das war aber Absicht, also hab ich den Bug geschlossen (rejected).

Das war vor 6 Jahren!

Nun bin ich also gestern über dieses Perlmonks Posting gestolpert, bei dem ganz unten zu jenem Bug verlinkt war. Natürlich erschien das Problem nun in einem völlig anderen Licht. Der Bug war sogar unerwarteterweise recht einfach zu beheben, was ich soeben gemacht habe.

Odd ist wirklich die passende Beschreibung für den Vorgang. 6 Jahre! Meine Güte :)

Nun ist also die Version 2.54 aktuell.