On 27/02/11 19:49, Evgeny Burmentyev wrote:
On Sun, Feb 27, 2011 at 07:33:32PM +1000, Allan McRae wrote:
On 27/02/11 18:38, Emmanuel Benisty wrote:
On Sun, Feb 27, 2011 at 8:55 AM, Allan McRae<allan@xxxxxxxxxxxxx> wrote:
On 27/02/11 10:40, Allan McRae wrote:
Major upstream update.
Test well. There is no soname bump, but experience tells me that some
rebuilds will probably be required to fix minor issues.
just FTR, it breaks rtorrent.
eb64@drama:~$rtorrent
Caught Segmentation fault, dumping stack:
0 rtorrent() [0x439274]
1 rtorrent() [0x43d737]
2 /lib/libc.so.6(+0x326d0) [0x7f60f5e6e6d0]
3 rtorrent() [0x482f9e]
4 rtorrent() [0x439988]
5 /lib/libc.so.6(__libc_start_main+0xfd) [0x7f60f5e5adcd]
6 rtorrent() [0x40d959]
Aborted
simple rebuild doesn't seem to help, downgrading does.
Seems this is x86_64 only. I tried building a few things in its dependency
chain too but that did not help.
Added to the TODO list for the maintainer to look into.
Allan
No, it is not. It breaks rtorrent on i686 as well.
Hmmm... I do not get the segfault on i686. Anyway... rebuilding
without the --disable-debug flag and adding options=(!strip), I get:
Program received signal SIGSEGV, Segmentation fault.
__pop_heap<__gnu_cxx::__normal_iterator<rak::priority_item**,
std::vector<rak::priority_item*, std::allocator<rak::priority_item*> >
>, rak::priority_compare>
(this=0x32332f3020485b20)
at
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_heap.h:331
331 *__result = _GLIBCXX_MOVE(*__first);
(gdb) bt
#0 __pop_heap<__gnu_cxx::__normal_iterator<rak::priority_item**,
std::vector<rak::priority_item*, std::allocator<rak::priority_item*> >
>, rak::priority_compare> (this=0x32332f3020485b20)
at
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_heap.h:331
#1 pop_heap<__gnu_cxx::__normal_iterator<rak::priority_item**,
std::vector<rak::priority_item*, std::allocator<rak::priority_item*> >
>, rak::priority_compare> (this=0x32332f3020485b20)
at
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_heap.h:360
#2 pop (this=0x32332f3020485b20) at ../../rak/priority_queue.h:72
#3 priority_queue_perform (this=0x32332f3020485b20)
at ../../rak/priority_queue_default.h:92
#4 display::Manager::receive_update (this=0x32332f3020485b20)
at manager.cc:100
#5 0x000000000044a074 in operator() (argc=1, argv=0x7fffffffebf8)
at ../rak/functional_fun.h:102
#6 call (argc=1, argv=0x7fffffffebf8) at ../rak/priority_queue_default.h:62
#7 priority_queue_perform (argc=1, argv=0x7fffffffebf8)
at ../rak/priority_queue_default.h:95
#8 main (argc=1, argv=0x7fffffffebf8) at main.cc:301
which looks nothing to do with ncurses...
