apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Teirney <and...@teirney.net>
Subject Re: building apr on cygwin for mingw
Date Wed, 06 Dec 2006 01:34:38 GMT
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 trunk@r464899), 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



Mime
View raw message