casley@neon.stanford.edu (Ross Casley) (09/30/89)
There seems to be a bug in calendar. When I try to run it today I wait a long time, then I get several messages that egrep has run out of swap space. Now, calendar works by first running /usr/lib/calendar, which generates a pattern that is then fed to egrep. The pattern is supposed to pick out the relevant lines from the calendar file. My best guess is that since today is a Friday and the month changes over the weekend, /usr/lib/calendar generates an unusually long pattern. Then egrep barfs on it. One might think that egrep would have got protected against this sort of thing by now, but apparently not. Has anybody else noticed this, or have a better explanation? This machine is running Ultrix T3.1A-2 (Rev.24). -Ross Casley.
maslen@Neon.Stanford.EDU (Thomas Maslen) (09/30/89)
In article <12066@polya.Stanford.EDU> casley@neon.stanford.edu (Ross Casley) writes: >There seems to be a bug in calendar. When I try to run it today I wait a >long time, then I get several messages that egrep has run out of swap >space. Now, calendar works by first running /usr/lib/calendar, which >generates a pattern that is then fed to egrep. The pattern is supposed to >pick out the relevant lines from the calendar file. My best guess is that >since today is a Friday and the month changes over the weekend, >/usr/lib/calendar generates an unusually long pattern. Then egrep barfs For what it's worth, here's the pattern from /usr/lib/calendar that caused egrep to lose it: (^|[ (,;])(([Ss]ep[^ ]* *|(09|9)/)0*29)([^0123456789]|$) (^|[ (,;])((\* *)0*29)([^0123456789]|$) (^|[ (,;])(([Ss]ep[^ ]* *|(09|9)/)0*30)([^0123456789]|$) (^|[ (,;])((\* *)0*30)([^0123456789]|$) (^|[ (,;])(([Oo]ct[^ ]* *|(010|10)/)0*1)([^0123456789]|$) (^|[ (,;])((\* *)0*1)([^0123456789]|$) (^|[ (,;])(([Oo]ct[^ ]* *|(010|10)/)0*2)([^0123456789]|$) (^|[ (,;])((\* *)0*2)([^0123456789]|$) An older version of Ultrix (2.0 -- I kid you not), a local 4.3-derivative, and SunOS (4.0.3) all do rather better on this pattern (well, OK, SunOS egrep gives up with "regular expression too long", but that's better than crashing and burning). The SunOS /usr/lib/calendar also generates a different pattern which is more digestible, both to the SunOS egrep and to Ultrix 3.1 egrep. Grrr. Thomas Maslen maslen@neon.stamford.edu
grr@cbmvax.UUCP (George Robbins) (10/04/89)
In article <12070@polya.Stanford.EDU> maslen@Neon.Stanford.EDU (Thomas Maslen) writes: > In article <12066@polya.Stanford.EDU> casley@neon.stanford.edu (Ross Casley) writes: > >There seems to be a bug in calendar. When I try to run it today I wait a > >long time, then I get several messages that egrep has run out of swap > >space. Now, calendar works by first running /usr/lib/calendar, which > >generates a pattern that is then fed to egrep. The pattern is supposed to > >pick out the relevant lines from the calendar file. My best guess is that > >since today is a Friday and the month changes over the weekend, > >/usr/lib/calendar generates an unusually long pattern. Then egrep barfs This sounds like manifestation of the problem that was reported previously with *grep, when DEC changed the regexp code to handle 8-bit data and didn't increase the area for storeing the compiled expressions. Please file an SPR describing the problem and pointing at egrep. Maybe DEC will deign to fix it this time... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)