Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #16933 > unrolled thread

Multiprocessing bug, is information ever omitted from a traceback?

Back to article view | Back to comp.lang.python

Contents

  Multiprocessing bug, is information ever omitted from a traceback? John Ladasky <ladasky@my-deja.com> - 2011-12-09 15:14 -0800
    Re: Multiprocessing bug, is information ever omitted from a traceback? Terry Reedy <tjreedy@udel.edu> - 2011-12-10 00:00 -0500
      Re: Multiprocessing bug, is information ever omitted from a traceback? John Ladasky <ladasky@my-deja.com> - 2011-12-10 09:53 -0800
        Re: Multiprocessing bug, is information ever omitted from a traceback? Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-10 12:38 -0600
          Re: Multiprocessing bug, is information ever omitted from a traceback? John Ladasky <ladasky@my-deja.com> - 2011-12-10 11:02 -0800
        Re: Multiprocessing bug, is information ever omitted from a traceback? Chris Angelico <rosuav@gmail.com> - 2011-12-11 06:02 +1100
        Re: Multiprocessing bug, is information ever omitted from a traceback? Terry Reedy <tjreedy@udel.edu> - 2011-12-10 18:57 -0500

#16933 — Multiprocessing bug, is information ever omitted from a traceback?

Hi folks,

A tangent off of this thread:

http://groups.google.com/group/comp.lang.python/browse_frm/thread/751b7050c756c995#

I'm programming in Python 2.6 on Ubuntu Linux 10.10, if it matters.

I'm trying to track down a multiprocessing bug. Here's my traceback.
All lines of code referenced in the traceback are in the standard
library code:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 532, in
__bootstrap_inner
    self.run()
  File "/usr/lib/python2.6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.6/multiprocessing/pool.py", line 284, in
_handle_tasks
    put(task)
TypeError: expected string or Unicode object, NoneType found

Fortunately, I have a working version of my code.  I was trying to add
new features, and only my new code is causing trouble.  This has
allowed me to examine the contexts of task when everything works.

Task is not a string when the program works.  Task is not None when
the program doesn't work.  In fact, task is a deeply-nested tuple.  NO
PART of this tuple ever contains any strings, as far as I can tell.
More details in my original thread.

Now, of course I've seen that the standard traceback shows you the
lines where various steps in a chain of function calls were taken.
The traceback skips over any lines in the code between successive
function calls, and assumes that you can follow along.  No problem, I
can do that.

But when multiprocessing is involved, can this traceback be truncated
in some way, for example when code execution switches over to a
subprocess?  I'm wondering if more code is getting executed after
"put(task)" that I'm not seeing.

Thanks for any information!

[toc] | [next] | [standalone]

#16942

On 12/9/2011 6:14 PM, John Ladasky wrote:

> http://groups.google.com/group/comp.lang.python/browse_frm/thread/751b7050c756c995#
>
> I'm programming in Python 2.6 on Ubuntu Linux 10.10, if it matters.

It might, as many bugs have been fixed since.
Can you try the same code with the most recent 2.x release, 2.7.2?
Do you have working and non-working code that you can publicly release?
Can you reduce the size and dependencies so the examples are closer to 
'small' than 'large'? And in any case, self-contained?

In my first response, I said you might have found a bug. A bogus 
exception message qualifies. But to do much, we need minimal good/bad 
examples that run or not on a current release (2.7.2 or 3.2.2).

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#16959

On Dec 9, 9:00 pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 12/9/2011 6:14 PM, John Ladasky wrote:
>
> >http://groups.google.com/group/comp.lang.python/browse_frm/thread/751...
>
> > I'm programming in Python 2.6 on Ubuntu Linux 10.10, if it matters.
>
> It might, as many bugs have been fixed since.
> Can you try the same code with the most recent 2.x release, 2.7.2?
> Do you have working and non-working code that you can publicly release?
> Can you reduce the size and dependencies so the examples are closer to
> 'small' than 'large'? And in any case, self-contained?
>
> In my first response, I said you might have found a bug. A bogus
> exception message qualifies. But to do much, we need minimal good/bad
> examples that run or not on a current release (2.7.2 or 3.2.2).
>
> --
> Terry Jan Reedy

All right, Terry, you've convinced me to look.  This will take some
time.  I'll hack away at the two versions of my 500-line programs,
until I have a minimal example.

Why did you specify Python 2.7.2, instead of the 2.7.6 version that is
being offered to me by Ubuntu Software Center?  Does it matter?

[toc] | [prev] | [next] | [standalone]

#16961

On 12/10/2011 11:53 AM, John Ladasky wrote:
> Why did you specify Python 2.7.2, instead of the 2.7.6 version that is
> being offered to me by Ubuntu Software Center?  Does it matter?
There is no Python 2.7.6. I think you have it confused with the version
2.7.2-6. If I'm not mistaken, that appended 6 has to do with packaging
and nothing at all to do with the software itself.

-- 
CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0

[toc] | [prev] | [next] | [standalone]

#16963

On Dec 10, 10:38 am, Andrew Berg <bahamutzero8...@gmail.com> wrote:
> On 12/10/2011 11:53 AM, John Ladasky wrote:> Why did you specify Python 2.7.2, instead of the 2.7.6 version that is
> > being offered to me by Ubuntu Software Center?  Does it matter?
>
> There is no Python 2.7.6. I think you have it confused with the version
> 2.7.2-6. If I'm not mistaken, that appended 6 has to do with packaging
> and nothing at all to do with the software itself.
>
> --
> CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0

How annoying, here's how Ubuntu Software Center described it:

"Version: 2.7-6 (python2.7)"

And here it is in the Synaptic Package Manager:

"package: python2.7-minimal, installed version: 2.7-6"

At first I considered that this truncated name might be the
consequence of a Linux bug.  But looking up and down my list of
installed software in both Ubuntu Software Center and Synaptic, I can
find version names which extend arbitrarily, such as my wxPython
installation, for which the version number reads
"2.8.11.0-0ubuntu4.1".

Now my hypothesis is that someone manually enters the revision numbers
into the Linux database, and they made a typo.

[toc] | [prev] | [next] | [standalone]

#16964

On Sun, Dec 11, 2011 at 5:38 AM, Andrew Berg <bahamutzero8825@gmail.com> wrote:
> On 12/10/2011 11:53 AM, John Ladasky wrote:
>> Why did you specify Python 2.7.2, instead of the 2.7.6 version that is
>> being offered to me by Ubuntu Software Center?  Does it matter?
> There is no Python 2.7.6. I think you have it confused with the version
> 2.7.2-6. If I'm not mistaken, that appended 6 has to do with packaging
> and nothing at all to do with the software itself.

On 12/9/2011 6:14 PM, John Ladasky wrote:
> I'm programming in Python 2.6 on Ubuntu Linux 10.10, if it matters.

As with my Ubuntu 10.10 - it's version 2.6.6. (I also altinstalled 3.3
built straight from Mercurial, which is approximately as new a Python
as one can have, but that doesn't count.)

There's a few differences between 2.6 and 2.7; not usually enough to
be concerned about in daily use, but when dealing with weird issues,
it helps to have the latest release.

ChrisA

[toc] | [prev] | [next] | [standalone]

#16971

On 12/10/2011 2:02 PM, Chris Angelico wrote:

> There's a few differences between 2.6 and 2.7; not usually enough to
> be concerned about in daily use, but when dealing with weird issues,
> it helps to have the latest release.

There are 2 issues. First, 2.7.2 has perhaps a couple hundred bug fixes 
since 2.7.0/2.6.6 were released. So it is possible that this particular 
problem was fixed, or at least changed. Second (leaving security issues 
aside), a Py2 bug fix will only be applied to the post-2.7.2 tip and 
only after the bug has been demonstrated to exist in the post-2.7.2 tip.

About the request for minimal code exhibiting the problem: each bug 
exposes a hole in the test suite. We try to add a new test case with 
each bug fix so fixed bugs stay fixed. So code examples not only show 
that the bug is in the latest version, but also serve as the basis for 
new tests.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web