|
From: Lee D. <lee...@mi...> - 2004-04-15 16:19:13
|
Hi folks! I'm using valgrind 2.0.0 and I'm trying to track down an issue with OpenSSL but I came across this *other* problem. I created a little test program that calls sem_init/sem_destroy. I can do 50 of these before vg barfs with a message to increase VG_N_SEMAPHORES. Every call to sem_destroy() generates a "KLUDGED call to: sem_destroy" message. So is it me or does vg's sem_destry not recover the semaphore for later reuse? Also, does anyone have a magic bullet (like a patch to openssl) to stop all those "uninitialized memory" errors that VG reports when doeing ssl operations? Also... :)... I tried cvs-ing the latest (head) and the previous (2.1.1) versions but they never worked at all. I'm running rh 7.3. If someone tells me that this does work, I'll spend the effort to figure out how. Thanks, -lee This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. |
|
From: Nicholas N. <nj...@ca...> - 2004-04-15 16:27:30
|
On Thu, 15 Apr 2004, Lee Dilkie wrote: > I created a little test program that calls sem_init/sem_destroy. I can do 50 > of these before vg barfs with a message to increase VG_N_SEMAPHORES. > > Every call to sem_destroy() generates a "KLUDGED call to: sem_destroy" > message. > > So is it me or does vg's sem_destry not recover the semaphore for later > reuse? I think this is fixed in later versions, 2.1.1 should have it, or definitely the cvs head. > Also... :)... I tried cvs-ing the latest (head) and the previous (2.1.1) > versions but they never worked at all. I'm running rh 7.3. If someone tells > me that this does work, I'll spend the effort to figure out how. What goes wrong? Can you show the output of "valgrind -v" for a sample prog, plus the output of "uname -a"? Thanks. N |
|
From: Lee D. <lee...@mi...> - 2004-04-15 16:51:20
|
> What goes wrong? Can you show the output of "valgrind -v" > for a sample > prog, plus the output of "uname -a"? Thanks. [root@localhost TUG]# uname -a Linux localhost.localdomain 2.4.18-27.7.x #1 Fri Mar 14 06:44:53 EST 2003 i686 unknown [root@localhost TUG]# valgrind -v --tool=memcheck ls ==13655== Memcheck, a memory error detector for x86-linux. ==13655== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==13655== Using valgrind-2.1.2.CVS, a program supervision framework for x86-linux. ==13655== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==13655== Valgrind library directory: /usr/local/lib/valgrind ==13655== Command line ==13655== ls ==13655== Startup, with flags: ==13655== -v ==13655== --tool=memcheck ==13655== Reading syms from /bin/ls (0x8048000) ==13655== object doesn't have a symbol table ==13655== object doesn't have any debug info --13655-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --13655-- si_code=1 Fault EIP: 0xB030B4BC (); Faulting address: 0x50100000 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 0 ==13655== at 0xB802BF5F: ??? ==13655== by 0xB802BF5E: ??? ==13655== by 0xB802BF74: ??? ==13655== by 0xB803288F: ??? sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==13655== at 0x3C000B50: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. [root@localhost TUG]# |