[issue34377] Update valgrind suppressions

[Paul Price]

Change by Paul Price :


--
keywords: +patch
pull_requests: +8213
stage:  -> patch review

___
Python tracker 
<https://bugs.python.org/issue34377>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34377] Update valgrind suppressions

[Paul Price]

New submission from Paul Price :

I've found that the valgrind suppressions don't work for me with cpython 3.6.2. 
Renaming PyObject_Free/PyObject_Realloc to _PyObject_Free/_PyObject_Realloc in 
the suppressions file works.

I've got a patch that I'll put in via a GitHub PR.

--
components: Demos and Tools
messages: 323385
nosy: Paul Price
priority: normal
severity: normal
status: open
title: Update valgrind suppressions
type: enhancement
versions: Python 3.6

___
Python tracker 
<https://bugs.python.org/issue34377>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32889] Valgrind suppressions need updating

[Paul Price]

New submission from Paul Price <paul.antony.pr...@gmail.com>:

Using the current valgrind suppressions (Misc/valgrind-python.supp) results in 
a lot of noise, e.g.:

==2662549== Conditional jump or move depends on uninitialised value(s)
==2662549==at 0x4EFD734: address_in_range (obmalloc.c:1200)
==2662549==by 0x4EFD734: _PyObject_Free (obmalloc.c:1467)
==2662549==by 0x4FAA6A3: block_free (pyarena.c:95)
==2662549==by 0x4FAA6A3: PyArena_Free (pyarena.c:169)

The suppressions are blocking Py_ADDRESS_IN_RANGE, but this function was 
renamed in 3.6.

--
messages: 312436
nosy: Paul Price
priority: normal
pull_requests: 5563
severity: normal
status: open
title: Valgrind suppressions need updating
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32889>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

Paul Price added the comment:

Thanks!

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17409
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

Paul Price added the comment:

Not sure how you want patches formatted, so I went for 'git format-patch'.

Also, this is my first attempt at writing ReST and my first attempt at writing 
docs for Python, so you may want to double-check I didn't screw up the syntax 
or style.  Hopefully this doesn't cause more work than writing it yourself

--
keywords: +patch
Added file: 
http://bugs.python.org/file29530/0001-Docs-clarify-use-of-1-for-resource.setrlimit-Issue17.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17409
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

Paul Price added the comment:

P.S. This is relative to the 'default' branch in the public cpython.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17409
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

Paul Price added the comment:

That's good; it doesn't have what I added to the description of RLIMIT_NOFILE, 
but perhaps you chose to leave that out on purpose.

Since both unlimited and infinite are both used in different contexts, 
perhaps we should use both, e.g., infinite/unlimited?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17409
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

Paul Price added the comment:

You missed out an is:

   Raises :exc:`ValueError` if an invalid resource is specified, if the new soft
   limit exceeds the hard limit, or if a process tries to raise its hard limit
   (unless the process has an effective UID of super-user).  Specifying an
   infinite/unlmited limit when the hard or system limit for that resource 
**is** not
   unlimited will result in a :exc:`ValueError`.  ``setrlimit`` may also raise
:exc:`error` if the underlying system call fails.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17409
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

Paul Price added the comment:

The OSX manpage for setrlimit includes:

COMPATIBILITY
 setrlimit() now returns with errno set to EINVAL in places that histori-
 cally succeeded.  It no longer accepts rlim_cur = RLIM_INFINITY for
 RLIM_NOFILE.  Use rlim_cur = min(OPEN_MAX, rlim_max).

It's strange that this is not mentioned in the corresponding manpage on Ubuntu 
12.04.

It seems the reason we can't use -1 for RLIMIT_NOFILE is because this requests 
'unlimited' (RLIM_INFINITY), while there is always a limit on the number of 
open files (e.g., OPEN_MAX).

Looking at the code (Modules/resource.c), python is doing the sensible thing.  
It seems that resource.setrlimit would have to be special-cased for 
RLIMIT_NOFILE to work as documented when specifying a -1, but then python 
would be diverging from the behaviour of the underlying system call.

I therefore propose that the documentation simply be adjusted to note the 
observed behaviour (i.e., specifying -1 means 'unlimited', and does not work in 
general for RLIMIT_NOFILE).  I would be happy to provide a patch if this is 
desired.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17409
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17409] resource.setrlimit doesn't respect -1

[Paul Price]

New submission from Paul Price:

The docs for resource.setrlimit 
(http://docs.python.org/2.7/library/resource.html#resource.setrlimit) state: 
The limits argument must be a tuple (soft, hard) of two integers describing 
the new limits. A value of -1 can be used to specify the maximum possible upper 
limit.

On Mac OSX (10.7.5) with Python 2.7.3 (built fresh), I get the following 
behaviour:


$ PATH=$HOME/test/bin:$PATH DYLD_LIBRARY_PATH=$HOME/test/lib:$DYLD_LIBRARY_PATH 
python
Python 2.7.3 (default, Mar 13 2013, 11:02:56) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)] on darwin
Type help, copyright, credits or license for more information.
 import resource
 resource.setrlimit(resource.RLIMIT_NOFILE, (10, -1))
Traceback (most recent call last):
  File stdin, line 1, in module
ValueError: not allowed to raise maximum limit
 resource.setrlimit(resource.RLIMIT_NOFILE, (10, 10))
 


I get the same behaviour for the system python (2.7.3 built with GCC 4.6.3) in 
Ubuntu 12.04.1.

--
messages: 184086
nosy: Paul.Price
priority: normal
severity: normal
status: open
title: resource.setrlimit doesn't respect -1
type: behavior
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17409
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12612] Valgrind suppressions

[Paul Price]

Paul Price pr...@astro.princeton.edu added the comment:

Welcome.  Thank you!

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12612
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12612] Valgrind suppressions

[Paul Price]

Paul Price pr...@astro.princeton.edu added the comment:

Here's the diff with the added sections commented out.

--
keywords: +patch
Added file: http://bugs.python.org/file23831/proposed.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12612
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12612] Valgrind suppressions

[Paul Price]

New submission from Paul Price pr...@astro.princeton.edu:

I am running Python 2.7.1 under Valgrind 3.6.1 on a x86_64 GNU/Linux box.  
Valgrind is flagging errors that are not covered by the standard suppressions 
file (Misc/valgrind-python.supp; after uncommenting the part I'm supposed to), 
e.g.:

==5804== Use of uninitialised value of size 8
==5804==at 0x4EBA956: PyObject_Free (obmalloc.c:958)
==5804==by 0x4E85D65: code_dealloc (codeobject.c:317)
==5804==by 0x4ECE23C: tupledealloc (tupleobject.c:220)
==5804==by 0x4E85E42: code_dealloc (codeobject.c:308)
==5804==by 0x4F3315D: load_source_module (import.c:1022)
==5804==by 0x4F33F7E: import_submodule (import.c:2596)
==5804==by 0x4F3420E: load_next (import.c:2416)
==5804==by 0x4F3484F: import_module_level (import.c:2137)
==5804==by 0x4F34DA3: PyImport_ImportModuleLevel (import.c:2189)
==5804==by 0x4F16ABE: builtin___import__ (bltinmodule.c:49)
==5804==by 0x4E6DA42: PyObject_Call (abstract.c:2529)
==5804==by 0x4F16F82: PyEval_CallObjectWithKeywords (ceval.c:3881)

==5804== Use of uninitialised value of size 8
==5804==at 0x4EBA956: PyObject_Free (obmalloc.c:958)
==5804==by 0x4E85D65: code_dealloc (codeobject.c:317)
==5804==by 0x4F3315D: load_source_module (import.c:1022)
==5804==by 0x4F33F7E: import_submodule (import.c:2596)
==5804==by 0x4F3420E: load_next (import.c:2416)
==5804==by 0x4F3484F: import_module_level (import.c:2137)
==5804==by 0x4F34DA3: PyImport_ImportModuleLevel (import.c:2189)
==5804==by 0x4F16ABE: builtin___import__ (bltinmodule.c:49)
==5804==by 0x4E6DA42: PyObject_Call (abstract.c:2529)
==5804==by 0x4F16F82: PyEval_CallObjectWithKeywords (ceval.c:3881)
==5804==by 0x4F1ACD3: PyEval_EvalFrameEx (ceval.c:2332)
==5804==by 0x4F1F347: PyEval_EvalCodeEx (ceval.c:3252)

etc.

Perhaps the suppressions file covers only 32-bit machines, because if I add:

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Addr8
   fun:PyObject_Free
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Value8
   fun:PyObject_Free
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Addr8
   fun:PyObject_Realloc
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Value8
   fun:PyObject_Realloc
}

(i.e., Value8 instead of Value4) then all is clear.

--
components: None
messages: 140895
nosy: Paul.Price
priority: normal
severity: normal
status: open
title: Valgrind suppressions
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12612
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com