New submission from Xavier de Gaye xdeg...@gmail.com:
Description:
1. When deleting a single breakpoint, all the breakpoints located on
the line of this breakpoint are also deleted. See the test case
below.
2. The pdb 'clear' command documentation does not mention that all
New submission from Xavier de Gaye xdeg...@gmail.com:
Python 2.7 - svn revision 82852
Bug description
===
Test script foo.py
--
#!/usr/bin/env python
import distutils.core
import test.regrtest
Exception when running foo.py
Xavier de Gaye xdeg...@gmail.com added the comment:
http://pyclewn.sourceforge.net uses the regrtest module to run its
testsuite.
The test package is documented in the Standard Library documentation,
quote:
The test package contains all regression tests for Python as well
as the modules
Xavier de Gaye xdeg...@gmail.com added the comment:
Thanks for your comments, that was fast!
I will skip using the test package then.
--
status: pending - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9250
Changes by Xavier de Gaye xdeg...@gmail.com:
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9250
___
___
Python-bugs-list
New submission from Xavier de Gaye xdeg...@gmail.com:
Pdb skips frames after hitting a breakpoint and running step commands
that walk back the frame stack.
Run the following two tests with the two files named foo.py and bar.py:
=== foo.py
from
Changes by Xavier de Gaye xdeg...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13183
___
___
Python-bugs-list
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded restore_trace_2.patch that improves the test case.
--
Added file: http://bugs.python.org/file23418/restore_trace_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded restore_trace.py27.patch with a fix and test case for python 2.7.
--
Added file: http://bugs.python.org/file23419/restore_trace.py27.patch
___
Python tracker rep...@bugs.python.org
http
Xavier de Gaye xdeg...@gmail.com added the comment:
I am not marking 'test needed' since the problem is 'hardly reproducible'.
The attached script named 'asyncore_epipe.py' may be used to reproduce
systematically the EPIPE error on linux with Python 3.2:
* the Reader closes the socket
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded the patch 'epipe-default.patch' with a test case that breaks
on linux when EPIPE is not handled by asyncore, which is the case with
Python 3.2 and previous versions.
--
Added file: http://bugs.python.org/file23533/epipe
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded the same test case for Python 2.7.
--
Added file: http://bugs.python.org/file23534/epipe-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5661
Xavier de Gaye xdeg...@gmail.com added the comment:
Did you try with the current branches?
Yes, the test is pass against the current default and 2.7 branches.
One must remove EPIPE from the asyncore._DISCONNECTED frozenset to
make the test to fail.
Yes, see RFC1122 section 4.2.2.13
Xavier de Gaye xdeg...@gmail.com added the comment:
The test fails when use_poll is True.
The difference between using poll() and poll2():
poll: All the read events are processed before the write events,
so the close after the first recv by TestHandler will be followed
by a send
Xavier de Gaye xdeg...@gmail.com added the comment:
Actually the class asyncore.dispatcher_with_send do not handle
properly disconnection. When the endpoint shutdown his sending part
of the socket, but keep the socket open in reading, the current
implementation of dispatcher_with_send
Xavier de Gaye xdeg...@gmail.com added the comment:
Thanks for the explanations.
I confirm that the patch fixes 'asyncore_12498.py' with your changes
applied to this script.
Note that the patch may break applications that have given different
semantics to 'closing' ('closing' being
Xavier de Gaye xdeg...@gmail.com added the comment:
Note that the patch may break applications that have given different
semantics to 'closing' ('closing' being such a common name for a
network application) after they noticed that this attribute is never
used by asyncore nor by asynchat.
I
Changes by Xavier de Gaye xdeg...@gmail.com:
Added file: http://bugs.python.org/file23559/asyncore_shutdown.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12498
Xavier de Gaye xdeg...@gmail.com added the comment:
While writing the test case, I found out that the test case does not
fail before the patch. It seems that draining the output buffer
already works:
The attached script 'asyncore_shutdown.py' drains the output buffer
when run without the patch
Xavier de Gaye xdeg...@gmail.com added the comment:
That's because you didn't define a handle_read() method
Ooops...
Attached is a patch for dispatcher_with_send and asynchat with a test
case for each, that fail when the fix is not applied.
--
Added file: http://bugs.python.org
New submission from Xavier de Gaye xdeg...@gmail.com:
Add the following lines to test_handle_expt (this makes sense, a
dispatcher instance is supposed to implement handle_read and call recv
in order to detect that the remote end has closed the socket):
--- a/Lib/test/test_asyncore.py
+++ b/Lib
New submission from Xavier de Gaye xdeg...@gmail.com:
When the remote end disconnects, handle_close is only called if recv
is called (from handle_read). The default implementation of
handle_read does not call recv.
Not having the default implementation of handle_read call recv, has
Xavier de Gaye xdeg...@gmail.com added the comment:
Hi Charles-François,
And indeed, that's a known kernel regression introduced in 2.6.28,
and fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b634f87522dff87712df8bda2a6c9061954d552a
http
New submission from Xavier de Gaye xdeg...@gmail.com:
When an asyncore dispatcher initiates a tcp connection, its
representation lacks the peer address. The output of the attached
script 'dispatcher_addr.py' gives on linux with Python 3.2:
call stack in handle_connect_event:
module-main-loop
Changes by Xavier de Gaye xdeg...@gmail.com:
Added file: http://bugs.python.org/file23593/dispatcher_addr.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13325
Changes by Xavier de Gaye xdeg...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file23594/dispatcher_addr.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13325
Xavier de Gaye xdeg...@gmail.com added the comment:
Review done after Charles-François review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12498
Xavier de Gaye xdeg...@gmail.com added the comment:
Attached is a new patch following the code review.
After rewriting the asyncore test to check that the data has been
successfully received by the client, the test fails when
using poll() and a data size of 4096 bytes. The reason is that when
Xavier de Gaye xdeg...@gmail.com added the comment:
I'd say your patch can be useful only in case the dispatcher subclass
doesn't send() neither recv() any data, in which case the connection
is supposed to remain open forever.
There are some cases where it is important to detect
Xavier de Gaye xdeg...@gmail.com added the comment:
In this kind of situation, it is perfectly legitimate for the client
to perform a half-duplex close (shutdown(SHUT_WR)), since it does
not intend to send data (which is implied by the fact that the sever
doesn't implement an handle_read
Xavier de Gaye xdeg...@gmail.com added the comment:
I think the best would be to not handle POLLHUP events while POLLIN
is set, so that the handlers can have a chance to drain the input
socket buffer.
Ok.
But it's a separate issue, could you create a new one?
The test case fails
Xavier de Gaye xdeg...@gmail.com added the comment:
Follow my comments about half_duplex_close.diff (current latest patch).
+def handle_close(self):
+if not self._closing:
+self._closing = True
+# try to drain the output buffer
+while
Xavier de Gaye xdeg...@gmail.com added the comment:
this is the handling of a half-duplex disconnection on the remote
side ?
Actually this is not the handling of a half-duplex disconnection on the
remote side, but we need a half-duplex disconnection to test
Xavier de Gaye xdeg...@gmail.com added the comment:
Attached yet another patch.
This patch does not use a while loop in handle_close() and handles
POLLHUP as suggested by Charles-François. No changes have been made to
both tests (test_half_duplex_close).
--
Added file: http
New submission from Xavier de Gaye xdeg...@gmail.com:
When use_poll is True, test_handle_close in test_asyncore.py invokes
twice the handle_close() method.
The attached patch:
modifies test_handle_close so that it fails when handle_close() is
called more than once
includes a fix
Xavier de Gaye added the comment:
In the test named 'test_pdb_return_command_for_generator' in the patch, the
return command does not cause pdb to stop at the StopIteration debug event as
expected. Instead the following step command steps into the generator.
With the patch applied
Xavier de Gaye added the comment:
This new patch fixes the two problems described in my previous message.
The patch is different from Andrew's patch in that it does not use a new state
variable, and the test cases in the patch are a copy of Andrew's patch except
Xavier de Gaye added the comment:
When the generator is used in a for loop, the interpreter handles the
StopIteration in its eval loop, and the exception is not raised. So it may be
considered as confusing to have pdb behave differently with a generator
depending on its context. A way to fix
New submission from Xavier de Gaye:
The following debugging session, run with python on the default branch, shows
that pdb does not stop in __del__ when it is invoked.
The reason is:
- The destructor is not called when processing the 'c = 1' statement because
foo frame.f_locals owns
Xavier de Gaye added the comment:
Tracing/profiling is disabled when tstate-tracing is true or
tstate-use_tracing is false. The proposed patch fixes the problem by reducing
the scope where this condition is true.
As a consequence call_trace, profile_trampoline, trace_trampoline
Xavier de Gaye added the comment:
The 'until' command is also broken (by xdegaye's patch) when issued at a return
debug event and not debugging a generator.
This new patch fixes both problems.
The patch also adds another test case to check that pdb stops after a 'next',
'until' or 'return
New submission from Xavier de Gaye:
When f_trace is NULL, only PyTrace_CALL tracing events trigger the invocation of
the trace function (see trace_trampoline).
maybe_call_line_trace() does quite some work though _PyCode_CheckLineNumber to
find out if the instruction should be traced, and all
Changes by Xavier de Gaye xdeg...@gmail.com:
Added file: http://bugs.python.org/file28298/foo.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16672
Changes by Xavier de Gaye xdeg...@gmail.com:
Added file: http://bugs.python.org/file28299/bar.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16672
Xavier de Gaye added the comment:
When f_trace is NULL, only PyTrace_CALL tracing events trigger the invocation
of the trace function (see trace_trampoline).
This may be confusing. I meant that when f_trace is NULL, PyTrace_LINE,
PyTrace_RETURN and PyTrace_EXCEPTION are not traced
Xavier de Gaye added the comment:
This patch breaks extension modules (for example Ned Batchelder's
coverage.py) that use PyEval_SetTrace to set the trace function.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16653
Xavier de Gaye added the comment:
Same problem in 3.4.
$ ./python
Python 3.4.0a0 (default:e1bee8b09828, Jan 5 2013, 20:29:00)
[GCC 4.3.2] on linux
Type help, copyright, credits or license for more information.
import asyncore
a = asyncore.dispatcher()
del a.socket
a.foo
Traceback (most
Xavier de Gaye added the comment:
Still randomly getting ignored exceptions on 3.3 and the default
branch, got for example:
Exception TypeError: TypeError(argument of type 'NoneType' is not
iterable,) in function _removeHandlerRef at 0x7fcbe6014200 ignored
This happens in a threaded application
Changes by Xavier de Gaye xdeg...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file28743/teardown_module.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9501
Xavier de Gaye added the comment:
The reason why this happens in python 3.3.0 and not in 3.2:
1) lastResort holds a reference to an instance of _StderrHandler at
module tear down, thus potentially triggering a TypeError in
_removeHandlerRef.
2) The logging code has the following two
Xavier de Gaye added the comment:
The initial teardown_module.py can be simply replaced with
(not a contrived example anymore) the following statements
to print the spurious ignored Exceptions:
# Run the script in a loop:
# while [ 1 ]; do python3 teardown_module.py; sleep .1; done
import
Xavier de Gaye added the comment:
Yes, my last two messages refer to python 3.3.0 only.
The changes logged in http://bugs.python.org/issue9501#msg180039
do fix the behavior of both versions of teardown_module.py.
--
___
Python tracker rep
Xavier de Gaye added the comment:
Attached is a patch for the current head of 2.7.
It would nice to have this patch on 2.7 too.
With this patch, an implementation of pdb running on 2.7 with an
extension module, runs at 1.2 times the speed of the interpreter when
the trace function is active
Xavier de Gaye added the comment:
One may argue that this is not only a performances patch and that it
fixes the wasting of cpu resources when tracing is on. Wasting cpu
resources is a bug. Anyway, this is fine with me to close this minor
issue on 2.7.
The test_hotshot test is ok on my linux
Xavier de Gaye added the comment:
The patch applied to the default branch should be reverted.
The 2.7 _hotshot extension module follows the specifications of PyEval_SetTrace:
Set the tracing function to func. This is similar to PyEval_SetProfile(),
except the tracing function does receive
Xavier de Gaye added the comment:
It is not possible to improve the performances of the trace function set with
sys.settrace without breaking backward compatibility for PyEval_SetTrace or
without introducing a new PyEval_xxx of some sort.
Yes, I suggest to revert this patch
Xavier de Gaye added the comment:
status should be close, I guess.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16672
___
___
Python-bugs-list
New submission from Xavier de Gaye:
The following test illustrates the problem.
script.py contains the line 1 / 0.
The 'bt' command is also wrong.
$ python3 -m pdb script.py
/tmp/script.py(1)module()
- 1 / 0
(Pdb) continue
Traceback (most recent call last):
File /usr/local/lib/python3.3
New submission from Xavier de Gaye:
An 'ignore' pdb command issued without any parameter raises IndexError.
--
components: Library (Lib)
messages: 181633
nosy: xdegaye
priority: normal
severity: normal
status: open
title: the 'ignore' pdb command raises IndexError
type: behavior
Changes by Xavier de Gaye xdeg...@gmail.com:
--
nosy: +xdegaye
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16956
___
___
Python-bugs-list
Xavier de Gaye added the comment:
How does this interact with pdb?
Also, the findlinestarts() function from the dis module computes line
numbers from lnotab. This function is used by pdb when displaying the
lines of a traceback.
--
___
Python
Xavier de Gaye added the comment:
This is fixed in python 3.2 by changeset 670d4cbf1464, and indeed the
'' marker is shown at line 8 of pdb_list_bug_reproduce.py when
debugging this (modified for py3) script with python 3.2.
--
nosy: +xdegaye
New submission from Xavier de Gaye:
It seems that using f_trace in the f_lineno getter PyFrame_GetLineNumber(), as
the condition to decide when tracing is active, is incorrect.
See the following two examples.
In the backtrace printed by tracer.py running with python 3.3,
the last entry should
Changes by Xavier de Gaye xdeg...@gmail.com:
Added file: http://bugs.python.org/file29163/generator.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17277
Xavier de Gaye added the comment:
The patch (on the default branch) reverts one of the changes made in r72488 to
introduce the new PyFrame_GetLineNumber() function (issue 5954): tb_lineno is
now back again the result of the call to PyCode_Addr2Line() instead of the
call to PyFrame_GetLineNumber
Xavier de Gaye added the comment:
The proposed patch fixes the backtrace line numbers issue, but it does not fix
PyFrame_GetLineNumber() which is the recommended way to get the frame line
number.
As mentionned in the original message, testing for f-f_trace to implement the
f_lineno getter
Xavier de Gaye added the comment:
fix the issue by changing PyFrame_GetLineNumber() and the f_lineno accessors
The new patch named traced_frame.patch has been uploaded.
Also, now it is not allowed anymore to set the f_lineno attribute of a frame
that is not the frame being traced, as f_lasti
New submission from Xavier de Gaye:
On python 3.3 and the default branch, the jump from a 'return' fails although
the change to f_lineno is validated, see below.
This problem does not occur with python 2.7.
$ python return.py
/tmp/return.py(8)module()
- foo()
(Pdb) break 5
Breakpoint 1
Xavier de Gaye added the comment:
Oops, it occurs too with python 2.7.
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17288
Xavier de Gaye added the comment:
There is an error in my patch (already fixed in pdb-clone) and in Jyrki's patch.
Running Jyrki's patch on quit.py produces the following output where the line
number in the last entry of the backtrace is incorrect (should be line 9 instead
of line 7):
$ python
Xavier de Gaye added the comment:
The patch changes the semantics of the quit command: quit behaves like the gdb
detach command when pdb is started with set_trace.
--
Added file: http://bugs.python.org/file29232/branch-27.patch
___
Python tracker rep
Xavier de Gaye added the comment:
The traced_frame.patch fixes also issue 7238 and issue 16482.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17277
Xavier de Gaye added the comment:
Nosying Benjamin Peterson who knows frame_setlineno (issue 14612) and nosying
Jesús Cea Avión. Hoping they don't mind.
This problem occurs also when setting f_lineno from an exception debug event.
One may crash the interpreter (or get a SystemError: unknown
Xavier de Gaye added the comment:
The proposed patch fixes the problem:
* f_lineno cannot be set now from an exception trace function or from a return
trace function.
* The broken arithmetic involving a null pointer (f-f_stacktop, at the end of
frame_setlineno when popping blocks
Xavier de Gaye added the comment:
Must add for completeness that f_lineno must be valid within a return trace
function for the reasons explained in the last paragraph of
Objects/lnotab_notes.txt.
--
___
Python tracker rep...@bugs.python.org
http
New submission from Xavier de Gaye xdeg...@gmail.com:
The 'Advanced Logging Tutorial' states about the lastResort handler:
The handler’s level is set to WARNING, so all events at this and
greater severities will be output.
Python 3.2 does not follow this behavior:
Python 3.2 (r32:88445, Jun 18
New submission from Xavier de Gaye xdeg...@gmail.com:
A regression occurs in python 3.2 when doing a copy of an asyncore
dispatcher.
$ python3.1
Python 3.1.2 (r312:79147, Apr 4 2010, 17:46:48)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
import
Xavier de Gaye xdeg...@gmail.com added the comment:
The infinite recursion occurs also when running python 3.2 with the
extension modules copy, copyreg and asyncore from python 3.1. So it
seems this regression is not caused by a modification in these
modules.
Anyway, the bug is in asyncore
Xavier de Gaye xdeg...@gmail.com added the comment:
About why the asyncore bug shows up in python 3.2:
The simple test below is ok with python 3.1 but triggers a
RuntimeError: maximum recursion depth exceeded... with python 3.2:
$ python3.1
Python 3.1.2 (r312:79147, Apr 4 2010, 17:46:48
Xavier de Gaye xdeg...@gmail.com added the comment:
So, in 3.1 hasattr(y, '__setstate__') *did* recurse and hit the limit,
but the exception was caught and hasattr returned False?
This is right.
I think I prefer the new behavior...
The patch looks good, I would simply have raised
New submission from Xavier de Gaye xdeg...@gmail.com:
In the following test both breakpoints are set on the line of a
function definition. However pdb does not stop when entering foo whose
breakpoint has been set with 'break 1' while pdb stops when entering
bar whose breakpoint has been set
Xavier de Gaye xdeg...@gmail.com added the comment:
Hi Petri
I have just sent the Contributor Agreement to PSF.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14798
New submission from Xavier de Gaye xdeg...@gmail.com:
In the following session, main.py is changed just before the restart
command. Pdb does not stop at Breakpoint 1 after the last continue.
$ python -m pdb main.py
/path_to/main.py(1)module()
- def foo():
(Pdb) import sys; print(sys.version
New submission from Xavier de Gaye xdeg...@gmail.com:
Pdb behavior is not consistent with GNU gdb behavior when setting a
breakpoint on an empty line, a comment or a multi-line statement (the
breakpoint is ignored by pdb on a non-first line of a multi-line
statement and rejected on empty lines
Xavier de Gaye xdeg...@gmail.com added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14789
Xavier de Gaye xdeg...@gmail.com added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14792
Xavier de Gaye xdeg...@gmail.com added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14795
Xavier de Gaye xdeg...@gmail.com added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14808
Xavier de Gaye xdeg...@gmail.com added the comment:
Parsing the modules source seems a better way to fix this problem, see issue
14913.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14912
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded pdb_default_2.patch.
This new patch fixes the previous patch that fails to stop at
breakpoints set in nested functions, and extends the previous patch in
allowing breakpoints outside function and method definitions.
When a breakpoint
Xavier de Gaye xdeg...@gmail.com added the comment:
This message is just a reminder that this 4 months old issue raises
the point that the step command in pdb is broken. A patch and test
case have been proposed.
No comment so far.
As the author of pyclewn, a Vim front end to pdb and gdb, I
Xavier de Gaye xdeg...@gmail.com added the comment:
Hi Senthil,
Thanks for your help with this issue.
self.frame_returning is both a flag to indicate that we are returning
from the current frame and a value (the current frame). We need both
as set_step() (the method invoked when the user runs
Xavier de Gaye xdeg...@gmail.com added the comment:
My fault :(
The call to print is useless for the test, so I suggest to replace it
with a plain 'pass' statement.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13183
Xavier de Gaye xdeg...@gmail.com added the comment:
The test has been changed in the default branch by changeset
1b174a117e19. This change replaces the assertIn by a less restrictive
assertTrue. These changes should also probably be made in 3.2 and 2.7
and hopefully this will fix the problem
New submission from Xavier de Gaye xdeg...@gmail.com:
The issue 13183 raises the problem that when the trace function is not
set in the caller frame, the step command fails at a return statement.
This new issue raises the point that, for the same reason:
* the next, until and return
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded pdb_default.patch that applies on the default branch with
minor changes to the initial pdb.patch.
--
Added file: http://bugs.python.org/file25463/pdb_default.patch
___
Python tracker rep
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded pdb_2.7.patch that applies on the 2.7 branch.
--
Added file: http://bugs.python.org/file25464/pdb_2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14728
New submission from Xavier de Gaye xdeg...@gmail.com:
All the problems raised in this issue are caused by self.botframe
being set in a Pdb frame.
In the following pdb session run with python 3.2.2, the first two
frames in the printed stack are Pdb frames, this is wrong. And the
second step
Xavier de Gaye xdeg...@gmail.com added the comment:
Note that now that this issue is fixed, issue 14743 has become more
visible.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13183
Xavier de Gaye xdeg...@gmail.com added the comment:
Uploaded a new patch, pdb_botframe_default_2.patch (that applies to
the current tip of the default branch) with:
* a correction to the initial change made to fix sigint_handler()
* the two test cases
--
Added file: http
1 - 100 of 1480 matches
Mail list logo
