internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: benoitc/gunicorn

Issue:
WSGI sendfile does not respect file current offset
Hi,

on Linux, I need to stream a regular file from the disk starting from a specific offset.

According to Django doc, when you use a FileReponse you can seek your file to a specific offset and only the remaining part of the file will be streamed from this offset (just have to take care of the Content-Length).

It's working with the internal Django development server but while using gunicorn the file is streamed from the offset 0.

* OS: Debian Buster
* Python: python 3.7.3
* Virtual environment packages:
   ```
   asgiref==3.4.1
   Django==3.2.8
   gunicorn==20.1.0
   pkg-resources==0.0.0
   pytz==2021.3
   sqlparse==0.4.2
   typing-extensions==3.10.0.2
   ```

Here is my view from by "buggy" Django project:

```
import os

from pathlib import Path

from django.http import FileResponse

SRC = Path(__file__).parent / 'src'

if not SRC.is_file():
    with SRC.open('wt') as sample:
        sample.write(''.join(map(str, range(10))))
        sample.write('\n')

def get(request):
    try:
        offset = int(request.GET.get('offset') or 0)
    except ValueError:
        offset = 0

    src = SRC.open('rb')
    src.seek(offset)
    reply = FileResponse(src)
    reply['Content-Length'] = str(SRC.stat().st_size - offset)
    return reply
````

Result with `manage.py runserver`:

```
$ curl http://127.0.0.1:8000/?offset=5
56789
$
```

Result with `gunicorn buggy.wsgi -b 127.0.0.1:9000`:

```
curl http://127.0.0.1:9000/?offset=5
012345$
```

I resolve my case by changing in `gunicorn.wsgi.Response.sendfile`:

```
375c375
<         self.sock.sendfile(respiter.filelike, count=nbytes)
---
>         self.sock.sendfile(respiter.filelike, count=nbytes, offset=offset)
```

New result with `gunicorn buggy.wsgi -b 127.0.0.1:9000`:

```
curl http://127.0.0.1:9000/?offset=5
56789
$
```

Looking to file history, it seems the bug has been introduced while switching from os.sendfile to socket.sendfile in commit 2d40e6daceb9735d27bb91d9c32743695de8e01c

Thanks,

PS: while it's not a problem in my case and Django, at line 380, why do you seek back the file descriptor to the original offset before leaving `sendfile` ?


Discussion:

Resolving patch:
diff --git a/gunicorn/http/wsgi.py b/gunicorn/http/wsgi.py
--- a/gunicorn/http/wsgi.py
+++ b/gunicorn/http/wsgi.py
@@ -372,7 +372,7 @@ def sendfile(self, respiter):
             chunk_size = "%X\r\n" % nbytes
             self.sock.sendall(chunk_size.encode('utf-8'))
         if nbytes > 0:
-            self.sock.sendfile(respiter.filelike, count=nbytes)
+            self.sock.sendfile(respiter.filelike, offset=offset, count=nbytes)
 
         if self.is_chunked():
             self.sock.sendall(b"\r\n")


Test patch:
Repository: benoitc/gunicorn

Issue:
LogRecords should not format variables into message
The `msg` of logging calls should be format strings and not include variables.

> msg – The event description message, possibly a format string with placeholders for variable data.

https://docs.python.org/3/library/logging.html#logrecord-objects

One example is at https://github.com/benoitc/gunicorn/blob/cf55d2cec277f220ebd605989ce78ad1bb553c46/gunicorn/workers/ggevent.py#L113

Pre-formatting variables into the `msg` prevents aggregation of logs in tools/services like sentry.


Discussion:

Resolving patch:
diff --git a/gunicorn/config.py b/gunicorn/config.py
--- a/gunicorn/config.py
+++ b/gunicorn/config.py
@@ -1906,7 +1906,7 @@ class PreRequest(Setting):
     type = callable
 
     def pre_request(worker, req):
-        worker.log.debug("%s %s" % (req.method, req.path))
+        worker.log.debug("%s %s", req.method, req.path)
     default = staticmethod(pre_request)
     desc = """\
         Called just before a worker processes the request.
diff --git a/gunicorn/workers/ggevent.py b/gunicorn/workers/ggevent.py
--- a/gunicorn/workers/ggevent.py
+++ b/gunicorn/workers/ggevent.py
@@ -110,7 +110,7 @@ def run(self):
                 gevent.sleep(1.0)
 
             # Force kill all active the handlers
-            self.log.warning("Worker graceful timeout (pid:%s)" % self.pid)
+            self.log.warning("Worker graceful timeout (pid:%s)", self.pid)
             for server in servers:
                 server.stop(timeout=1)
         except Exception:


Test patch:
Repository: benoitc/gunicorn

Issue:
Wrong HTTP status code on Request Header Fields Too Large
When the request header gets too large (e.g. a lot of cookies), gunicorn returns HTTP 400 instead of HTTP 431, which can mask the real problem through proxies. Gunicorn should return the right HTTP error code.


Discussion:

Resolving patch:
diff --git a/gunicorn/workers/base.py b/gunicorn/workers/base.py
--- a/gunicorn/workers/base.py
+++ b/gunicorn/workers/base.py
@@ -230,7 +230,9 @@ def handle_error(self, req, client, addr, exc):
             elif isinstance(exc, LimitRequestLine):
                 mesg = "%s" % str(exc)
             elif isinstance(exc, LimitRequestHeaders):
+                reason = "Request Header Fields Too Large"
                 mesg = "Error parsing headers: '%s'" % str(exc)
+                status_int = 431
             elif isinstance(exc, InvalidProxyLine):
                 mesg = "'%s'" % str(exc)
             elif isinstance(exc, ForbiddenProxyRequest):


Test patch:
Repository: benoitc/gunicorn

Issue:
Version 21.0.1 or higher breaks with python 3.5
I am currently running an older application with Python 3.5, and I encountered an error when attempting to update the Gunicorn version to the latest one:

```
NameError: name 'ModuleNotFoundError' is not defined
```

After some investigation, I realized that the 'ModuleNotFoundError' is only available for Python 3.6 or higher. My suspicion is that this bug was introduced in [this commit](https://github.com/benoitc/gunicorn/commit/f628dd9730f965b1917397ea1846c68844b1fe7a).

As a result, it seems that Gunicorn is not fully compatible with Python 3.5



Discussion:
It [looks](https://github.com/benoitc/gunicorn/blob/master/.github/workflows/tox.yml#L13) [like](https://github.com/benoitc/gunicorn/commit/f5d73aa73d53ef7838c128b7c3a582c536670c5e) the tests are run on Python 3.7 and higher, so I'm not sure Gunicorn is trying to be compatible with Python 3.5. Seems like the README should be updated.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -21,8 +21,6 @@
     'Operating System :: POSIX',
     'Programming Language :: Python',
     'Programming Language :: Python :: 3',
-    'Programming Language :: Python :: 3.5',
-    'Programming Language :: Python :: 3.6',
     'Programming Language :: Python :: 3.7',
     'Programming Language :: Python :: 3.8',
     'Programming Language :: Python :: 3.9',
@@ -100,7 +98,7 @@ def run_tests(self):
         'Source code': 'https://github.com/benoitc/gunicorn',
     },
 
-    python_requires='>=3.5',
+    python_requires='>=3.7',
     install_requires=install_requires,
     classifiers=CLASSIFIERS,
     zip_safe=False,


Test patch:
Repository: vyperlang/vyper

Issue:
Need a .travis.yml file to properly run travis tests
^


Discussion:
If it works for you, I will pick up this task during the next weekend.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -20,7 +20,7 @@
     license=license,
     packages=find_packages(exclude=('tests', 'docs')),
     install_requires=[
-        'ethereum == 1.3.7',
+        'ethereum==2.0.4',
         'serpent',
         'pytest-cov',
         'pytest-runner', # Must be after pytest-cov or it will not work


Test patch:
Repository: vyperlang/vyper

Issue:
Array of bytes has infinite type size
I am pretty sure this is an error, although I am a bit unclear behind the purpose of declaring the size of a type to be infinite. Is this a part of the gas estimate?

Anyways, if you define an array of bytes using another type, it throws an error e.g.:
```python
def __init__(test: bytes32[bool]):
    pass
```

even though that data size should only be 64 bytes max (32 bytes x 2 possible values for bool)

Would appreciate some understanding behind the purpose of this check and if there is supposed to be a deeper check occuring, like some sort of maximum (or reasonable) number of bytes we should be allowed to use? (distinct from their economic cost to store them)


Discussion:
I think the problem with my example is only in function arguments... hmm
Viper assumes maps all have infinite type size; you're right that it's incorrect in that particular case. IMO it's not worth it to have some kind of special-case support for two-item maps.
I agree with you on that, it was a spurious example.

More for my understanding, what is the reasoning behind this decision? A viper contract can store it's own data in maps, which could reach infinite size in theory, but function arguments (or return values) are not allowed to be of variable size. Is this to ensure that gas estimates can be computed, or something more fundamental to the EVM?

I'm still very much learning, excuse my ignorance!
The reason why infinite sized types in general are not allowed as function arguments is indeed gas estimation. The reason why maps specifically are not allowed is that there is no standard for how an entire map can be passed around as a data structure in the ABI, and the code complexity of implementing such a format, as well as the mechanisms for converting between this format and storage maps, is hard.
@vbuterin as a suggestion, can we change that error message to "Maps are not supported for function arguments or outputs"? A much more descriptive error than "has infinite size"

Resolving patch:
diff --git a/viper/types.py b/viper/types.py
--- a/viper/types.py
+++ b/viper/types.py
@@ -310,7 +310,7 @@ def get_size_of_type(typ):
     elif isinstance(typ, ListType):
         return get_size_of_type(typ.subtype) * typ.count
     elif isinstance(typ, MappingType):
-        raise Exception("Type size infinite!")
+        raise Exception("Maps are not supported for function arguments or outputs.")
     elif isinstance(typ, StructType):
         return sum([get_size_of_type(v) for v in typ.members.values()])
     elif isinstance(typ, TupleType):


Test patch:
Repository: vyperlang/vyper

Issue:
Remove inputs from abi name field.
### What's your issue about?
Viper's abi `name` field should not have a functions inputs attached to it for two reasons:
1) Duplicate information (the inputs are already in that abi elsewhere)
2) Abi uniformity, now the `name` field will match Solidity's

### How can it be fixed?

Change abi `name` to not have inputs

#### Cute Animal Picture

![image](https://user-images.githubusercontent.com/17552858/30252057-f79e4644-9628-11e7-8cb9-b690f6d19034.png)




Discussion:
I found it, submitting a PR with a few other minor tweaks to the ABI for review (added `sig` field to match, might make #335 easier)

Resolving patch:
diff --git a/viper/function_signature.py b/viper/function_signature.py
--- a/viper/function_signature.py
+++ b/viper/function_signature.py
@@ -89,7 +89,7 @@ def from_definition(cls, code):
 
     def to_abi_dict(self):
         return {
-            "name": self.sig,
+            "name": self.name,
             "outputs": [{"type": canonicalize_type(self.output_type), "name": "out"}] if self.output_type else [],
             "inputs": [{"type": canonicalize_type(arg.typ), "name": arg.name} for arg in self.args],
             "constant": self.const,


Test patch:
Repository: vyperlang/vyper

Issue:
compile_lll.py: buggy translation of `repeat` when #iteration <= 0
### What's your issue about?

If the #iteration of `repeat` loop is less than or equal to 0, it replaces it by `2`, which perhaps should not, while `1` would be more reasonable:
https://github.com/ethereum/viper/blob/b1fe12ddd8706ef3340a103916e3d3f2cc95ceef/viper/compile_lll.py#L96

Fortunately, for now, the `repeat` loops will be rejected in the preprocess phase if the #iteration is less than or equal to 0, but it would be good to fix for later:
https://github.com/ethereum/viper/blob/b1fe12ddd8706ef3340a103916e3d3f2cc95ceef/viper/parser/parser_utils.py#L113-L114

### How can it be fixed?

Change the following line:
https://github.com/ethereum/viper/blob/b1fe12ddd8706ef3340a103916e3d3f2cc95ceef/viper/compile_lll.py#L96
to something like:
```
loops = num_to_bytearray(code.args[2].value) or [1]
```
or
```
loops = num_to_bytearray(code.args[2].value) or raise Exception(...)
```

#### Cute Animal Picture

```
                        _.-..
                      ,'9 )\)`-.,.--.
                      `-.|           `.
                         \,      ,    \)
                          `.  )._\   (\
                            |//   `-,//
                            ]||    //"
                     hjw    ""    ""
```



Discussion:

Resolving patch:
diff --git a/viper/compile_lll.py b/viper/compile_lll.py
--- a/viper/compile_lll.py
+++ b/viper/compile_lll.py
@@ -93,7 +93,9 @@ def compile_to_assembly(code, withargs=None, break_dest=None, height=0):
     # Repeat(memloc, start, rounds, body)
     elif code.value == 'repeat':
         o = []
-        loops = num_to_bytearray(code.args[2].value) or [2]
+        loops = num_to_bytearray(code.args[2].value)
+        if not loops:
+            raise Exception("Number of times repeated must be a constant nonzero positive integer: %r" % loops)
         start, end = mksymbol(), mksymbol()
         o.extend(compile_to_assembly(code.args[0], withargs, break_dest, height))
         o.extend(compile_to_assembly(code.args[1], withargs, break_dest, height + 1))


Test patch:
diff --git a/tests/compiler/LLL/test_repeat.py b/tests/compiler/LLL/test_repeat.py
new file mode 100644
--- /dev/null
+++ b/tests/compiler/LLL/test_repeat.py
@@ -0,0 +1,9 @@
+import pytest
+
+def test_repeat(t, get_contract_from_lll, assert_compile_failed):
+    good_lll = ['repeat', 0, 0, 1, ['seq']]
+    bad_lll_1 = ['repeat', 0, 0, 0, ['seq']]
+    bad_lll_2 = ['repeat', 0, 0, -1, ['seq']]
+    get_contract_from_lll(good_lll)
+    assert_compile_failed(lambda: get_contract_from_lll(bad_lll_1), Exception)
+    assert_compile_failed(lambda: get_contract_from_lll(bad_lll_2), Exception)
Repository: vyperlang/vyper

Issue:
Compiler doesn't check the actual return type (when it is a ListType) 
### What's your issue about?
```
@public
def foo()->bool[2]:
    a: decimal[2]
    a[0] = 1
    return a
```
```
@public
def foo()->bool[2]:
    a: bool[1000]
    a[0] = 1
    return a
```
Viper accepts the above programs which don't seem to be correct. The compiler will neither check the list subtype nor the number of elements in the list.

### How can it be fixed?

add checking in `def parse_return`

#### Cute Animal Picture

![image](https://user-images.githubusercontent.com/5641590/33407265-2b7c78b8-d536-11e7-9ad8-409ab77a1dcd.png)




Discussion:
Thanks! I will tackle this one next :smile: 

Resolving patch:
diff --git a/viper/parser/stmt.py b/viper/parser/stmt.py
--- a/viper/parser/stmt.py
+++ b/viper/parser/stmt.py
@@ -1,4 +1,5 @@
 import ast
+import re
 
 from viper.exceptions import (
     ConstancyViolationException,
@@ -350,6 +351,15 @@ def parse_return(self):
                 raise Exception("Invalid location: %s" % sub.location)
 
         elif isinstance(sub.typ, ListType):
+            sub_base_type = re.split(r'\(|\[', str(sub.typ.subtype))[0]
+            ret_base_type = re.split(r'\(|\[', str(self.context.return_type.subtype))[0]
+            if sub_base_type != ret_base_type and sub.value != 'multi':
+                raise TypeMismatchException(
+                    "List return type %r does not match specified return type, expecting %r" % (
+                        sub_base_type, ret_base_type
+                    ),
+                    self.stmt
+                )
             if sub.location == "memory" and sub.value != "multi":
                 return LLLnode.from_list(['return', sub, get_size_of_type(self.context.return_type) * 32],
                                             typ=None, pos=getpos(self.stmt))


Test patch:
diff --git a/tests/parser/syntax/test_list.py b/tests/parser/syntax/test_list.py
--- a/tests/parser/syntax/test_list.py
+++ b/tests/parser/syntax/test_list.py
@@ -109,6 +109,20 @@ def foo():
 def foo():
     x = self.b[0].cow
     """,
+    """
+@public
+def foo()->bool[2]:
+    a: decimal[2]
+    a[0] = 1
+    return a
+    """,
+    """
+@public
+def foo()->bool[2]:
+    a: bool[1000]
+    a[0] = 1
+    return a
+    """
 ]
Repository: vyperlang/vyper

Issue:
decimal number range check is not consistent with the document
### What's your issue about?
In the types doc, it says `decimal` is a value with a precision of 10 decimal places between `-2**127` and `2**127 - 1`. In the following program 
```
a:decimal
@public
def foo():
    self.a = 170141183460469231731687303715884105727.888
```
a is greater than 2**127 -1 but it still compiles.

### How can it be f**ixe**d?

In expr.py:
```
def number(self):
        ...
        elif isinstance(self.expr.n, float):
            numstring, num, den = get_number_as_fraction(self.expr, self.context)
            if not (-2**127 * den < num < 2**127 * den):
                ...

```
change from `-2**127 * den < num < 2**127 * den` to `SizeLimits.MINNUM * den <= num <= SizeLimits.MAXNUM *den`

#### Cute Animal Picture

![image](https://user-images.githubusercontent.com/5641590/33224087-79ff227e-d12b-11e7-9be3-d94f29ffa9bc.png)





Discussion:
Typically the decimal counts towards the total, but I agree with the clamping here. Otherwise we would have information loss when converting to `num` when the value of decimal is above `2**127 - 1 + 0.5`
On it :) thanks @yzhang90 !

Resolving patch:
diff --git a/viper/parser/expr.py b/viper/parser/expr.py
--- a/viper/parser/expr.py
+++ b/viper/parser/expr.py
@@ -84,7 +84,7 @@ def number(self):
             return LLLnode.from_list(self.expr.n, typ=BaseType('num', None), pos=getpos(self.expr))
         elif isinstance(self.expr.n, float):
             numstring, num, den = get_number_as_fraction(self.expr, self.context)
-            if not (-2**127 * den < num < 2**127 * den):
+            if not (SizeLimits.MINNUM * den < num < SizeLimits.MAXNUM * den):
                 raise InvalidLiteralException("Number out of range: " + numstring, self.expr)
             if DECIMAL_DIVISOR % den:
                 raise InvalidLiteralException("Too many decimal places: " + numstring, self.expr)


Test patch:
diff --git a/tests/parser/exceptions/test_invalid_literal_exception.py b/tests/parser/exceptions/test_invalid_literal_exception.py
--- a/tests/parser/exceptions/test_invalid_literal_exception.py
+++ b/tests/parser/exceptions/test_invalid_literal_exception.py
@@ -91,6 +91,14 @@ def foo():
 @public
 def foo():
     x = as_num256(3.1415)
+    """,
+    """
+# Test decimal limit.
+a:decimal
+
+@public
+def foo():
+    self.a = 170141183460469231731687303715884105727.888
     """
 ]
Repository: vyperlang/vyper

Issue:
Unit arithmetic is not correct in the expontial case
### What's your issue about?
```
@public def foo(): 
    a: num(wei) 
    b: num(wei) 
    c = a ** b
```
viper allows such program which doesn't make sense.  And use `combine_units` in the exponential case doesn't seem correct.

### How can it be fixed?

The correct behavior of `c = a ** b` if a is a unit type is that:
`b` MUST be an integer and the type of `c` becomes the unit of `a` rises to the power of `b`.

#### Cute Animal Picture

![image](https://user-images.githubusercontent.com/5641590/33395381-f0809c7e-d50a-11e7-990e-bc9dc76bd6d0.png)


Discussion:

Resolving patch:
diff --git a/viper/parser/expr.py b/viper/parser/expr.py
--- a/viper/parser/expr.py
+++ b/viper/parser/expr.py
@@ -285,6 +285,8 @@ def arithmetic(self):
         elif isinstance(self.expr.op, ast.Pow):
             if left.typ.positional or right.typ.positional:
                 raise TypeMismatchException("Cannot use positional values as exponential arguments!", self.expr)
+            if right.typ.unit:
+                raise TypeMismatchException("Cannot use unit values as exponents", self.expr)
             new_unit = combine_units(left.typ.unit, right.typ.unit)
             if ltyp == rtyp == 'num':
                 o = LLLnode.from_list(['exp', left, right], typ=BaseType('num', new_unit), pos=getpos(self.expr))


Test patch:
diff --git a/tests/parser/types/numbers/test_num.py b/tests/parser/types/numbers/test_num.py
--- a/tests/parser/types/numbers/test_num.py
+++ b/tests/parser/types/numbers/test_num.py
@@ -1,6 +1,8 @@
 import pytest
 from tests.setup_transaction_tests import chain as s, tester as t, ethereum_utils as u, check_gas, \
     get_contract_with_gas_estimation, get_contract, assert_tx_failed
+from viper.exceptions import TypeMismatchException
+
 
 def test_exponents_with_nums():
     exp_code = """
@@ -17,6 +19,7 @@ def _num_exp(x: num, y: num) -> num:
     assert c._num_exp(3,3) == 27
     assert c._num_exp(72,19) == 72**19
 
+
 def test_negative_nums(assert_tx_failed):
     negative_nums_code = """
 @public
@@ -33,6 +36,23 @@ def _negative_exp() -> num:
     assert c._negative_num() == -1
     assert c._negative_exp() == -3
 
+
+def test_exponents_with_units(assert_compile_failed):
+    code = """
+@public
+def foo() -> num(wei): 
+    a: num(wei)
+    b: num
+    c: num(wei)
+    a = 2
+    b = 2
+    c = a ** b
+    return c
+"""
+    c = get_contract_with_gas_estimation(code)
+    assert c.foo() == 4
+
+
 def test_num_bound(assert_tx_failed):
     num_bound_code = """
 @public
@@ -78,3 +98,15 @@ def _num_min() -> num:
 
     assert_tx_failed(lambda: c._num_add3(NUM_MAX, 1, -1))
     assert c._num_add3(NUM_MAX, -1, 1) == NUM_MAX
+
+
+def test_invalid_unit_exponent(assert_compile_failed):
+    code = """
+@public
+def foo():
+    a: num(wei)
+    b: num(wei)
+    c = a ** b
+"""
+    assert_compile_failed(lambda: get_contract_with_gas_estimation(code), TypeMismatchException)
+