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.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
