[issue7742] please avoid 'which' in Modules/ld_so_aix

[Brian Curtin]

Changes by Brian Curtin :


--
components: +None
keywords: +needs review
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7

___
Python tracker 

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

[issue7712] Add a context manager to change cwd in test.test_support

[Florent Xicluna]

Florent Xicluna  added the comment:

Different approach, after some other talks with Ezio and David.

Now the directory is changed before running any test.
The developer can assume that the current directory if always writable.
It makes the tests easier to write, and repeatable.

Additionally, TESTFN always contains a single filename (without path).
Before this change, it could be "/tmp/@test" or "@test", which is error-prone.

The decorator becomes useless.

--
Added file: http://bugs.python.org/file15956/issue7712_context_manager.diff

___
Python tracker 

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

[issue7742] please avoid 'which' in Modules/ld_so_aix

[Michael Haubenwallner]

Michael Haubenwallner  added the comment:

Uhm, as I read the patch again, there's room for improvement of pywhich():
it likely fails with CC=/full/path/to/cc

--

___
Python tracker 

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

[issue7742] please avoid 'which' in Modules/ld_so_aix

[Michael Haubenwallner]

New submission from Michael Haubenwallner :

In Modules/ld_so_aix there is `which $CC` to search for the full compiler's 
path.

Unfortunately, /usr/bin/which on AIX is a csh-script and thus ~/.cshrc gets 
sourced before doing the path search.

Now, when the user does set some PATH in ~/.cshrc, `which` might print a wrong 
path for the compiler, causing the build to fail (at best).

It would be better to do the path search without launching an external program.

--
files: ld_so_aix-which.patch
keywords: patch
messages: 98070
nosy: haubi
severity: normal
status: open
title: please avoid 'which' in Modules/ld_so_aix
versions: Python 3.2
Added file: http://bugs.python.org/file15955/ld_so_aix-which.patch

___
Python tracker 

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

[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL

[Doron Tal]

Doron Tal  added the comment:

We didn't prove this point yet, currently it's merely circumstantial.
The application calls strftime few dozen times each second from different
threads. We spot the stall using another two threads, the first takes a time
stamp before calling a python function and reset the time stamp when the
python function is done. The other thread watches the timestamp and if it
gets over a certain limit (2 seconds) it aborts the process, leaving a core
dump behind.

We've build this infrastructure to tackle python stalls caused by
misbehaving C calls which takes long but does not release the GIL.

Here is the traceback (one of the threads):

#0  0x003424ac5800 in __open_nocancel () from /lib64/libc.so.6

#1  0x003424a6c383 in __GI__IO_file_open () from /lib64/libc.so.6

#2  0x003424a6c43c in _IO_new_file_fopen () from /lib64/libc.so.6

#3  0x003424a61764 in __fopen_internal () from /lib64/libc.so.6

#4  0x003424a8d666 in __tzfile_read () from /lib64/libc.so.6

#5  0x003424a8c56f in tzset_internal () from /lib64/libc.so.6

#6  0x003424a8d010 in tzset () from /lib64/libc.so.6

#7  0x003424a91934 in strftime_l () from /lib64/libc.so.6

#8  0x2aea01bced34 in ?? () from

/usr/lib64/python2.4/lib-dynload/timemodule.so

#9  0x0034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0 #10 0x003430436bbc in PyObject_CallMethod
() from /usr/lib64/libpython2.4.so.1.0

#11 0x2aea01dda64a in ?? () from

/usr/lib64/python2.4/lib-dynload/datetime.so

#12 0x2aea01dda9c3 in ?? () from

/usr/lib64/python2.4/lib-dynload/datetime.so

#13 0x0034304950ba in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#14 0x003430494b66 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#15 0x003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0

#16 0x00343044c45a in ?? () from /usr/lib64/libpython2.4.so.1.0

#17 0x0034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#18 0x00343049352c in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#19 0x003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0 #20 0x00343044c45a in ?? () from
/usr/lib64/libpython2.4.so.1.0

#21 0x0034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#22 0x00343049352c in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#23 0x003430494b66 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#24 0x003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0

#25 0x00343044c367 in ?? () from /usr/lib64/libpython2.4.so.1.0

#26 0x0034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#27 0x00343043c1ef in ?? () from /usr/lib64/libpython2.4.so.1.0

#28 0x0034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#29 0x00343048fc3d in PyEval_CallObjectWithKeywords () from
/usr/lib64/libpython2.4.so.1.0 #30 0x0034304d in ?? () from
/usr/lib64/libpython2.4.so.1.0

#31 0x0034256064a7 in start_thread () from /lib64/libpthread.so.0

#32 0x003424ad3c2d in clone () from /lib64/libc.so.6

So, we didn't actually proved that opening /etc/localtime takes so long. I
assumed that it is better to release the GIL prior to opening a file.

In any case, it won't solve our problem, since we use old Python 2.4.3
(CentOS5.4)...

--doron

On Tue, Jan 19, 2010 at 10:27 PM, Martin v. Löwis 
wrote:

>
> Martin v. Löwis  added the comment:
>
> I'd also be curious why it takes a second to open /etc/localtime. That
> sounds like a bug in the C library, or a mismanaged system.
>
> --
> nosy: +loewis
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: http://bugs.python.org/file15954/unnamed

___
Python tracker 

___We didn't prove this point yet, currently it's merely 
circumstantial.The application calls strftime few dozen times each second 
from different threads. We spot the stall using another two threads, the first 
takes a time stamp before calling a python function and reset the time stamp 
when the python function is done. The other thread watches the timestamp and if 
it gets over a certain limit (2 seconds) it aborts the process, leaving a core 
dump behind.
We've build this infrastructure to tackle python stalls caused by 
misbehaving C calls which takes long but does not release the GIL.Here 
is the traceback (one of the threads):