On Tue, Jan 31, 2012 at 10:36:15PM +0100, Otto Moerbeek wrote: > On Tue, Jan 31, 2012 at 09:10:25PM +0100, Michael Niedermayer wrote: > > > On Tue, Jan 31, 2012 at 01:10:28PM +0100, Otto Moerbeek wrote: > > > On Mon, Jan 30, 2012 at 03:18:04PM +0100, Michael Niedermayer wrote: > > > > > > > Hi > > > > > > > > Our automated tests for FFmpeg (http://fate.ffmpeg.org/) have yesterday > > > > found a segfault in openbsds /bin/sh. > > > > > > > > Analysis revealed that it was triggered by too many variables > > > > That is something like > > > > > > > > #!/bin/sh > > > > > > > > i=0 > > > > while true ; do > > > > eval X${i}=yes > > > > i=$(($i+1)) > > > > test $i -gt 17000 && break > > > > done > > > > > > > > will segfault. > > > > > > > > The following patch fixes it: (which we are currently using on our > > > > openbsd fate client) > > > > > > > > Index: table.h > > > > =================================================================== > > > > RCS file: /cvs/src/bin/ksh/table.h,v > > > > retrieving revision 1.7 > > > > diff -u -r1.7 table.h > > > > --- table.h 11 Dec 2005 20:31:21 -0000 1.7 > > > > +++ table.h 30 Jan 2012 14:13:30 -0000 > > > > @@ -8,7 +8,7 @@ > > > > > > > > struct table { > > > > Area *areap; /* area to allocate entries */ > > > > - short size, nfree; /* hash size (always 2^^n), free entries */ > > > > + int size, nfree; /* hash size (always 2^^n), free entries */ > > > > struct tbl **tbls; /* hashed table items */ > > > > }; > > > > > > > > > > > > > > Thanks for the report. > > > > > > I could reproduce the bug, but I'm not 100% happy with your fix since > > > it just pushes the failure to a bigger number of vars. > > > > > > It's better to check for the case like below, > > > > yes, absolutely a check is needed. > > doing the check at SHORT_MAX/2 though would likely just lead ffmpegs > > configure to fail with "too many vars" > > But what does the test actually tries to find out? Is this just a test > creating many vars for no real reason or is this something real and not > contrived?
its not contrived, the segfault actually happened with ffmpegs configure: http://fate.ffmpeg.org/log.cgi?time=20120129184603&log=configure&slot=x86_64- openbsd4.8-gcc3.3 and went away once i changed the vars from short to int in /bin/sh it also went away by using bash Ive also done a quick test with 5.0 to make sure this hasnt been fixed by some other means The number of actually created variables in our configure is around 3500 (counted by using set | grep '=' | wc at the end of it) by dumping the entries of the hash table at the time of it hitting the SHORT_MAX/2 limit i found that there was alot more in there then what i naively had expected from the set output. These are created by: eval dep_all="\$${cfg}_deps" eval dep_any="\$${cfg}_deps_any" eval dep_sel="\$${cfg}_select" eval dep_sgs="\$${cfg}_suggest" eval dep_ifa="\$${cfg}_if" eval dep_ifn="\$${cfg}_if_any" of our check_deps() function see: http://source.ffmpeg.org/?p=ffmpeg.git;a=blob_plain;f=configure;hb=HEAD > > > Some further investigation shows that code like: > > i=0 > > while true ; do > > eval X="\$X${i}" > > > > i=$(($i+1)) > > test $i -gt 17000 && break > > done > > > > also fails, iam not sure why ksh generates entries in the table for > > this > > Will look into this. thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
