[arch-general] [arch-dev-public] [signoff] ncurses-5.8-1

[Allan McRae]

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 at archlinux.org>   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 at 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...