A wild guess: is boost/detail/atomic_count.hpp correctly implemented
for this compiler/processor combination? Maybe try to force to use
pthreads for locking?
BR,
Wim.
2011/8/15 Tom <tom.robin...@miranda.com>:
> Hi Koen,
>
> First of all, I have to say I really do appreciate this response, it's
> given us some interesting things to think about.
> We have tryed a lot more things today, unfortunatlely it's not working
> still.
>
> > It's hanging in spirit. Spirit is one of those libraries in boost
> > which need an explicit compile flag to be used safely in
> > multi-threaded builds (-DBOOST_SPIRIT_THREADSAFE)
>
> > You could start with checking that this flag is indeed being used
> > while building Wt ?
>
> > We did discover this when we built for an ARM target and got also a
> > hang in the first call to spirit code.
>
> This is interesting as it sounds like a very similar problem, and it
> really sounded like this could be the sort of thing that will fix
>
> it.
> We checked a few things in this domain:
> * We checked our Wt build.
> We are cross-compiling it with a cmake toolchain file.
> I am now explicitly setting this define although the cmake output
> shows the following:
> -- Looking for include files CMAKE_HAVE_PTHREAD_H
> -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> ** Enabling multi threading.
>
> For it to output that last line, the CMakeLists file sets
> -DBOOST_SPIRIT_THREADSAFE on the very next line.
>
> * We checked our boost build.
> We added this define to the boost build itself - incase it was
> building any precompiled headers, found later it isn't though.
> Boost is compiled with threading=multi also.
>
> * We checked the build of our app.
> We didn't have this define in the build of our app so we added it. We
> also added -D_REENTRANT as that was being used in the Wt
>
> CMakeLists file also.
>
> The problem is bound to be in our building of either Wt, boost, our app
> or the compiler itself.
>
> >> Heres the problem:
> >>
> >> It doesn't seem to us like this is really the issue here.
> >> It seems more like this has just moved the problem around, and that the
> >> problem was probably there with the old compiler also.
> >> Note that with either version, once the web browser connects, the Wt app
> >> can no longer be Ctrl-C, it just says stopping sessions and never does,
> >> needs to be Ctrl-Z and killed.
>
> > So, do I get this correctly: in any build so far, you've never been
> > able to Ctrl-C a Wt application to exit cleanly ?
>
> We can Ctrl-C a Wt app built with our previous toolchain - IE. gcc 4.3.4.
> The gcc 4.3.4 toolchain builds work 100% when run.
> It's just that as the new 4.4.4 toolchain builds work after adding
> -fno-inline
> that makes it seem like maybe we were doing something wrong with the old
> toolchain also, but we just got away with it.
>
> >> So I guess the question is now, has anyone ever seen a problem with
> >> Ctrl-C a Wt app, probably using WServer in particular.
>
> > Actually, even if you use WRun() this creates and manipulates a
> > WServer instance. This probably doesn't matter ?
>
> Interesting. I've just tried the hello.C example app that comes with Wt and
> it goes wrong in the exact same way. IE. web browsers can't connect and once
> a web browser attempts a connect, it can no longer be Ctrl-C.
> This is nice as it makes testing a lot simpler. We are building hello.C with
> the following script for simplicity now (included just so you can see what
> we are linking with and the cflags given):
>
> #!/bin/bash
>
> COMP="$CXX"
> IFLAGS="$TOOLCHAIN_CXXFLAGS $DISTRO_CXXFLAGS"
> LFLAGS="$TOOLCHAIN_LDFLAGS $DISTRO_LDFLAGS"
> SOURCE_FILES="hello.C"
> OUT_FILE="wttest"
>
> LIBS="-lgcc -lgcc_eh -lc -lstdc++"
> WTLIBS="-lwt -lwthttp"
> BOOSTLIBS="-lboost_thread -lboost_regex -lboost_signals -lboost_system
> -lboost_date_time -lboost_filesystem -lboost_program_options"
> MISCLIBS="-lz"
> MISC_OPTS="-ggdb -DDEBUG -D_REENTRANT -DBOOST_SPIRIT_THREADSAFE"
>
> ${COMP} ${IFLAGS} ${LFLAGS} ${LIBS} ${WTLIBS} ${BOOSTLIBS} ${MISCLIBS}
> ${MISC_OPTS} -o ${OUT_FILE} ${SOURCE_FILES}
>
>
> Also we are using eglibc as opposed to glibc, incase there is an issue
> there.
>
>
> > This is the stacktrace which hangs within expireSessions() ?
>
> > This stacktrace indicates that expireSessions is waiting to get a
> > session lock. That would be the case if one session is still actively
> > handling a request, or, there is a problem with an update lock.
>
> > In either case, it would be informative to get stacktraces of all
> threads ?
>
> > We've recently identified one problem in expireSessions(), which was
> > patched on July 25th in git trunk as part of patch
> > 45555e5fe1549e80018401b4d2fd3c2ee9ddf125 (those hunks that touch
> > WebSession.C). But this should not explain why it consistently hangs
> > though.
>
> The trace is from running under gdb, hitting ctrl-c (which causes the hang)
> then ctrl-z to get back to gdbs prompt, then running thread apply all bt.
>
> here is a link to the full backtrace for hello.C for all threads after a
> Ctrl-C,
> I have annotated it with notes when the browser is pointed at the server
> and when Ctrl-C is pressed:
> http://pastebin.com/B7MmbTHc
>
> I'm not sure whether the Ctrl-C hang is a symptom of the other issue, our
> main concern is the web-browser not being able to retreive data from the
> server (before ctrl-c is tried). I've tried a backtrace of this also, not
> sure if it will be useful but I've just done a backtrace right after
> pointing
> the browser at the server, here it is:
> http://pastebin.com/BMhAb6a6
>
>
> >> Also, Does anyone know of any issues with the way Wt uses boost_thread
> >> that might not be 100% "correct"
>
> > I'ld be interested in knowing that too ;-), but, so far, it does
> > behave correctly on different targets (ARM, linux i386, i686 and
> > windows). And what we do is fairly standard boost::asio code.
>
> Yep it does seem like maybe it's more the way something is being built
> than the Wt code itself now.
>
> Thanks again for all your help Koen,
>
> Regards,
> Tom
>
> ____________________________
>
> Miranda Technologies Limited
> Registered in England and Wales CN 02017053
> Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7
> 1FJ
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
