Bug im Perl-Interpreter

Hallo alle,

das folgende Perl-Skript bricht bei mir immer mit "Segmentation fault" ab.
Kann irgendeiner bestätigen, dass ein Fehler im Perl-Interpreter vorliegt
und somit das Problem nicht an der Softwareinstallation hier an der Uni
liegt?

http://homepages.uni-paderborn.de/msteinbo/test.pl

Das Skript sieht so aus:

#! /usr/bin/perl

$line = ;
chomp $line;

$r = $line =~ /^([ae]) +(([0-9]+ +)+)0 *$/ ;
$r = 0+$r;
print "Result: $r\n";
__END__
[Hier steht eine betimmte Zeile, die ca. 40k lang ist, deswegen will ich
sie hier nicht posten. Siehe URL oben]


> perl --version

This is perl, v5.8.5 built for i386-linux-thread-multi

Copyright 1987-2004, Larry Wall




Grüße

Markus

Re: Bug im Perl-Interpreter

Am 03.05.2007 11:18 schrieb Markus Steinborn:
> Hallo alle,
>
> das folgende Perl-Skript bricht bei mir immer mit "Segmentation fault" ab.
> Kann irgendeiner bestätigen, dass ein Fehler im Perl-Interpreter vorliegt
> und somit das Problem nicht an der Softwareinstallation hier an der Uni
> liegt?
>
> http://homepages.uni-paderborn.de/msteinbo/test.pl
>
> Das Skript sieht so aus:

> This is perl, v5.8.5 built for i386-linux-thread-multi
>
> Copyright 1987-2004, Larry Wall

Stürzt hier auch ab:

ck@held:~> perl --version

This is perl, v5.8.6 built for i686-linux

Re: Bug im Perl-Interpreter

Markus Steinborn schrieb:
> das folgende Perl-Skript bricht bei mir immer mit "Segmentation fault" ab.
> Kann irgendeiner bestätigen, dass ein Fehler im Perl-Interpreter vorliegt
> und somit das Problem nicht an der Softwareinstallation hier an der Uni
> liegt?
>
> http://homepages.uni-paderborn.de/msteinbo/test.pl
>
> Das Skript sieht so aus:
>
> #! /usr/bin/perl
>
> $line = ;
> chomp $line;
>
> $r = $line =~ /^([ae]) +(([0-9]+ +)+)0 *$/ ;
> $r = 0+$r;
> print "Result: $r\n";
> __END__
> [Hier steht eine betimmte Zeile, die ca. 40k lang ist, deswegen will ich
> sie hier nicht posten. Siehe URL oben]
>
>
>> perl --version
>
> This is perl, v5.8.5 built for i386-linux-thread-multi
>
> Copyright 1987-2004, Larry Wall

Das ist ein bekannter Bug in der regex-Engine in Form eines Stack-
Überlaufs. Einen Fix gibt es erst in Perl 5.10[:(] das aber hoffentlich
nicht mehr allzu lange auf sich warten lässt. Eventuell bringt
es etwas an den ulimits zu schrauben oder das ganze auf Windows
laufen zu lassen.

Siehe
https://rt.perl.org/rt3/Ticket/Display.html?id=39167

-Christian

Re: Bug im Perl-Interpreter

Hier auch. Liegt aber bei mir an der bash.

$ ulimit -s unlimited
$ ./test.pl
Result: 1


tschazu
erkan


--
über den grenzen muß die freiheit wohl wolkenlos sein

Re: Bug im Perl-Interpreter

Christian Winter schrieb:
> Markus Steinborn schrieb:
>> das folgende Perl-Skript bricht bei mir immer mit "Segmentation fault" ab.
>> Kann irgendeiner bestätigen, dass ein Fehler im Perl-Interpreter vorliegt
>> und somit das Problem nicht an der Softwareinstallation hier an der Uni
>> liegt?
>>
> Das ist ein bekannter Bug in der regex-Engine in Form eines Stack-
> Überlaufs. Einen Fix gibt es erst in Perl 5.10[:(] das aber hoffentlich
> nicht mehr allzu lange auf sich warten lässt. Eventuell bringt
> es etwas an den ulimits zu schrauben oder das ganze auf Windows
> laufen zu lassen.

Ja, unter Windows kein Problem:

perl test.pl
Result: 1

Verwendet: perl 5.8.7 von ActiveState

Wolf

Re: Bug im Perl-Interpreter

Hallo Markus


Markus Steinborn schrieb:
> Hallo alle,
>=20
> das folgende Perl-Skript bricht bei mir immer mit "Segmentation fault" =
ab.=20
> Kann irgendeiner bestätigen, dass ein Fehler im Perl-Interpreter v=
orliegt=20
> und somit das Problem nicht an der Softwareinstallation hier an der Uni=
=20
> liegt?
>=20
[...]

Ich habe es mal unter OS2 getestet:
perl test.pl
Result: 1

Perl Version:
This is perl, v5.8.0 built for os2_emx

Copyright 1987-2002, Larry Wall

Schönen Gruß aus dem Bergischen Land
Robert

Re: Bug im Perl-Interpreter

Hallo Christian,

On Thu, 3 May 2007, Christian Winter wrote:

> Das ist ein bekannter Bug in der regex-Engine in Form eines Stack-
> Überlaufs. Einen Fix gibt es erst in Perl 5.10[:(] das aber hoffentlich
> nicht mehr allzu lange auf sich warten lässt.

Evtl. probiere ich auch mal Version 5.9.4 :-)

> Eventuell bringt es etwas an den ulimits zu schrauben

das werde ich dann wohl machen müssen. Weis einer, bis zu welcher
Zeilenlänge man dann kommt? Mit Ausprobieren wird man ja kaum den
Worst-Case erwischen.

> oder das ganze auf Windows laufen zu lassen.

Das ist leider keine Option.


Grüße

Markus

Re: Bug im Perl-Interpreter

Markus Steinborn schrieb:
> On Thu, 3 May 2007, Christian Winter wrote:
>
>> Das ist ein bekannter Bug in der regex-Engine in Form eines Stack-
>> Überlaufs. Einen Fix gibt es erst in Perl 5.10[:(] das aber hoffentlich
>> nicht mehr allzu lange auf sich warten lässt.
>
> Evtl. probiere ich auch mal Version 5.9.4 :-)

Auf eigene Gefahr ;)

>> Eventuell bringt es etwas an den ulimits zu schrauben
>
> das werde ich dann wohl machen müssen. Weis einer, bis zu welcher
> Zeilenlänge man dann kommt? Mit Ausprobieren wird man ja kaum den
> Worst-Case erwischen.

Das kommt natürlich immer auf die Regex selbst an, d.h.
Anzahl der Capture-Groups und Art der Quantifiers.

>> oder das ganze auf Windows laufen zu lassen.
>
> Das ist leider keine Option.

Dachte ich mir fast :)

Wobei sich für das Rekursions-Problem auch meist ein Workaround
finden ließe, IMHO wenn es nur um eine Hand voll Skripte geht
die unproblematischere Lösung.

-Christian

Re: Bug im Perl-Interpreter

Hallo Christian,

On Thu, 3 May 2007, Christian Winter wrote:

> Markus Steinborn schrieb:
> > das werde ich dann wohl machen müssen. Weis einer, bis zu welcher
> > Zeilenlänge man dann kommt? Mit Ausprobieren wird man ja kaum den
> > Worst-Case erwischen.
>
> Das kommt natürlich immer auf die Regex selbst an, d.h.
> Anzahl der Capture-Groups und Art der Quantifiers.

/^p +cnf +(+[0-9]+) +(+[0-9]+) *$/

/^([ae]) +(([0-9]+ +)+)0 *$/

/^ *((-?[0-9]+ +)+)0 *$/

sind z. Zt. die drei einzig relevanten Regexp's, es geht nämlich um das
Parsen des "qdimacs"-Formates; also eigentlich grammatisch einfache
Regexp's. Alle zukünftigen Erweiterungen bleiben bei solch einfacher Form,
die man eigentlich einfach mit einen Lookahead von 1 per Hand zerlegen
könnte (nur wird das länglich und nicht so übersichtlich wie der Regexp).

> Wobei sich für das Rekursions-Problem auch meist ein Workaround
> finden ließe, IMHO wenn es nur um eine Hand voll Skripte geht
> die unproblematischere Lösung.

Kann man obige drei Regexp's so anpassen, das Perl weniger Rekursionen
macht?

Grüße

Markus

Re: Bug im Perl-Interpreter

Markus Steinborn wrote:
> /^p +cnf +(+[0-9]+) +(+[0-9]+) *$/
> /^([ae]) +(([0-9]+ +)+)0 *$/
> /^ *((-?[0-9]+ +)+)0 *$/
>
> sind z. Zt. die drei einzig relevanten Regexp's, es geht nämlich um das
> Parsen des "qdimacs"-Formates; also eigentlich grammatisch einfache
> Regexp's. Alle zukünftigen Erweiterungen bleiben bei solch einfacher Form,
> die man eigentlich einfach mit einen Lookahead von 1 per Hand zerlegen
> könnte (nur wird das länglich und nicht so übersichtlich wie der Regexp).
>

Hallo markus, ich versuchs mal. Ich vermute mal, was das qdimacs-Format
sein könnte und würde folgende Ausdrücke nehmen. Es kommt aber sehr
darauf an, was genau Du extrahieren möchtest. Kannst Du ein
konkretes Beispiel Input -_> Output liefern?

Viele Grüße

Mirco


my @fmt = (
[ 'p cnf 4 2 ' , qr/^ p \s+ cnf \s+ (\d+) \s+ (\d+) \s*/x],
[ 'e 1 2 0 ' , qr/^ ([ae]) \s+ ((?:\d+\s+)+) 0\s*/x],
[ ' -1 2 0 ' , qr/^ \s* ((?:-? \d+ \s+)+) 0/x]
);


for my $o (@fmt) {
for my $i (@fmt) {
if( $o->[0] =~ /$i->[1]/ ) {
print $i->[1] . ' matches ' . $o->[0]
. '==> | ' . $1 . ' | ' . ($2 || '')
. "\n"
}
}
}

Re: Bug im Perl-Interpreter

Hallo Mirco,

On Thu, 3 May 2007, Mirco Wahab wrote:

> Markus Steinborn wrote:
> > /^p +cnf +(+[0-9]+) +(+[0-9]+) *$/
> > /^([ae]) +(([0-9]+ +)+)0 *$/
> > /^ *((-?[0-9]+ +)+)0 *$/

> Hallo markus, ich versuchs mal. Ich vermute mal, was das qdimacs-Format
> sein könnte und würde folgende Ausdrücke nehmen. Es kommt aber sehr
> darauf an, was genau Du extrahieren möchtest. Kannst Du ein
> konkretes Beispiel Input -_> Output liefern?

Ich füge mal folgendes ein:

$line = ;
chomp $line;

>
> my @fmt = (
> [ 'p cnf 4 2 ' , qr/^ p \s+ cnf \s+ (\d+) \s+ (\d+) \s*/x],

Vermute mal, dass der Regexp mit einem abschließenden Dollar gemeint war.
Der Regexp der "p"-Zeile legt aber zu Recht nahe, dass diese kurz ist, die
brauche ich eigentlich gar nicht zu ändern.

> [ 'e 1 2 0 ' , qr/^ ([ae]) \s+ ((?:\d+\s+)+) 0\s*/x],

hab ich mal geändert in:
[ $line , qr/^ ([ae]) \s+ ((?:\d+\s+)+) 0\s*/x],


> [ ' -1 2 0 ' , qr/^ \s* ((?:-? \d+ \s+)+) 0/x]
> );
>
>
> for my $o (@fmt) {
> for my $i (@fmt) {
> if( $o->[0] =~ /$i->[1]/ ) {
> print $i->[1] . ' matches ' . $o->[0]
> . '==> | ' . $1 . ' | ' . ($2 || '')
> . "\n"
> }
> }
> }

__END__
[Letzte Zeile von test.pl aus meinen OP hier einfügen]

Ich teste mal das geänaderte Skript:

> perl test2.pl
(?x-ism:^ p \s+ cnf \s+ (\d+) \s+ (\d+) \s*) matches p cnf 4 2 333 ==> | 4
| 2
Segmentation fault

Nein, das ist leider nicht besser als das Original von mir :-( Allerdings
hast Du die wesentlichen Teile des qdimacs-Formates verstanden (wir reden
hier nur über Syntax ohne Semantik).

Du wolltest ein Beispiel? Aber gerne:

--- cut here ---
p cnf 5 5
e 5 1 0
a 2 0
e 3 4 0
-1 2 -3 0
-1 -2 3 0
-1 2 4 0
-1 -2 -4 0
1 5 0
1 2 3 4 5 -1 0
--- cut here ---

Allgemeingültige Beobachtungen:

- Erst eine Zeile zum ersten Regexp

- Dann beliebig viele (auch 0) Zeilen zum zweiten Regexp ( der inhaltlich
lautet: [ea] "Liste on pos. Int-Zahlen" 0 )

- Zuletzt beliebig viele (auch 0) Zeilen zum dritten Ausdruck (
inhaltlich: "Liste von Int-Zahlen mit Vorzeichen" 0 )


Zur Ausgabe: Ich will Variablen befüllen, um damit ein Baum auszubauen
(bei "kleineren" Beispielen klappt das auch fehlerfrei!)

Die "p"-Zeile ist immer kurz und kann daher so bleiben, wie sie ist. Die
beiden Zahlen werden einfach zwei Variablen zugewiesen (mit $1 und $2 kein
Problem). Ich habe den Regexp nur der Vollständigkeit halber aufgeführt.

Eine Ausgabe soll sein: $line passt/passt nicht zum gegebenen Regexp.
Falls der Regexp passt, muss noch folgendes passieren:

"e 5 1 0" soll $quant = "e": @variables=(5,1); bewirken (also ohne
die 0, die ist nur syntaktischer Ballast).

"-1 2 -3 0" soll @variables=(-1,2,-3); bewirken. Wieder ist die "0"
uninteressant.


Grüße

Markus

PS: Hier zu Hause hab ich mindestens eine Linuxinstallation, wo mein
Originalbeispiel nicht abstürzt. Nützt aber nichts, an der Uni MUSS es
laufen.

Re: Bug im Perl-Interpreter

Hallo,

Christian Winter wrote:
> Das ist ein bekannter Bug in der regex-Engine in Form eines Stack-
> Überlaufs. Einen Fix gibt es erst in Perl 5.10[:(] das aber hoffen=
tlich
> nicht mehr allzu lange auf sich warten lässt.

Ich dachte, erst kommt noch 5.9 heraus? Bis das draußen ist wür=
de ich
mich auf so etwas nicht unbedingt verlassen...

Grüße,
Moritz

--=20
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/

Re: Bug im Perl-Interpreter

Hi,

Moritz Lenz wrote:
> Christian Winter wrote:
>> Das ist ein bekannter Bug in der regex-Engine in Form eines Stack-
>> Überlaufs. Einen Fix gibt es erst in Perl 5.10[:(] das aber hoffe=
ntlich
>> nicht mehr allzu lange auf sich warten lässt.
>=20
> Ich dachte, erst kommt noch 5.9 heraus? Bis das draußen ist wü=
rde ich
> mich auf so etwas nicht unbedingt verlassen...

Das war natürlich Unsinn, sorry...

Moritz

--=20
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/