libgfortran3 respin : status and problem

libgfortran3 respin : status and problem

[marco atzeri]

Hi,
I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.

( If you wan to try them, install with
setup.exe -X  -O -s http://matzeri.altervista.org )

lapack tests passed
netcdf also (i am not 100% sure)

but testing qrupdate I catched another problem.
The test programs go in a never ending loop:

 37   15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
tty output_mutex: waiting -1 ms
 31   15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
tty output_mutex: acquired
 33   15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
tty output_mutex released

One of the test program and strace on
http://matzeri.altervista.org/works/qrupdate/

Also testing octave I see a similar problem; as I doubt it is a
problem of qrupdate or octave,
I guess it is more a problem of fortran or cygwin.

I also test the 2011-03-23 cygwin dll instead of 1.7.8 one, but the
same problem is there.

Could someone give a check ?

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[Corinna Vinschen]

On Mar 26 06:56, marco atzeri wrote:
> Hi,
> I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.
> 
> ( If you wan to try them, install with
> setup.exe -X  -O -s http://matzeri.altervista.org )
> 
> lapack tests passed
> netcdf also (i am not 100% sure)
> 
> but testing qrupdate I catched another problem.
> The test programs go in a never ending loop:
> 
>  37   15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
> tty output_mutex: waiting -1 ms
>  31   15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
> tty output_mutex: acquired
>  33   15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
> tty output_mutex released

That's not an endless loop as far as Cygwin is concerned.  When a
process writes to the console, then every write is atomic.  To accomplish
that, a mutex is used, like this:

  write()
  {
    acquire mutex
    while (there's still something to write)
      write it
    release mutex
  }

So, what you see is a supposedly endless stream of calls to the write
function.  Usually, if an error occurs, you would also see an error
message.  The only reason you don't see it is if an error already
occured in an earlier call to write.  The important would be prior to
the endless loop then.  Maybe the testcase doesn't check for errors?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[marco atzeri]

On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen  wrote:
> On Mar 26 06:56, marco atzeri wrote:
>> Hi,
>> I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.
>>
>> ( If you wan to try them, install with
>> setup.exe -X  -O -s http://matzeri.altervista.org )
>>
>> lapack tests passed
>> netcdf also (i am not 100% sure)
>>
>> but testing qrupdate I catched another problem.
>> The test programs go in a never ending loop:
>>
>>  37   15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
>> tty output_mutex: waiting -1 ms
>>  31   15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
>> tty output_mutex: acquired
>>  33   15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
>> tty output_mutex released
>
> That's not an endless loop as far as Cygwin is concerned.  When a
> process writes to the console, then every write is atomic.  To accomplish
> that, a mutex is used, like this:
>
>  write()
>  {
>    acquire mutex
>    while (there's still something to write)
>      write it
>    release mutex
>  }
>
> So, what you see is a supposedly endless stream of calls to the write
> function.  Usually, if an error occurs, you would also see an error
> message.  The only reason you don't see it is if an error already
> occured in an earlier call to write.  The important would be prior to
> the endless loop then.  Maybe the testcase doesn't check for errors?
>
>
> Corinna

the test case is a normal Fortran program that call numerical functions and
print output with a really standard "write" command, nothing fancy.
It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7

---------------------------------------------------------
      write (*,*)
      write (*,*) 'testing Cholesky rank-1 downdate routines.'
      write (*,*) 'All residual errors are expected to be small.'
      write (*,*)

      n = 50
      write (*,*) 'sch1dn test:'
      call stest(n)
      write (*,*) 'dch1dn test:'
      call dtest(n)
      write (*,*) 'cch1dn test:'
      call ctest(n)
      write (*,*) 'zch1dn test:'
      call ztest(n)
-------------------------------------------------------------
     subroutine smdump(name,m,n,A,lda)
      character(*) name
      integer m,n,lda
      real A(lda,n)
      integer i,j
      write (*,1001) name
      do i = 1,m
        do j = 1,n
          write(*,1002) A(i,j)
        end do
        write(*,*)
      end do
------------------------------------------------------------------

The full source is here, and it is a very tiny lib
http://matzeri.altervista.org/cygwin-1.7/qrupdate/

May be a mutex problem in Fortran lib ?
We already had long time ago.... a "WRITE" problem

http://cygwin.com/ml/cygwin/2009-03/msg00428.html

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[Jerry DeLisle]

On 03/26/2011 03:33 AM, marco atzeri wrote:
> On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen  wrote:
>> On Mar 26 06:56, marco atzeri wrote:
>>> Hi,
>>> I rebuilt lapack, qrupdate, octave and netcdf with the libgfortran3-4.3.4-4.
>>>
>>> ( If you wan to try them, install with
>>> setup.exe -X  -O -s http://matzeri.altervista.org )
>>>
>>> lapack tests passed
>>> netcdf also (i am not 100% sure)
>>>
>>> but testing qrupdate I catched another problem.
>>> The test programs go in a never ending loop:
>>>
>>>   37   15579 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
>>> tty output_mutex: waiting -1 ms
>>>   31   15610 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (746):
>>> tty output_mutex: acquired
>>>   33   15643 [main] tch1dn_sym 4300 fhandler_tty_slave::write: (789):
>>> tty output_mutex released
>>
>> That's not an endless loop as far as Cygwin is concerned.  When a
>> process writes to the console, then every write is atomic.  To accomplish
>> that, a mutex is used, like this:
>>
>>   write()
>>   {
>>     acquire mutex
>>     while (there's still something to write)
>>       write it
>>     release mutex
>>   }
>>
>> So, what you see is a supposedly endless stream of calls to the write
>> function.  Usually, if an error occurs, you would also see an error
>> message.  The only reason you don't see it is if an error already
>> occured in an earlier call to write.  The important would be prior to
>> the endless loop then.  Maybe the testcase doesn't check for errors?
>>
>>
>> Corinna
>
> the test case is a normal Fortran program that call numerical functions and
> print output with a really standard "write" command, nothing fancy.
> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7
>
> ---------------------------------------------------------
>        write (*,*)
>        write (*,*) 'testing Cholesky rank-1 downdate routines.'
>        write (*,*) 'All residual errors are expected to be small.'
>        write (*,*)
>
>        n = 50
>        write (*,*) 'sch1dn test:'
>        call stest(n)
>        write (*,*) 'dch1dn test:'
>        call dtest(n)
>        write (*,*) 'cch1dn test:'
>        call ctest(n)
>        write (*,*) 'zch1dn test:'
>        call ztest(n)
> -------------------------------------------------------------
>       subroutine smdump(name,m,n,A,lda)
>        character(*) name
>        integer m,n,lda
>        real A(lda,n)
>        integer i,j
>        write (*,1001) name
>        do i = 1,m
>          do j = 1,n
>            write(*,1002) A(i,j)
>          end do
>          write(*,*)
>        end do
> ------------------------------------------------------------------
>

I have been monitoring this thread for the libgfortran maintainer side, but have 
not had time yet to investigate further.  The only platform reporting the issue 
so far is Cygwin. I am not aware of any changes occurring with 4.3 upstream of 
Cygwin, but I will check the logs.

Jerry

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[Jerry DeLisle]

On 03/26/2011 08:35 AM, Jerry DeLisle wrote:

>
> I have been monitoring this thread for the libgfortran maintainer side, but have
> not had time yet to investigate further. The only platform reporting the issue
> so far is Cygwin. I am not aware of any changes occurring with 4.3 upstream of
> Cygwin, but I will check the logs.
>

The latest upstream change in libgfortran was May of 2010.  That points to 
downstream tweaks or not related to libgfortran itself.

Jerry

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[Corinna Vinschen]

On Mar 26 11:33, marco atzeri wrote:
> On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen  wrote:
> > So, what you see is a supposedly endless stream of calls to the write
> > function.  Usually, if an error occurs, you would also see an error
> > message.  The only reason you don't see it is if an error already
> > occured in an earlier call to write.  The important would be prior to
> > the endless loop then.  Maybe the testcase doesn't check for errors?
> 
> the test case is a normal Fortran program that call numerical functions and
> print output with a really standard "write" command, nothing fancy.
> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7

What about current libgfortran3 and cygwin 1.7.7?  What about previous
libgfortran3 and cygwin 1.7.8?

> The full source is here, and it is a very tiny lib
> http://matzeri.altervista.org/cygwin-1.7/qrupdate/

Yes, well, are you going to debug this problem?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[marco atzeri]

On Sat, Mar 26, 2011 at 5:05 PM, Corinna Vinschen  wrote:
> On Mar 26 11:33, marco atzeri wrote:
>> On Sat, Mar 26, 2011 at 10:45 AM, Corinna Vinschen  wrote:
>> > So, what you see is a supposedly endless stream of calls to the write
>> > function.  Usually, if an error occurs, you would also see an error
>> > message.  The only reason you don't see it is if an error already
>> > occured in an earlier call to write.  The important would be prior to
>> > the endless loop then.  Maybe the testcase doesn't check for errors?
>>
>> the test case is a normal Fortran program that call numerical functions and
>> print output with a really standard "write" command, nothing fancy.
>> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7
>
> What about current libgfortran3 and cygwin 1.7.7?  What about previous
> libgfortran3 and cygwin 1.7.8?

I will make all the test as soon I built a simpler test case involving
only libgfortran3 and cygwin .
Currently qrupdate require lapack and lapack 3.2.2-1 was broken by the
libgfortran3 update.

Today I have
cygwin-1.7.7 , libgfortran3-4.3.4-3, lapack-3.2.2-1,
qrupdate-qrupdate-1.1.0-1 fine
cygwin-1.7.8 , libgfortran3-4.3.4-4, lapack-3.2.2-2,
qrupdate-qrupdate-1.1.1-1 broken (as also octave3.4.0-3)

>> The full source is here, and it is a very tiny lib
>> http://matzeri.altervista.org/cygwin-1.7/qrupdate/
>
> Yes, well, are you going to debug this problem?

yes but very slowly, my real job take me real busy and I have little spare time.

> Corinna
>

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[Jerry DeLisle]

On 03/26/2011 11:18 AM, marco atzeri wrote:
--- snip ---
> Today I have
> cygwin-1.7.7 , libgfortran3-4.3.4-3, lapack-3.2.2-1,
> qrupdate-qrupdate-1.1.0-1 fine
> cygwin-1.7.8 , libgfortran3-4.3.4-4, lapack-3.2.2-2,
> qrupdate-qrupdate-1.1.1-1 broken (as also octave3.4.0-3)
>
>>> The full source is here, and it is a very tiny lib
>>> http://matzeri.altervista.org/cygwin-1.7/qrupdate/
>>
>> Yes, well, are you going to debug this problem?
>
> yes but very slowly, my real job take me real busy and I have little spare time.
>
I just got cygwin-1.7.8 loaded.  I am going to see if I can then build 
gcc/gfortran, and go from there.

Marco, please continue your efforts to a reduced example.

Jerry

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[Yaakov (Cygwin/X)]

On Sat, 2011-03-26 at 11:33 +0100, marco atzeri wrote:
> the test case is a normal Fortran program that call numerical functions and
> print output with a really standard "write" command, nothing fancy.
> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7

FWIW, qrupdate's test suite WJFFM with DLL from recent CVS (2011-03-20)
and Ports' gcc 4.5.2-2 (which was also rebuilt for 1.7.8).


Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[marco atzeri]

On Sun, Mar 27, 2011 at 6:34 AM, Yaakov (Cygwin/X)  wrote:
> On Sat, 2011-03-26 at 11:33 +0100, marco atzeri wrote:
>> the test case is a normal Fortran program that call numerical functions and
>> print output with a really standard "write" command, nothing fancy.
>> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7
>
> FWIW, qrupdate's test suite WJFFM with DLL from recent CVS (2011-03-20)
> and Ports' gcc 4.5.2-2 (which was also rebuilt for 1.7.8).
>
>
> Yaakov
>
>

which lapack ? 3.2.2-1 of distro ?


Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[Yaakov (Cygwin/X)]

On Sun, 2011-03-27 at 07:43 +0200, marco atzeri wrote:
> which lapack ? 3.2.2-1 of distro ?

3.2.2 rebuilt with cygwin 1.7.8 and Ports' gcc 4.5.2-2.


Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[marco atzeri]

On Sun, Mar 27, 2011 at 6:34 AM, Yaakov (Cygwin/X)  wrote:
> On Sat, 2011-03-26 at 11:33 +0100, marco atzeri wrote:
>> the test case is a normal Fortran program that call numerical functions and
>> print output with a really standard "write" command, nothing fancy.
>> It used to work fine with previous libgfortran3-4.3.4-3 and cygwin-1.7.7
>
> FWIW, qrupdate's test suite WJFFM with DLL from recent CVS (2011-03-20)
> and Ports' gcc 4.5.2-2 (which was also rebuilt for 1.7.8).
>
>
> Yaakov
>
>

which lapack ? 3.2.2-1 of distro ?


Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[marco atzeri]

On Sun, Mar 27, 2011 at 10:15 AM, Yaakov (Cygwin/X) wrote:
> On Sun, 2011-03-27 at 07:43 +0200, marco atzeri wrote:
>> which lapack ? 3.2.2-1 of distro ?
>
> 3.2.2 rebuilt with cygwin 1.7.8 and Ports' gcc 4.5.2-2.
>
>
> Yaakov
>

Thanks,
I start to think that there is a problem in lapack-3.2.2.-2 built with
gcc-4.3.4-4.

It looks that slartg never returns; I need to further dig.

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: libgfortran3 respin : status and problem

[marco atzeri]

On Sun, Mar 27, 2011 at 1:43 PM, marco atzeri  wrote:
> On Sun, Mar 27, 2011 at 10:15 AM, Yaakov (Cygwin/X) wrote:
>> On Sun, 2011-03-27 at 07:43 +0200, marco atzeri wrote:
>>> which lapack ? 3.2.2-1 of distro ?
>>
>> 3.2.2 rebuilt with cygwin 1.7.8 and Ports' gcc 4.5.2-2.
>>
>>
>> Yaakov
>>
>
> Thanks,
> I start to think that there is a problem in lapack-3.2.2.-2 built with
> gcc-4.3.4-4.
>
> It looks that slartg never returns; I need to further dig.
>
> Marco

I guess I catched.
There is likely an optimization bomb that never exploded before during
lapack building.
For what ever reason  gcc-4.3.4-4 activates it and all the previous version not.

slamch.f and dlamch.f could fall in never ending loop if the
optimization is active.
The funny thing is that they were created in such a way to fool
optimization to recover hardware real data.

So at the end it is a PEBCAK problem from the first time that I
adopted lapack and used automake/autoconf.

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple