search for: pthread_self

Hi, I would like to propose a potential solution to a bug that involves coroutine and pthread_self(). Description of the bug can be found in https://bugs.llvm.org/show_bug.cgi?id=47833. Below is a summary: pthread_self() from glibc is defined with "__attribute__ ((__const__))". The const attribute tells the compiler that it does not read nor write any global state and hence always ret...

...0644 --- a/tools/virtio/ringtest/main.c +++ b/tools/virtio/ringtest/main.c @@ -87,7 +87,7 @@ void set_affinity(const char *arg) cpu = strtol(arg, &endptr, 0); assert(!*endptr); - assert(cpu >= 0 || cpu < CPU_SETSIZE); + assert(cpu >= 0 && cpu < CPU_SETSIZE); self = pthread_self(); CPU_ZERO(&cpuset);

...0644 --- a/tools/virtio/ringtest/main.c +++ b/tools/virtio/ringtest/main.c @@ -87,7 +87,7 @@ void set_affinity(const char *arg) cpu = strtol(arg, &endptr, 0); assert(!*endptr); - assert(cpu >= 0 || cpu < CPU_SETSIZE); + assert(cpu >= 0 && cpu < CPU_SETSIZE); self = pthread_self(); CPU_ZERO(&cpuset);

...0c <+276>:    ldr    r0, [sp, #36]    ; 0x24    0x00008f10 <+280>:    add    r0, r0, #1    0x00008f14 <+284>:    dmb    ish    0x00008f18 <+288>:    ldr    r1, [sp, #40]    ; 0x28    0x00008f1c <+292>:    strb    r0, [r1]    0x00008f20 <+296>:    bl    0x8aa0 <pthread_self> > > In what way is "count" corrupted, and how do you observe it? What > assembly is actually produced for the block? The assembly for whole block is huge even for minimal test case. I attached source code. I used cocotron derived framework, but due canaries was alive I don...

...all_id)) printf("succ to deRegister, conn:%p, call id:%d\n", conn, arg->call_id); else printf("fail to deRegister, conn:%p, call id:%d\n", conn, arg->call_id) } void* vnf_worker_proc(void *arg) { vnf_mission_t *mission = NULL; pthread_t tid = pthread_self(); vnf_task_ctx_t *task = vnf_task_get_task_info(tid); assert(task); pthread_detach(tid); while (1) { mission = vnf_mission_queue_get(task); if (mission == NULL) { sleep(1); continue; } VNF_IMAGE_DBG("tid:%lu, get...

.... This should definitely be on of the (if not main) reason why SC2 doesn't use the CPU/GPU at 100% and both are set to lowest consumption/run level. I wanted to know even what rendering threads were doing. Are they put to sleep as well? If yes, when? To do so I have to identify the thread id (pthread_self) of a thread. Which part of wine code should I instrument to get such information? Which function(s) do get called for sure by D3D rendering threads? Which part of code in wined3d.dll.so? Thanks again, Cheers, Ema! :)

.... Based on that I came up with the following code: int i = 0; //Signal handler function. The remmed out args reflect my attempt to make this work with both POSIX.1 and POSIX.4 void on_accvio(int signo/*, siginfo_t *info, void *ignored*/) { printf ("[%d] - on_accvio() : entered %d\n", pthread_self(), i++); void **_p = (void **)&signo; throw true; struct sigcontext_struct *_regs = (struct sigcontext_struct *)++_p; register unsigned long _ebp = _regs->ebp; register unsigned long _eip = _regs->eip; asm volatile ("mov %0, (%%ebp); mov %1, 4(%%ebp)" : : "r"(_e...

Hello community, I faced with bug in multithread environment in objective C code which using dispatch_async and block, __sync_add_and_fetch increments global variable. But in case of many..many threads> 5, after every __sync_add_and_fetch got damaged ... int32_t count = 0; ... int main(int argc, char *argv[]) {    for (i = 1; i < 32; ++i) {      ...         char* name;        

On a typical embedded Linux device, with no MMU, there is no fork() or it returns ENOSYS. The nearest replacements are vfork() (which is only useful before exec*()), or to create threads with pthread_create(). rsync would be a very useful program on such devices, and I was a bit disappointed to build it, only to find the compile went fine but it failed at runtime due to ENOSYS. Is there any

From: "Richard W.M. Jones" <rjones at redhat.com> If the parent process uses a pipe (or any fd, but pipes are a particular problem), then the recovery process would hold open the file descriptor(s) of the pipe, meaning that it could not be fully closed in the parent. Because the recovery process doesn't use exec(2), this wasn't avoidable even using FD_CLOEXEC. Avoid this

I will say this first -- I can't copy/paste the error message from the screen, so it's being retyped. Errors might occur. SORRY. I've been experiencing some interesting stack warnings recently when moving from R 2.2.x to the R 2.3.0 series and the R 2.4.0 series. In particular, I'm getting warnings of "Error: C stack usage is too close to the limit" before

On 2018-04-07 11:24, Bernard Spil wrote: > On 2018-04-07 9:04, Joel Sing wrote: >> On Friday 06 April 2018 21:31:01 Bernard Spil wrote: >>> Hi, >>> >>> When using OpenSSH with LibreSSL 2.7.x it cannot read existing RSA >>> and >>> ECDSA private keys. >>> >>> Error loading key "./id_rsa": invalid format

...e, char *file, int line) + { + if (mode & CRYPTO_LOCK) + { + pthread_mutex_lock(&(lock_cs[type])); + lock_count[type]++; + } + else + { + pthread_mutex_unlock(&(lock_cs[type])); + } + } + +unsigned long pthreads_thread_id(void) + { + unsigned long ret; + + ret=(unsigned long)pthread_self(); + return(ret); + } + +#endif --- ssh-openssl-thread-locking.h 2012-03-11 00:00:00.000000000 +0000 +++ ssh-openssl-thread-locking.h 2012-03-11 21:23:23.000000000 +0400 @@ -0,0 +1,75 @@ +/* This code is taken from openssl distribution crypto/threads/mttest.c */ +/* Non-pthreads code is removed. */...

...ad/thread.h:25, from avl.c:35: /usr/include/pthread.h:163: parse error before `*' /usr/include/pthread.h:165: `pthread_create' declared as function returning a function /usr/include/pthread.h:166: parse error before `void' /usr/include/pthread.h:169: parse error before `pthread_self' /usr/include/pthread.h:169: warning: data definition has no type or storage class /usr/include/pthread.h:172: parse error before `__thread1' /usr/include/pthread.h:181: parse error before `__th' /usr/include/pthread.h:187: parse error before `__th' /usr/include/pthread.h:195: parse...

...+{ + wait_for_notify(callfd); +} + +void set_affinity(const char *arg) +{ + cpu_set_t cpuset; + int ret; + pthread_t self; + long int cpu; + char *endptr; + + if (!arg) + return; + + cpu = strtol(arg, &endptr, 0); + assert(!*endptr); + + assert(cpu >= 0 || cpu < CPU_SETSIZE); + + self = pthread_self(); + CPU_ZERO(&cpuset); + CPU_SET(cpu, &cpuset); + + ret = pthread_setaffinity_np(self, sizeof(cpu_set_t), &cpuset); + assert(!ret); +} + +static void run_guest(void) +{ + int completed_before; + int completed = 0; + int started = 0; + int bufs = runcycles; + int spurious = 0; + int r;...

...+{ + wait_for_notify(callfd); +} + +void set_affinity(const char *arg) +{ + cpu_set_t cpuset; + int ret; + pthread_t self; + long int cpu; + char *endptr; + + if (!arg) + return; + + cpu = strtol(arg, &endptr, 0); + assert(!*endptr); + + assert(cpu >= 0 || cpu < CPU_SETSIZE); + + self = pthread_self(); + CPU_ZERO(&cpuset); + CPU_SET(cpu, &cpuset); + + ret = pthread_setaffinity_np(self, sizeof(cpu_set_t), &cpuset); + assert(!ret); +} + +static void run_guest(void) +{ + int completed_before; + int completed = 0; + int started = 0; + int bufs = runcycles; + int spurious = 0; + int r;...

...00030 GLIBC_2.2.5 toupper 0000000000000000 DF *UND* 000000000000000f Base _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED2Ev 0000000000000000 DF *UND* 00000000000000af GLIBC_2.2.5 pthread_rwlock_wrlock 0000000000000000 DF *UND* 000000000000000a GLIBC_2.2.5 pthread_self 0000000000000000 DF *UND* 000000000000001f Base _ZTv0_n24_NSt3__113basic_istreamIcNS_11char_traitsIcEEED0Ev 0000000000000000 DF *UND* 00000000000000e5 Base _ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5flushEv 0000000000000000 DF *UND* 0000000000000044 GLIBC_2.2.5...

Hello, I update my building scripts to build LLVM 4.0 RC1 (with clang, lldb, libc++, libc++abi, lld) on CentOS 6 and I got a lot of undefined symbols during linking LLDB. I'm using clang-3.9 and this configuration: -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++