Search Results

Search found 3 results on 1 pages for 'alesplin'.

Page 1/1 | 1 

• How to make xlock use the first key I hit as a part of my password

  - by alesplin

  I just switched from Arch Linux to Ubuntu 10.10. I'm running the Fluxbox window manager, and I use xlockmore to lock my screen with the following key shortcut: 192 :Exec xlock-mode marquee +usefirst -icongeometry 240x240 -message "back in a minute..." The problem I'm having is that xlock is definitely not using my first key as part of my password. Instead, it uses some randomized fade pattern to fade to the password screen. I find this highly annoying, as when I get back to my desk and start entering my password it doesn't register password characters until the fade pattern is complete. I've also tried the following modifications with no difference: 192 :Exec xlock -mode marquee -usefirst -icongeometry 240x240 -message "back in a minute..." 192 :Exec xlock -mode marquee -icongeometry 240x240 -message "back in a minute..." The first example worked flawlessly on Arch. Does Ubuntu have some sort of system default that you can't override on the command-line?

  Read the article

• strlen returns incorrect value when called in gdb

  - by alesplin

  So I'm noticing some severely incorrect behavior from calls to standard library functions inside GDB. I have the following program to illustrate: #include <stdio.h> #include <stdlib.h> #include <string.h> int main(int argc, char *argv[]) { char *s1 = "test"; char *s2 = calloc(strlen("test")+1,sizeof(char)); snprintf(s2,strlen("test")+1,"test"); printf("string constant: %lu\n", strlen(s1)); printf("allocated string: %lu\n", strlen(s2)); free(s2); return 0; } When run from the command-line, this program outputs just what you'd expect: string constant: 4 allocated string: 4 However, in GDB, I get the following, incorrect output from calls to strlen(): (gdb) p strlen(s1) $1 = -938856896 (gdb) p strlen(s2) $2 = -938856896 I'm pretty sure this is a problem with glibc shipped with Ubuntu (I'm using 10.10), but this is a serious problem for those of us who spend lots of time in GDB. Is anyone else experiencing this kind of error? What's the best way to fix it? Build glibc from source? (I'm already running a version of GDB built from source)

  Read the article

• pthread_create followed by pthread_detach still results in possibly lost error in Valgrind.

  - by alesplin

  I'm having a problem with Valgrind telling me I have some memory possible lost: ==23205== 544 bytes in 2 blocks are possibly lost in loss record 156 of 265 ==23205== at 0x6022879: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23205== by 0x540E209: allocate_dtv (in /lib/ld-2.12.1.so) ==23205== by 0x540E91D: _dl_allocate_tls (in /lib/ld-2.12.1.so) ==23205== by 0x623068D: pthread_create@@GLIBC_2.2.5 (in /lib/libpthread-2.12.1.so) ==23205== by 0x758D66: MTPCreateThreadPool (MTP.c:290) ==23205== by 0x405787: main (MServer.c:317) The code that creates these threads (MTPCreateThreadPool) basically gets an index into a block of waiting pthread_t slots, and creates a thread with that. TI becomes a pointer to a struct that has a thread index and a pthread_t. (simplified/sanitized): for (tindex = 0; tindex < NumThreads; tindex++) { int rc; TI = &TP->ThreadInfo[tindex]; TI->ThreadID = tindex; rc = pthread_create(&TI->ThreadHandle,NULL,MTPHandleRequestsLoop,TI); /* check for non-success that I've omitted */ pthread_detach(&TI->ThreadHandle); } Then we have a function MTPDestroyThreadPool that loops through all the threads we created and cancels them (since the MTPHandleRequestsLoop doesn't exit). for (tindex = 0; tindex < NumThreads; tindex++) { pthread_cancel(TP->ThreadInfo[tindex].ThreadHandle); } I've read elsewhere (including other questions here on SO) that detaching a thread explicitly would prevent this possibly lost error, but it clearly isn't. Any thoughts?

  Read the article

1