[gccsdk] libapr

[Chris Gransden]

Peter Naulls wrote:
> Jan-Jaap van der Geer wrote:
>> Some time ago I updated the patches for subversion. Although it compiles
>> fine, it crashes when it is invoked.
>>
>> I've played a little bit with it, but have not found out what the
>> problem is. All crashes seem to be happening in libapr1. An example
>> here:
>>         
>
> There seems to be some memory problem with libapr. I've been running
> its test programs, and "testall" in particular with debugging on has
> problems:
>
> ...
> POOL DEBUG: [136173925]  PALLOC (     13472/     13472/     13540) 
> 0x7f7f8 "testutil.c:43" <strings/apr_strings.c:78> (92/92/0)
> POOL DEBUG: [136173925]  PALLOC (     17568/     17568/     17636) 
> 0x7f7f8 "testutil.c:43" <file_io/unix/open.c:180> (93/93/0) |POOL 
> DEBUG: [136173925] PCALLOC (     17636/     17636/     17704) 0x7f7f8 
> "testutil.c:43" <file_io/unix/open.c:169> (94/94/0)
> POOL DEBUG: [136173925]  PALLOC (     17656/     17656/     17724) 
> 0x7f7f8 "testutil.c:43" <strings/apr_strings.c:78> (95/95/0)
> POOL DEBUG: [136173925]  PALLOC (     17679/     17679/     17747) 
> 0x7f7f8 "testutil.c:43" <testfile.c:571> (96/96/0) |POOL DEBUG: 
> [136173925]    LIFE                                    0x80838 
> <memory/unix/apr_pools.c:apr_pool_integrity check>
>
> Fatal signal received: Aborted
>
> Stack backtrace:
>
> Running thread 0x75d30
>   (  376e34) pc:    4f640 lr:    4fc54 sp:   376e38  __write_backtrace()
>   (  376e9c) pc:    4f7f8 lr:    4ec94 sp:   376ea0 
> __unixlib_raise_signal()
>   (  376eac) pc:    4ec68 lr:    38ce4 sp:   376eb0  raise()
>   (  376ec0) pc:    38ca8 lr:    28de4 sp:   376ec4  abort()
>   (  376ee0) pc:    28c18 lr:    28e30 sp:   376ee4 
> apr_pool_cleanup_kill()
>   (  376ef8) pc:    28e1c lr:     e068 sp:   376efc  
> apr_pool_cleanup_run()
>   (  376f28) pc:     dfa4 lr:     f310 sp:   376f2c  
> ^file_contents_equal()
>   (  376f80) pc:     f270 lr:     95a8 sp:   376f84  ^test_writev()
>   (  376fac) pc:     94f4 lr:     d48c sp:   376fb0  abts_run_test()
>   (  376fc0) pc:     d31c lr:     8444 sp:   376fc4  testfile()
>   (  376ff4) pc:     8334 lr:    5d6e0 sp:   376ff8  main()
>
>
> This is a static binary, and I have turned off threading and other
> things which might be causing a problem.   This seems to be triggered
> by, or around the "writev" test in testall.
>
> Apart from that, in some of its other tests, John and I have seen
> instabilities in running shared library versions of some of the
> tests in a taskwindow, where other applications would be taken
> out with an abort - e.g, testshmconsumer.
>
> Also in the shared library library version of the 'testall' with debug
> off, it would first crash with a segmentation fault, and then
> a repeat run would give a much earlier crash with an illegal
> instruction - this is cleared by reloading the SOManager module.
> However, this might be a side effect of the memory problems seen
> in the first case above, but does suggest some unhelpful state
> stored by SOManager.
I noticed there had just been some changes to unixlib. I rebuilt 
everything and managed to check out netsurf without subversion crashing. :)

Chris.