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 0x8820 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]
