[Quantlib-dev] Re: Bug#286995: quantlib-python: FTBFS: buildd stopped because of inactivity.

[Dirk E. <ed...@de...>]

On Thu, Dec 23, 2004 at 02:52:53PM +0100, Kurt Roeckx wrote:
> Package: quantlib-python
> Version: 0.3.8-1
> Severity: serious
> 
> Hi,
> 
> The package is failing to build on a few arches (sparc, amd64 so
> far) because it seems to hang when making tests.

Ok, thanks. This time I only commented out TermStructureTest from the actual
Python script as that one hangs on i386.  SoO maybe I'll revert to what I
did up to 0.3.7 -- comment out InstrumentTest as well.  The buildd page
(i.e. http://buildd.debian.org/build.php?pkg=quantlib-python) shows that
0.3.7 built fine everywhere...

Also CCing upstream as a heads up.

Dirk

> >From the buildd log:
> python2.3 setup.py test
> running test
> running build
> running build_py
> running build_ext
> testing QuantLib 0.3.8
> Testing date arithmetics ... ok
> Testing observability of stocks ... make: *** [test-stamp] Terminated
> Build killed with signal 15 after 150 minutes of inactivity
> 
> python2.3 is using all available cpu during that time.
> 
> It seems to be stuck doing this:
> futex(0x73b4d8, FUTEX_WAIT, 2, NULL)    = -1 EAGAIN (Resource temporarily unavailable)
> futex(0x73b4d8, FUTEX_WAIT, 2, NULL)    = -1 EAGAIN (Resource temporarily unavailable)
> 
> Attached gdb doesn't seem to be very helpful.  A backtrace looks
> like this:
> #0  0x0000002a95782744 in __lll_mutex_lock_wait () from
> /lib/libpthread.so.0
> #1  0x000000000073b4d8 in ?? ()
> #2  0x000000000080c200 in ?? ()
> #3  0x0000002a9577f971 in pthread_mutex_lock () from
> /lib/libpthread.so.0
> #4  0x00000000005d2ae0 in PyDictIter_Type ()
> #5  0x0000002a96d72c90 in ?? ()
> #6  0x0000000000000000 in ?? ()
> #7  0x000000000041ca24 in PyMethod_Fini ()
> #8  0x0000002a96dde980 in ?? ()
> #9  0x0000002a96dde9d0 in ?? ()
> #10 0x00000000006142d0 in ?? ()
> #11 0x0000000000000000 in ?? ()
> #12 0x000000000069f7c0 in ?? ()
> #13 0x000000000069f7a8 in ?? ()
> #14 0x0000000000000000 in ?? ()
> #15 0x0000002a96d72c90 in ?? ()
> #16 0x0000000000000000 in ?? ()
> #17 0x0000000000000000 in ?? ()
> ...
> #95 0x000000000048e208 in PyRun_SimpleFileExFlags ()
> #96 0x000000000040fd7a in Py_Main ()
> #97 0x0000002a95c363c1 in __libc_start_main () from /lib/libc.so.6
> #98 0x000000000040f7ea in _start ()
> #99 0x0000007fbffffb48 in ?? ()
> #100 0x0000000000000000 in ?? ()
> [...]
> #249 0x00332e326e6f6874 in ?? ()
> #250 0x0000000000000000 in ?? ()
> Cannot access memory at address 0x7fc0000000
> 
> 
> 
> Kurt
> 

-- 
If you don't go with R now, you will someday.
  -- David Kane on r-sig-finance, 30 Nov 2004