date:20070401

[ python-Bugs-1692280 ] lambda function segfault

2007-04-01 Thread SourceForge.net

Bugs item #1692280, was opened at 2007-04-01 18:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692280&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dasn (dasn)
Assigned to: Nobody/Anonymous (nobody)
Summary: lambda function segfault

Initial Comment:
>>> lambda ((x,y)): 'ok'
Segment fault (core dumped).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692280&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1692280 ] lambda function segfault

2007-04-01 Thread SourceForge.net

Bugs item #1692280, was opened at 2007-04-01 18:05
Message generated for change (Settings changed) made by dasn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692280&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Private: No
Submitted By: Dasn (dasn)
Assigned to: Nobody/Anonymous (nobody)
Summary: lambda function segfault

Initial Comment:
>>> lambda ((x,y)): 'ok'
Segment fault (core dumped).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692280&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1692280 ] lambda function segfault

2007-04-01 Thread SourceForge.net

Bugs item #1692280, was opened at 2007-04-01 10:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692280&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Out of Date
Priority: 9
Private: No
Submitted By: Dasn (dasn)
Assigned to: Nobody/Anonymous (nobody)
Summary: lambda function segfault

Initial Comment:
>>> lambda ((x,y)): 'ok'
Segment fault (core dumped).

--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-04-01 10:15

Message:
Logged In: YES 
user_id=849994
Originator: NO

Thanks, this is already fixed in SVN and will be part of 2.5.1, which is
scheduled to be released soon.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692280&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1692592 ] Stripping debugging symbols from compiled C extensions

2007-04-01 Thread SourceForge.net

Feature Requests item #1692592, was opened at 2007-04-02 01:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1692592&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Stripping debugging symbols from compiled C extensions

Initial Comment:
It would be nice to automatically strip debugging symbols from compiled library 
files (such as .so files) if a C extension module is not build in debug mode. 
This could somehow reduce memory footprint and storage requirements for 
extension modules.

Distutils already does this for cygwin and emx compilers with the following 
code in cygwinccompiler.py and emxccompiler.py:

# who wants symbols and a many times larger output file
# should explicitly switch the debug mode on
# otherwise we let dllwrap/ld strip the output file
# (On my machine: 10KB < stripped_file < ??100KB
#   unstripped_file = stripped_file + XXX KB
#  ( XXX=254 for a typical python extension))
if not debug:
extra_preargs.append("-s")

This code should be somehow integrated into base compiler classes such as 
UnixCCompiler. I've added the following at the beginning of UnixCCompiler.link 
function:

if not debug:
if extra_preargs is None:
extra_preargs = []
extra_preargs.append("-s")

This works for me with gcc under Linux (Debian Sarge). I does not provide a 
patch, since this could be the best solution for this.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1692592&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1689458 ] pdb unable to jump to first statement

2007-04-01 Thread SourceForge.net

Bugs item #1689458, was opened at 2007-03-27 16:07
Message generated for change (Comment added) made by gotgenes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Lasher (gotgenes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb unable to jump to first statement

Initial Comment:
The Python debugger is unable to "jump" back to the first executable statement 
in a frame once that statement has been executed. For example:

[EMAIL PROTECTED]:~/development/playground$ python -m pdb simple.py 
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) next
> /home/chris/development/playground/simple.py(4)?()
-> b = 2
(Pdb) jump 3
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) list
  1 #!/usr/bin/env python
  2  
  3 a = 1
  4  -> b = 2
  5  
  6 c = a + b
  7  
  8 print c
[EOF]
(Pdb) next
> /home/chris/development/playground/simple.py(6)?()
-> c = a + b

One can see that after supposedly "jump"ing to line 3 at the second command, 
when "list"ing the line, the debugger is actually at line 4. The "next" command 
further demonstrates this since it re-executes line 4 and moves to line 6.

This issue was raised on comp.lang.python. (For example, see

or if that link is munged, refer to


Duncan Booth offers the following:
[quote]
I verified (with a print statement in pdb) that assigning to 
self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti 
incorrectly

...

The problem looks to be in frameobject.c:

addr = 0;
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
addr += lnotab[offset];
line += lnotab[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
break;
}
}

The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 
1). If line==f->f_code->co_firstlineno it should set new_lasti=0, 
new_lineno=line but the loop still executes once which increments new_lasti and 
new_lineno to the next line (6, 4).
[/quote]

And Rocky Bernstein offers the following:
[quote]
Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle 
the "jump" command by changing the frame f_lineno value. When the corresponding 
code pointer has offset 0 (or equivalently and more simlply as you put it, is 
the first statement) this doesn't seem to work properly.
[/quote]

--

>Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 18:53

Message:
Logged In: YES 
user_id=1180453
Originator: YES

I'm changing the category. Apparently this is a bug in the Python core,
itself, not pdb.

>From Rocky Bernstein on comp.lang.python
[quote]
At present it looks like the bug is in Python, and its handling after
setting the current frame's f_lineno when it refers to byte code offset 0,
not pdb.
[/quote]

--

Comment By: Rocky Bernstein (rockyb)
Date: 2007-03-31 05:32

Message:
Logged In: YES 
user_id=158581
Originator: NO

Although a single file unit test would be nice, below is a short simple
program that I think clearly shows the bug. Alas, as a follow-up comment I
don't see a way to attach files so I have to paste it inline. However with
this example and the information from Duncan Booth, I think the problem and
how to fix it is pretty clear.

file: jumpbug.py

#!/usr/bin/env python
import inspect, linecache, sys
def tracer(frame, event, arg):
global z
(filename, line_no) = inspect.getframeinfo(frame)[0:2]
print "Event %s at line %d:" % (event, line_no)
print "\t", linecache.getline(filename, line_no),
print "--"
try: 
if z == 0:
if line_no == 4:
print "***We jumped back to line 4 but should have gone to
2**"
sys.exit(1)
frame.f_lineno = 2 # And 3 is broken too.
except NameError:
pass
return tracer # This helps emacs figure indentation out
sys.settrace(tracer)
execfile("jumpbug2.py")
#END first file

file jumpbug2.py:

#!/usr/bin/env python
x = 2  # This statement gets skipped the 2nd time around
q = 1  # This statement gets skipped too!
try:   # tracer() will exit here if z == 0 and line_no == 4
y = z   
except NameError:
z = 0
print "When tracing via tracer(), f

[ python-Bugs-1689458 ] pdb unable to jump to first statement

2007-04-01 Thread SourceForge.net

Bugs item #1689458, was opened at 2007-03-27 16:07
Message generated for change (Comment added) made by gotgenes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Lasher (gotgenes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb unable to jump to first statement

Initial Comment:
The Python debugger is unable to "jump" back to the first executable statement 
in a frame once that statement has been executed. For example:

[EMAIL PROTECTED]:~/development/playground$ python -m pdb simple.py 
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) next
> /home/chris/development/playground/simple.py(4)?()
-> b = 2
(Pdb) jump 3
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) list
  1 #!/usr/bin/env python
  2  
  3 a = 1
  4  -> b = 2
  5  
  6 c = a + b
  7  
  8 print c
[EOF]
(Pdb) next
> /home/chris/development/playground/simple.py(6)?()
-> c = a + b

One can see that after supposedly "jump"ing to line 3 at the second command, 
when "list"ing the line, the debugger is actually at line 4. The "next" command 
further demonstrates this since it re-executes line 4 and moves to line 6.

This issue was raised on comp.lang.python. (For example, see

or if that link is munged, refer to


Duncan Booth offers the following:
[quote]
I verified (with a print statement in pdb) that assigning to 
self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti 
incorrectly

...

The problem looks to be in frameobject.c:

addr = 0;
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
addr += lnotab[offset];
line += lnotab[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
break;
}
}

The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 
1). If line==f->f_code->co_firstlineno it should set new_lasti=0, 
new_lineno=line but the loop still executes once which increments new_lasti and 
new_lineno to the next line (6, 4).
[/quote]

And Rocky Bernstein offers the following:
[quote]
Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle 
the "jump" command by changing the frame f_lineno value. When the corresponding 
code pointer has offset 0 (or equivalently and more simlply as you put it, is 
the first statement) this doesn't seem to work properly.
[/quote]

--

>Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 19:06

Message:
Logged In: YES 
user_id=1180453
Originator: YES

File Added: jumpbug.py

--

Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 18:53

Message:
Logged In: YES 
user_id=1180453
Originator: YES

I'm changing the category. Apparently this is a bug in the Python core,
itself, not pdb.

>From Rocky Bernstein on comp.lang.python
[quote]
At present it looks like the bug is in Python, and its handling after
setting the current frame's f_lineno when it refers to byte code offset 0,
not pdb.
[/quote]

--

Comment By: Rocky Bernstein (rockyb)
Date: 2007-03-31 05:32

Message:
Logged In: YES 
user_id=158581
Originator: NO

Although a single file unit test would be nice, below is a short simple
program that I think clearly shows the bug. Alas, as a follow-up comment I
don't see a way to attach files so I have to paste it inline. However with
this example and the information from Duncan Booth, I think the problem and
how to fix it is pretty clear.

file: jumpbug.py

#!/usr/bin/env python
import inspect, linecache, sys
def tracer(frame, event, arg):
global z
(filename, line_no) = inspect.getframeinfo(frame)[0:2]
print "Event %s at line %d:" % (event, line_no)
print "\t", linecache.getline(filename, line_no),
print "--"
try: 
if z == 0:
if line_no == 4:
print "***We jumped back to line 4 but should have gone to
2**"
sys.exit(1)
frame.f_lineno = 2 # And 3 is broken too.
except NameError:
pass
return tracer # This helps emacs figure indentation out
sys.settrace(tracer)
execfile("jumpbug2.py")
#END first file

file jumpbug2.py:

#!/usr/bin/env python
x = 2  # This statemen

[ python-Bugs-1689458 ] pdb unable to jump to first statement

2007-04-01 Thread SourceForge.net

Bugs item #1689458, was opened at 2007-03-27 16:07
Message generated for change (Comment added) made by gotgenes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1689458&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Lasher (gotgenes)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb unable to jump to first statement

Initial Comment:
The Python debugger is unable to "jump" back to the first executable statement 
in a frame once that statement has been executed. For example:

[EMAIL PROTECTED]:~/development/playground$ python -m pdb simple.py 
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) next
> /home/chris/development/playground/simple.py(4)?()
-> b = 2
(Pdb) jump 3
> /home/chris/development/playground/simple.py(3)?()
-> a = 1
(Pdb) list
  1 #!/usr/bin/env python
  2  
  3 a = 1
  4  -> b = 2
  5  
  6 c = a + b
  7  
  8 print c
[EOF]
(Pdb) next
> /home/chris/development/playground/simple.py(6)?()
-> c = a + b

One can see that after supposedly "jump"ing to line 3 at the second command, 
when "list"ing the line, the debugger is actually at line 4. The "next" command 
further demonstrates this since it re-executes line 4 and moves to line 6.

This issue was raised on comp.lang.python. (For example, see

or if that link is munged, refer to


Duncan Booth offers the following:
[quote]
I verified (with a print statement in pdb) that assigning to 
self.curframe.f_lineno sets self.curframe.f_lineno and sel.curframe.f_lasti 
incorrectly

...

The problem looks to be in frameobject.c:

addr = 0;
line = f->f_code->co_firstlineno;
new_lasti = -1;
for (offset = 0; offset < lnotab_len; offset += 2) {
addr += lnotab[offset];
line += lnotab[offset+1];
if (line >= new_lineno) {
new_lasti = addr;
new_lineno = line;
break;
}
}

The first bytes in lnotab are the length and line increment for line 3 (i.e. 6, 
1). If line==f->f_code->co_firstlineno it should set new_lasti=0, 
new_lineno=line but the loop still executes once which increments new_lasti and 
new_lineno to the next line (6, 4).
[/quote]

And Rocky Bernstein offers the following:
[quote]
Best as I can tell, it looks like a bug in Python. pdb, pydb, rpdb2 all handle 
the "jump" command by changing the frame f_lineno value. When the corresponding 
code pointer has offset 0 (or equivalently and more simlply as you put it, is 
the first statement) this doesn't seem to work properly.
[/quote]

--

>Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 19:07

Message:
Logged In: YES 
user_id=1180453
Originator: YES

File Added: jumpbug2.py

--

Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 19:06

Message:
Logged In: YES 
user_id=1180453
Originator: YES

File Added: jumpbug.py

--

Comment By: Chris Lasher (gotgenes)
Date: 2007-04-01 18:53

Message:
Logged In: YES 
user_id=1180453
Originator: YES

I'm changing the category. Apparently this is a bug in the Python core,
itself, not pdb.

>From Rocky Bernstein on comp.lang.python
[quote]
At present it looks like the bug is in Python, and its handling after
setting the current frame's f_lineno when it refers to byte code offset 0,
not pdb.
[/quote]

--

Comment By: Rocky Bernstein (rockyb)
Date: 2007-03-31 05:32

Message:
Logged In: YES 
user_id=158581
Originator: NO

Although a single file unit test would be nice, below is a short simple
program that I think clearly shows the bug. Alas, as a follow-up comment I
don't see a way to attach files so I have to paste it inline. However with
this example and the information from Duncan Booth, I think the problem and
how to fix it is pretty clear.

file: jumpbug.py

#!/usr/bin/env python
import inspect, linecache, sys
def tracer(frame, event, arg):
global z
(filename, line_no) = inspect.getframeinfo(frame)[0:2]
print "Event %s at line %d:" % (event, line_no)
print "\t", linecache.getline(filename, line_no),
print "--"
try: 
if z == 0:
if line_no == 4:
print "***We jumped back to line 4 but should have gone to
2**"
sys.exit(1)
frame.f_lineno = 2 # And 3 is broken too.
e

[ python-Bugs-1692280 ] lambda function segfault

[ python-Bugs-1692280 ] lambda function segfault

[ python-Bugs-1692280 ] lambda function segfault

[ python-Feature Requests-1692592 ] Stripping debugging symbols from compiled C extensions

[ python-Bugs-1689458 ] pdb unable to jump to first statement

[ python-Bugs-1689458 ] pdb unable to jump to first statement

[ python-Bugs-1689458 ] pdb unable to jump to first statement

7 matches

Site Navigation

Mail list logo

Footer information