matplotlib-devel Mailing List for matplotlib

On Dec 5, 2004, at 9:10 PM, Andrew Straw wrote:

>
> On Dec 5, 2004, at 9:04 AM, Jochen Voss wrote:
>
>> Hello everybody,
>>
>> On Wed, Dec 01, 2004 at 06:38:47PM -0800, Andrew Straw wrote:
>>> It sounds like you may have hit a nasty glibc bug that caused me much
>>> head scratching over the months.  Check this thread:
>>>
>>> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/ 
>>> 2207861
>>>
>>> Bottom line:
>>>
>>> numarray does The Right Thing and attempts to set up floating point
>>> exception handling, but older versions of glibc (such as that in  
>>> Debian
>>> sarge) have a bug whereby the floating point error bits in the SSE  
>>> are
>>> not  properly cleared, leading to a SIGFPE terminating the program  
>>> the
>>> next time the SSE unit is used.
>> Yes, this was the problem.  I applied the patch from
>>
>
I really appreciate Andrew's diagnosing the original problem and  
particularly in recognizing it as possibility here. This is a nasty  
kind of bug to figure out.

>> By the way: I am still interested in my original question.  How would
>> I use a debugger etc. to find the problem myself in such a situation?
>
> If you find out, let me know!  Seriously, having a process killed by  
> the kernel

Us too!

Perry

Hello Andrew,

On Mon, Dec 06, 2004 at 06:42:03PM +0000, Jochen Voss wrote:
> I will try to add more information to the bug report log.
> Maybe this helps the patch being applied.
It turns out that I do not understand enough of this to
produce an illustrative example.  Do you have a minimal
C program which terminates with SIGFPE because of this bug
where it shouldn't?

All the best,
Jochen
--=20
http://seehuhn.de/

Hello Andrew,

On Sun, Dec 05, 2004 at 06:10:47PM -0800, Andrew Straw wrote:
> I have to admit that I'm a little disappointed in the speed of this=20
> bugfix going into the Debian sources.  I'd think that since I submitted=
=20
> a 2 line (1 of which was comments) patch over a month ago, which was=20
> copied directly from upstream, this would be about 2 minutes of work=20
> for someone...
Yes, this can be a pain.  I think the first thing to do
is to add more information to the bug report log.  I guess
the the Debian libc-maintainers are short of time and have
problems to easily see whether the bug is actually a bug and the
fix is actually a fix.

I will try to add more information to the bug report log.
Maybe this helps the patch being applied.

All the best,
Jochen
--=20
http://seehuhn.de/

> By the way: I am still interested in my original question.  How would
> I use a debugger etc. to find the problem myself in such a situation?

I should know the answer because I created the glibc patch that fixes
the problem, but it was back in February and I can't remember all the
details.
It started when I thought, why should I run my AthlonXP in '386 emulator
mode' when I can use 'gcc -march=athlon-xp' and actually benefit from
the extra instructions my processor supports. This worked fine until I
compiled numarray and it failed its own tests with a floating-point
exception. But if I used the default gcc settings it worked OK. I filed
a numarray bug report (which I can no longer locate, perhaps they get
deleted after a certain date), they looked at it and said it was
probably a gcc bug. I filed a gcc bug report, and they closed it saying
it was not a gcc bug.
Then I thought it might be a bug with the way kernel handles FP
exceptions and started looking through the kernel sources, but did not
make much progress. So I went back to the numarray source code and tried
no narrow down where the problem was occurring.

Now to answer your question:
Consider you are on a TV game show where you have to guess a number x in
the range 1 to y and are told 'higher', 'lower' or 'correct' after each
turn.  You can use a binary search and always guess the mid point of the
range - you are either correct or eliminate half of the possibilities
each turn, so in ceil log(y, 2) turns or less you locate the correct
number.

You can use a similar kind of binary search to locate bugs in software.
You know the bug occurs on some line x of the source code with y lines.
Use gdb and insert breakpoints in the code (I think I just inserted
printf() statements instead of using gdb) and see if the error occurs
before or after the breakpoint, move the breakpoint and try again. The
problem is that source code is rarely a linear list of statements in one
file that are executed in order, but a set of procedures/functions in
many files where the execution order can vary. You can start at the main
() function, split it in half and insert a breakpoint (or printf()) run
it and see in which half the error occurs, repeat the process working
your way down into other functions until you pinpoint the error.

Hope that makes sense. You could now reinstall the old glibc, forget
that you know that glibc is the problem and start again to locate the
bug, it will be useful practise for the next bug that comes along!

Steve

On Dec 5, 2004, at 9:04 AM, Jochen Voss wrote:

> Hello everybody,
>
> On Wed, Dec 01, 2004 at 06:38:47PM -0800, Andrew Straw wrote:
>> It sounds like you may have hit a nasty glibc bug that caused me much
>> head scratching over the months.  Check this thread:
>>
>> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2207861
>>
>> Bottom line:
>>
>> numarray does The Right Thing and attempts to set up floating point
>> exception handling, but older versions of glibc (such as that in 
>> Debian
>> sarge) have a bug whereby the floating point error bits in the SSE are
>> not  properly cleared, leading to a SIGFPE terminating the program the
>> next time the SSE unit is used.
> Yes, this was the problem.  I applied the patch from
>
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279294
>
> and the problem disappeared.  Does this imply that on current
> Debian/unstable systems matplotlib can only be used with
> python-numeric and not with python-numarray?

You can remove atlas3-sse2 (and perhaps atlas3-sse), and it should run 
OK.  Sorry I didn't remember this earlier.

I have to admit that I'm a little disappointed in the speed of this 
bugfix going into the Debian sources.  I'd think that since I submitted 
a 2 line (1 of which was comments) patch over a month ago, which was 
copied directly from upstream, this would be about 2 minutes of work 
for someone...  Maybe I should have put it at a higher priority than 
"Normal".

> By the way: I am still interested in my original question.  How would
> I use a debugger etc. to find the problem myself in such a situation?

If you find out, let me know!  Seriously, having a process killed by 
the kernel because of a signal was difficult for me to debug. (Python 
is supposed to insulate you from this kind of low-level stuff and 
generally does a fantastic job.) I had no idea where the FPE signal was 
coming from or why. I first came across this in the context of a 
numarray/Intel IPP program.  Because  IPP is closed source, I didn't go 
very far initially, and just converted my program to Numeric. Then, I 
encountered the same thing purely within numarray and knew it was 
within my grasp.  By making a minimal program that exhibited the bug, I 
determined that the floating point error checking and setting code 
executed on import of numarray.ieeespecial would cause a floating point 
error (SIGFPE) in later matrix calls (e.g. 
numarray.linear_algebra.singular_value_decomposition).  I began to 
suspect the SSE unit because this code ran fine when I compiled 
numarray with its built-in lapack_lite.

Strangely, running python from within gdb did not terminate or indicate 
that a SIGFPE was raised.  This I'd like to understand a bit better...

Cheers!
Andrew