Bob Rossi wrote:
> On Tue, Dec 05, 2006 at 03:35:21PM -0600, William A. Rowe, Jr. wrote:
>> Bob Rossi wrote:
>>> Hi,
>>>
>>> Well, here is the compile command.
>>>
>>> /bin/sh
>>>
/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/libtool
>>> --silent --mode=compile gcc -mno-cygwin -g -O0 -DHAVE_CONFIG_H
>>> -D_LARGEFILE64_SOURCE -I./include
>>>
-I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include/arch/win32
>>> -I./include/arch/unix
>>>
-I/home/bobbybrasko/rcs/svn/vigilant/vigilant/builddir/vigilant-tools/apr/include
>>> -o dso/win32/dso.lo -c dso/win32/dso.c && touch dso/win32/dso.lo
>>>
>>> And yes, #define APR_HAS_DSO 1
>> Beauty. If you can share the backtrace (you said it crashed, no?) this
>> too might be helpful.
>
> It raised an assertion.
>
> Assertion failed: rv == APR_SUCCESS, file testmutexscope.c, line 168
> This application has requested the Runtime to terminate it in an
unusual way.
> Please contact the application's support team for more information.
>
> Would you still like a backtrace? Can one typically get that for apr
> using GDB using the standard techniques? ie. (r, bt)
>
> Thanks,
> Bob Rossi
This is what i sent to the list on the past regarding this error when
building under mingw from trunk.
...
I've just been working on getting the mingw build of apr up and running
(based on [EMAIL PROTECTED]), it all seems to go well and i get the compiled
libraries as expected.
However when it comes to testing i notice that there are problems such
that the testmutexscope.exe fails. The output is as follows.
<quote>
Trying proc mutexes with mechanism `default'...
Mutex mechanism `default' is global in scope on this platform.
Assertion failed: rv == APR_SUCCESS, file testmutexscope.c, line 169
This application has requested the Runtime to terminate it in an unusual
way. Please contact the application's support team for more information.
</quote>
Basically what appears to be happening in that the apr_thread_join
returns APR_INCOMPLETE, this is correct as per the apr_thread_join
source code as the thread's pool is still intact (apr_thread_exit was
not called for thread cleanup). However the thread itself has exited, or
more rather then threads main function has returned.
My question comes down to the usage of apr_thread_exit(...), should all
threads prior to returning call this function, and if it does not then
is it considered a usage error? I would be inclined to change the dummy
thread function such that if the threads function registered via
apr_thread_create does return then apr_thread_exit(...) is called,
however this is more a fail safe for perhaps incorrect usage?
I myself did try to assertain whether apr_thread_exit() was infact
required to be called, however i failed and looking at the test examples
they generally do not.
Andrew
