Registering thread fails...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



More info I got. I've tested the same assertion and this is my results all the time, even the first creation. It's almost always YES YES NO
printf("%s %p %s %p %s %p==%p\n", (thread->signature1 != 0xDEAFBEEF ? "YES" : "NO"), thread->signature1, (thread->signature2 != 0xDEADC0DE ? "YES" : "NO"), thread->signature2, (thread->thread == pthread_self() ? "YES" : "NO"), thread->thread, pthread_self());

Responses, first.
YES 0x0 YES 0x0 NO 0x0==0xb0227000

One after stoping and starting.
NO 0xdeafbeef NO 0xdeadc0de NO 0xb0227000==0xb02a9000

This bug is really weird and I have no idea why it's occurring, the hex does say dead code, but what does that mean? Do I have to destroy the threads after I'm done using them? I'll look more into this as I wait for help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100917/c610ed4c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4657 bytes
Desc: not available
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100917/c610ed4c/attachment-0001.p7s>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux