[gccsdk] libapr (was: Subversion)

Peter Naulls peter at chocky.org
Wed Dec 30 12:45:32 PST 2009


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.









More information about the gcc mailing list