bug in inet_drv.c

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bug in inet_drv.c

Claes Wikström
Howdy,

I resent an old bug report of mine a couple
of months ago but I'm not sure what happened to it.

It's a pretty serious bug and I recommend everone running
erlang systems that use sockets with {packet, http}  
(this includes all yaws systems) to apply the patch.
Otherwise it's easy to bring down the entire erlang node
just by sending broken HTTP requests at it.

Anyway, the bug is old and originally reported at:

http://www.erlang.org/ml-archive/erlang-questions/200302/msg00493.html

and a correct description at

http://article.gmane.org/gmane.comp.lang.erlang.patches/3


The patch is:

--- inet_drv.c.orig     2005-04-08 17:33:37.003071900 +0200
+++ inet_drv.c  2005-04-08 17:33:43.279602316 +0200
@@ -1980,7 +1980,7 @@
     int c;
     /* start-line = Request-Line | Status-Line */
     if (n == 0)
-      return 0;
+      return -1;
     h = 0;
     meth_ptr = ptr;
     while (n && !is_tspecial((unsigned char)*ptr)) {



/klacke


--
Claes Wikstrom                        -- Caps lock is nowhere and
http://www.hyber.org                  -- everything is under control          


Reply | Threaded
Open this post in threaded view
|

bug in inet_drv.c

Björn Gustavsson-3
Thanks!

I have now written a ticket, and we'll try to fix the bug
in R10B-5.

Do you happen to have any simple Erlang code that will
provoke the bug? That would save us some time in writing
the test case.

/Bjorn

klacke writes:

> Howdy,
>
> I resent an old bug report of mine a couple
> of months ago but I'm not sure what happened to it.
>
> It's a pretty serious bug and I recommend everone running
> erlang systems that use sockets with {packet, http}  
> (this includes all yaws systems) to apply the patch.
> Otherwise it's easy to bring down the entire erlang node
> just by sending broken HTTP requests at it.
>
> Anyway, the bug is old and originally reported at:
>
> http://www.erlang.org/ml-archive/erlang-questions/200302/msg00493.html
>
> and a correct description at
>
> http://article.gmane.org/gmane.comp.lang.erlang.patches/3
>
>
> The patch is:
>
> --- inet_drv.c.orig     2005-04-08 17:33:37.003071900 +0200
> +++ inet_drv.c  2005-04-08 17:33:43.279602316 +0200
> @@ -1980,7 +1980,7 @@
>      int c;
>      /* start-line = Request-Line | Status-Line */
>      if (n == 0)
> -      return 0;
> +      return -1;
>      h = 0;
>      meth_ptr = ptr;
>      while (n && !is_tspecial((unsigned char)*ptr)) {
>
>
>
> /klacke
>
>
> --
> Claes Wikstrom                        -- Caps lock is nowhere and
> http://www.hyber.org                  -- everything is under control          
>

--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB


Reply | Threaded
Open this post in threaded view
|

bug in inet_drv.c

Luke Gorrie-3
In reply to this post by Claes Wikström
klacke writes:

> I resent an old bug report of mine a couple
> of months ago but I'm not sure what happened to it.

Ha ha! I had forgotten all about this but I hit what was probably the
same bug just a month or two ago: having a process blocking in
gen_tcp:recv on a socket that is in CLOSE_WAIT, which should be
impossible.

Bjorn, you can find the test case in this link:

> http://article.gmane.org/gmane.comp.lang.erlang.patches/3




Reply | Threaded
Open this post in threaded view
|

bug in inet_drv.c

Claes Wikström
In reply to this post by Björn Gustavsson-3
On Tue, Apr 12, 2005 at 10:31:11AM +0200, Bjorn Gustavsson wrote:
> Thanks!
>
> I have now written a ticket, and we'll try to fix the bug
> in R10B-5.
>
> Do you happen to have any simple Erlang code that will
> provoke the bug? That would save us some time in writing
> the test case.

Sure, follow the links I posted. Nice little erlang program
there that provokes the bug.


/klacke



--
Claes Wikstrom                        -- Caps lock is nowhere and
http://www.hyber.org                  -- everything is under control          


Reply | Threaded
Open this post in threaded view
|

question about intended function of filelib:wildcard/2

Bengt Kleberg-4
greetings,

this is what the manual says:

        wildcard(Wildcard, Cwd) -> list()

               Types  Wildcard = filename() | dirname()
                      Cwd = dirname()

               The wildcard/2  function  works  like  wildcard/1,
except  that
               instead of the actual working dirctory, Cwd will be used.


i thought this would mean that the following 2 calls would give me the
same result:

  filelib:wildcard("/home/eleberg/*").
  filelib:wildcard("*", "/home/eleberg").


on my system they return very different lists.

could somebody please explain if they should be different, and how
wildcard/2 is supposed to be used.

or, what i am doing wrong.


bengt


Reply | Threaded
Open this post in threaded view
|

question about intended function of filelib:wildcard/2

Vlad Dumitrescu-4
>  filelib:wildcard("/home/eleberg/*").
>  filelib:wildcard("*", "/home/eleberg").
> on my system they return very different lists.
>
> could somebody please explain if they should be different, and how
> wildcard/2 is supposed to be used.

Hi,

Looking at the code,
    wildcard(Pattern) ->
        {ok, Cwd} = file:get_cwd(),
        wildcard(Pattern, Cwd).

    wildcard({compiled_wildcard, [Base|Rest]}, _Cwd) ->
        wildcard1([Base], Rest);
    wildcard(Pattern, Cwd) when list(Pattern), list(Cwd) ->
        wildcard(compile_wildcard(Pattern), Cwd).

it's interesting to notice that the Cwd argument is not used at all.

I would suppose that the intention was that if Base was a relative path, it
should be appended to Cwd. If Base is absolute, then Cwd should be ignored,
of course.

Using for example
    wildcard({compiled_wildcard, [Base|Rest]}, Cwd) ->
        case filename:pathtype(Base) of
             relative ->
                 wildcard1([join(Base, Cwd)], Rest);
            _ ->
                 wildcard1([Base], Rest)
        end;
works, with the only drawback that the returned filenames are all absolute
(which might or might not be what one needs).

regards,
Vlad


Reply | Threaded
Open this post in threaded view
|

question about intended function of filelib:wildcard/2

Björn Gustavsson-3
In reply to this post by Bengt Kleberg-4
I have now written the missing test suite and corrected the bug.

I have also corrected the minor bug that

        filelib:wildcard("/not/a/wildcard/pattern")

would not check that "/not/a/wildcard/pattern" really existed; not it will
check and return an empty list if the file does not exist.

I have also changed the exception that is thrown when the pattern is
invalid, such as in

        filelib:wildcard("{a,")

It used to be exit(missing_delimiter); but is now
erlang:error({badpattern,missing_delimiter}).

The correction will be in included in OTP R10-5.

/Bjorn

Bengt Kleberg <bengt.kleberg> writes:

> greetings,
>
> this is what the manual says:
>
>         wildcard(Wildcard, Cwd) -> list()
>
>                Types  Wildcard = filename() | dirname()
>                       Cwd = dirname()
>
>                The wildcard/2  function  works  like  wildcard/1,
> except  that
>                instead of the actual working dirctory, Cwd will be used.
>
>
> i thought this would mean that the following 2 calls would give me the
> same result:
>
>   filelib:wildcard("/home/eleberg/*").
>   filelib:wildcard("*", "/home/eleberg").
>
>
> on my system they return very different lists.
>
> could somebody please explain if they should be different, and how
> wildcard/2 is supposed to be used.
>
> or, what i am doing wrong.
>
>
> bengt
>

--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB