On Tue, Jun 06, 2006 at 11:59:14PM +0100, David Given wrote:
> Damián Viano wrote:
> [...]
> > I'm writing you just to let you know that your bug-report didn't fall
> > into void. I'm currently looking into this, and will report back to you
> > and the bug when I have something more usefull.
>
> Excellent --- thanks!
>
> I've actually found a possibly related problem, which I haven't managed to
> isolate yet; what I appear to be seeing is that an exception thrown by (some
> C++ running in) one coroutine is ignoring the coroutine's own try{} block and
> being caught by the one in co_main instead. Needless to say, this is causing
> my app to go wrong. I have managed to get identical code behaving differently
> if compiled on either the i386 and ARM, but unfortunately this involves
> running the entire app, which isn't convenient. Does this ring any bells?
Yes, this is probably the same sort of error. Maybe you can reduce it
to a simpler test case?
> > By the moment I was able to reproduce the bug in an arm4 machine
> > through a friend, I hope i could get direct/semi-direct access this
> > machine soon so I could investigate firther.
I've been investigating this a while now and have some ideas/pointers
but no solution nor clear identification of the exact problem. I'll keep
digging.
Meanwhile I thought to drop you and the bug this note about my
findings.
It seems that arm lack support for {make,get,swap}context() calls so
an alternate way of creating the context for the threads is used. This
uses a very clever hack of sigaltstack an a little trickery with
setjmp/longmp to get a stack for the threads. The problem seems to be
that pthread uses the same trick, so there might possibly lay the problem.
However, forcing the alternative stack (by commenting
HAVE_{MAKE,GET,SWAP}CONTEXT in config.h) didn't allowed me to reproduce
the bug in i386. This may be because my guess is wrong, because pthread
uses {get,make,swap}context calls instead of this trick on i386 so there's
no clashing, or because there is something specific to arm that make
this use-case fail.
I'll keep looking because I'm still not fully convinced that, even
though both libraries used the same trick, this use should not work.
Btw, here I leave the backtrace of the proposed testcase:
Program received signal SIGSEGV, Segmentation fault.
0x4003fc08 in __pthread_sighandler () from /lib/libpthread.so.0
(gdb) bt
#0 0x4003fc08 in __pthread_sighandler () from /lib/libpthread.so.0
#1 <signal handler called>
#2 0x400ba968 in sigsuspend () from /lib/libc.so.6
#3 0x4001edf0 in co_set_context (ctx=0x11050, func=0x4001f14c,
stkbase=0x11150 "", stksiz=<value optimized out>) at pcl.c:281
#4 0x4001eea4 in co_create (func=0x8768 <switch_bench>, data=0x0,
stack=0x11050, size=<value optimized out>) at pcl.c:401
#5 0x00008820 in main (argc=1, argv=0xbec555f4) at cobench.c:70
Damián Viano(Des).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
