Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Stefan H. <hu...@in...> - 2003-05-29 14:56:23
|
On 29-May-2003 Nicholas Nethercote wrote:
> with this:
>
> if (VG_(needs).core_errors) {
> VG_(message)(Vg_UserMsg,
> "Warning: invalid file descriptor %d in syscall %s",
> fd, syscall_no == __NR_read ? "read()" : "write()" );
> VG_(pp_ExeContext)( VG_(get_ExeContext)( & VG_(threads)[tid] ) );
> }
>
Thanks. This does the trick.
--
Stefan Huelswitt
hu...@in... | http://home.pages.de/~nathan
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-29 12:50:41
|
On Thu, 29 May 2003, Stefan Huelswitt wrote:
> I'm examining a program and keep getting the message:
>
> (1) ==17858== Warning: invalid file descriptor 28 in syscall read()
>
> Is there a way to trace from where the read() was called?
In coregrind/vg_scheduler.c, try replacing this code (around line 890):
if (VG_(needs).core_errors)
VG_(message)(Vg_UserMsg,
"Warning: invalid file descriptor %d in syscall %s",
fd, syscall_no == __NR_read ? "read()" : "write()" );
with this:
if (VG_(needs).core_errors) {
VG_(message)(Vg_UserMsg,
"Warning: invalid file descriptor %d in syscall %s",
fd, syscall_no == __NR_read ? "read()" : "write()" );
VG_(pp_ExeContext)( VG_(get_ExeContext)( & VG_(threads)[tid] ) );
}
This is obviously only a temporary hack, but it should be enough to help
you for this case. Perhaps this change should be made permanent.
N
|
|
From: Stefan H. <hu...@in...> - 2003-05-29 12:33:04
|
Hi, I'm examining a program and keep getting the message: (1) ==17858== Warning: invalid file descriptor 28 in syscall read() Is there a way to trace from where the read() was called? Regards. -- Stefan Huelswitt hu...@in... | http://home.pages.de/~nathan |
|
From: Crispin F. <val...@fl...> - 2003-05-29 11:08:28
|
Hi, > Well, you haven't zeroed all your environment variables, but you have > zeroed LD_PRELOAD and LD_LIBRARY_PATH, which Valgrind currently requires > to be non-zeroed. Maybe if either of them are zeroed it should just skip > the mash_ stuff... As far as I can tell from that function it is just trying to remove its entries from the environment. It would probably make more sense for it to try and remove anything that is still around, and not complain if the application has removed the variables. If I get a chance I will have a look at getting it to remove anything that is still in the env that is valgrind related. > If this is causing problems for you (ie. you're not just playing > let's-try-to-confuse-Valgrind :) change the first line of code in > coregrind/vg_main.c:VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH)() from this: > > if (ld_preload_str == NULL || ld_library_path_str == NULL) MUTANCY(0); > > to this: > > if (ld_preload_str == NULL || ld_library_path_str == NULL) return; Thanks, this fixes the running of CGI scripts under our Web Server (Zeus). Crispin |
|
From: Nicholas N. <nj...@ca...> - 2003-05-29 10:20:53
|
On 29 May 2003, Crispin Flowerday wrote:
> The following program is simple test program that cause valgrind (cvs
> version) to crash out with the mash_LD_PRELOAD... error when it
> encounters the exec. (the FAQ asked for a test case).
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <unistd.h>
>
> int main( int argc, char ** argv )
> {
> char * arg[] = { "/bin/true", 0 };
> char * env[] = { "PATH=/bin", 0 };
>
> execve( "/bin/true", arg, env );
>
> fprintf( stderr, "Failed to exec\n" );
> exit(1);
> }
The FAQ says:
One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Avoid this if you can.
Well, you haven't zeroed all your environment variables, but you have
zeroed LD_PRELOAD and LD_LIBRARY_PATH, which Valgrind currently requires
to be non-zeroed. Maybe if either of them are zeroed it should just skip
the mash_ stuff...
If this is causing problems for you (ie. you're not just playing
let's-try-to-confuse-Valgrind :) change the first line of code in
coregrind/vg_main.c:VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH)() from this:
if (ld_preload_str == NULL || ld_library_path_str == NULL) MUTANCY(0);
to this:
if (ld_preload_str == NULL || ld_library_path_str == NULL) return;
It works for the program above, at least.
N
|
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-05-29 10:17:57
|
This instruction is not implemented (in 1.9.6), though its twin sahf is (and is listed in FPU ops in vg_to_ucode.c though it's not an FPU insn). I had a quick look at adding it, but the ucode generation is not immediately obvious, though the HTML docs do help getting started. So, is anyone doing this yet ? Also, while checking that segment overrides were actually there :) I noticed that the size override (db 66h) unconditionally sets the operand size to 2, though it actually switches between 2 and 4, depending on the default size. Is it an oversight, or just because default 2 byte operand size is unsupported ? Thanks -- Vincent Penquerc'h |
|
From: Crispin F. <val...@fl...> - 2003-05-29 09:44:20
|
Hi,
The following program is simple test program that cause valgrind (cvs
version) to crash out with the mash_LD_PRELOAD... error when it
encounters the exec. (the FAQ asked for a test case).
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int main( int argc, char ** argv )
{
char * arg[] = { "/bin/true", 0 };
char * env[] = { "PATH=/bin", 0 };
execve( "/bin/true", arg, env );
fprintf( stderr, "Failed to exec\n" );
exit(1);
}
Cheers
Crispin
|
|
From: Nicholas N. <nj...@ca...> - 2003-05-29 09:05:37
|
On Thu, 29 May 2003, Sami Romdhani wrote: > I know that there is no support in valgrind for mmx, sse and sse2 > instructions. There is now: grab the latest version from CVS (sourceforge.net/cvs/?group_id=46268) and follow instructions in README to install. I think MMX support is complete, or close to complete, and SSE/SSE2 support is at least partly done. Hopefully it will get things working for you. N |
|
From: Sami R. <sam...@un...> - 2003-05-29 08:30:44
|
Dear valgrind users and developers, My program uses the ATLAS version of the blas library and the clapack library (see http://math-atlas.sourceforge.net/). blas-atlas is a linear algebra package heavily optimized for the machine it's running on. When I valgrind my program it crashes with: disInstr: unhandled 2-byte opcode 0x18 This _might_ be the result of executing an MMX, SSE, SSE2 or 3DNow! instruction. Valgrind does not currently support such instructions. Sorry. This happens when a blas function is called. I know that there is no support in valgrind for mmx, sse and sse2 instructions. But it there still a way to detect the memory problems of my program with valgrind ? even letting valgrind ignore these blas functions would be good for me. If there is no way, would it be possible sometimes in the future and if yes, when ? Thanks, Sami. -- http://informatik.unibas.ch/personen/romdhani_sami/ |
|
From: Nicholas N. <nj...@ca...> - 2003-05-29 07:30:53
|
On Wed, 28 May 2003, Madhu M Kurup wrote: > On a sortof related note, the gen-suppressions option is really cool, > although it could be possibly improved; I have some ideas Fire away. N |
|
From: Madhu M K. <mm...@ya...> - 2003-05-28 23:28:50
|
Hi, Nicholas Nethercote <nj...@ca...> said: > I've hacked up support for a basic gdb-style interactive shell for > Valgrind. To try it out, download On a sortof related note, the gen-suppressions option is really cool, although it could be possibly improved; I have some ideas - is that still being worked on? Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Nicholas N. <nj...@ca...> - 2003-05-28 21:07:45
|
Hi, I've hacked up support for a basic gdb-style interactive shell for Valgrind. To try it out, download www.cl.cam.ac.uk/~njn25/valgrind-interactive.tar.bz2. Install as usual. It supports the basic gdb-type commands -- add, remove, list breakpoints; print values in registers/memory locations. The interesting part is that you can also query meta-data tracked by skins, if they support it. At the moment, I only added support for the Memcheck skin; you can inspect the A (addressability) and V (validity) bits for each byte, but any skin could support this. To run it, use the --interactive=yes option, then type "help" to show the available commands. It's all pretty straightforward. One unfortunate limitation is that you can't step through code line-by-line. Unlike most of the other current limitations, this one wasn't for lack of effort, but because I don't (yet?) know how to do it. The lack of ways to specify data locations is the biggest weakness ("help" tells you the currently supported ways). Ideally, it would handle local variables and allow expressions such as foo[3].bar->baz as data locations. Unfortunately, getting that to work would require beefing up Valgrind's debug info reader greatly, which is not impossible, but would be a lot of work. Another thing: it's a bit different to gdb (or other normal debuggers) in one important respect. With gdb, you start it up and then gdb can start your program, kill it, and start again -- the debugger is "outside" the program. Valgrind's shell is different. Because Valgrind effectively becomes part of your program when you use it (Valgrind and your program run as one process), Valgrind's shell is effectively "inside" your program. This means that killing your program kills the shell, so if you eg. want to restart your program, you have to restart Valgrind with it. It's very much prototype-quality code; there are bound to be bugs. I'm putting it out there to get feedback, find out if this would be useful to anyone. Hopefully yes, although there's no guarantees this will ever make it into Valgrind-proper. Nonetheless, enjoy. N |
|
From: Robert W. <rj...@du...> - 2003-05-28 20:25:41
|
> Valgrind, however, thinks that this is a CDROM-related ioctl() call > and issues three errors to me. The log is below. I am using RH8 with > glibc 2.2.93. Looks like this is valgrind core related, not > application error. Could someone look into that? If you look in the header files, CDROMREADTOCENTRY has the same value as I_SRDOPT, which is unfortunate. The only way you could tell these two apart is by knowing that the file descriptor in question is a socket file descriptor. My file descriptor leakage patch already makes note of that (i.e. that a file descriptor is a socket file descriptor) - it shouldn't be too much trouble to modify it the ioctl code to check this. Give me about a day or so and I'll see what I can do. Regards, Robert. |
|
From: Alex I. <ale...@in...> - 2003-05-28 20:04:42
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Gentlemen,
<p>I am issuing an ioctl() call on a UNIX-domain socket to set it to message
non-discard mode. Here is the trivial snippet of code:<font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier">---------------------------------------------------------------------------------</font>
<br><font face="Courier New,Courier"> struct sockaddr_un socketAddress;</font>
<br><font face="Courier New,Courier"> int socketFd = socket ( AF_UNIX,
SOCK_DGRAM, 0 );</font><font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier"> if ( socketFd < 0 )</font>
<br><font face="Courier New,Courier"> return -1;</font><font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier"> memset( &socketAddress, 0,
sizeof( socketAddress ));</font>
<br><font face="Courier New,Courier"> strcpy ( socketAddress.sun_path,
"/tmp/testlistener" );</font>
<br><font face="Courier New,Courier"> socketAddress.sun_family = AF_UNIX;</font>
<br><font face="Courier New,Courier"> unlink ( "/tmp/testlistener"
);</font>
<br><font face="Courier New,Courier"> unsigned int len = strlen(socketAddress.sun_path)
+</font>
<br><font face="Courier New,Courier"> sizeof(socketAddress.sun_family);</font><font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier"> if ( bind (socketFd,(struct sockaddr*)&socketAddress,len
) < 0 )</font>
<br><font face="Courier New,Courier"> {</font>
<br><font face="Courier New,Courier"> return -1;</font>
<br><font face="Courier New,Courier"> }</font>
<br><font face="Courier New,Courier"> </font>
<br><font face="Courier New,Courier"> // ... Set the
socket to message non-discard mode</font>
<br><font face="Courier New,Courier"> ioctl ( socketFd,
I_SRDOPT, RMSGN );</font><font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier">---------------------------------------------------------------------------------</font><font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier">Valgrind, however, thinks that this
is a CDROM-related ioctl() call and issues three errors to me. The log
is below. I am using RH8 with glibc 2.2.93. Looks like this
is valgrind core related, not application error. Could someone look into
that?</font><font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier">Thanks a lot!</font>
<br><font face="Courier New,Courier">Alex</font>
<br><font face="Courier New,Courier"></font> <font face="Courier New,Courier"></font>
<p><font face="Courier New,Courier">==28423== ERROR SUMMARY: 3 errors from
3 contexts (suppressed: 0 from 0)</font>
<br><font face="Courier New,Courier">==28423==</font>
<br><font face="Courier New,Courier">==28423== 1 errors in context 1 of
3:</font>
<br><font face="Courier New,Courier">==28423== Syscall param ioctl(CDROMREADTOCENTRY)
contains unaddressable byte(s)</font>
<br><font face="Courier New,Courier">==28423== at 0x420D3454:
__GI___ioctl (in /lib/i686/libc-2.2.93.so)</font>
<br><font face="Courier New,Courier">==28423== by 0x420158D3:
__libc_start_main (in /lib/i686/libc-2.2.93.so)</font>
<br><font face="Courier New,Courier">==28423== by 0x8048408:
(within /home/agi/probe/Prototype/ValgrindIoctlTest/a.out)</font>
<br><font face="Courier New,Courier">==28423== Address
0x2 is not stack'd, malloc'd or free'd</font>
<br><font face="Courier New,Courier">==28423==</font>
<br><font face="Courier New,Courier">==28423== 1 errors in context 2 of
3:</font>
<br><font face="Courier New,Courier">==28423== Syscall param ioctl(CDROMREADTOCENTRY
(cdte_track, char)) contains uninitialised or unaddressable byte(s)</font>
<br><font face="Courier New,Courier">==28423== at 0x420D3454:
__GI___ioctl (in /lib/i686/libc-2.2.93.so)</font>
<br><font face="Courier New,Courier">==28423== by 0x420158D3:
__libc_start_main (in /lib/i686/libc-2.2.93.so)</font>
<br><font face="Courier New,Courier">==28423== by 0x8048408:
(within /home/agi/probe/Prototype/ValgrindIoctlTest/a.out)</font>
<br><font face="Courier New,Courier">==28423== Address
0x2 is not stack'd, malloc'd or free'd</font>
<br><font face="Courier New,Courier">==28423==</font>
<br><font face="Courier New,Courier">==28423== 1 errors in context 3 of
3:</font>
<br><font face="Courier New,Courier">==28423== Syscall param ioctl(CDROMREADTOCENTRY
(cdte_format, char)) contains uninitialised or unaddressable byte(s)</font>
<br><font face="Courier New,Courier">==28423== at 0x420D3454:
__GI___ioctl (in /lib/i686/libc-2.2.93.so)</font>
<br><font face="Courier New,Courier">==28423== by 0x420158D3:
__libc_start_main (in /lib/i686/libc-2.2.93.so)</font>
<br><font face="Courier New,Courier">==28423== by 0x8048408:
(within /home/agi/probe/Prototype/ValgrindIoctlTest/a.out)</font>
<br><font face="Courier New,Courier">==28423== Address
0x4 is not stack'd, malloc'd or free'd</font>
<br><font face="Courier New,Courier">==28423== IN SUMMARY: 3 errors from
3 contexts (suppressed: 0 from 0)</font>
<br><font face="Courier New,Courier">==28423==</font>
<br><font face="Courier New,Courier">==28423== malloc/free: in use at exit:
0 bytes in 0 blocks.</font>
<br><font face="Courier New,Courier">==28423== malloc/free: 0 allocs, 0
frees, 0 bytes allocated.</font>
<pre>--
Alex G. Ivershen Inet Technologies, Inc.
Network Products Dept. 1500 N. Greenville Ave.
Inet Technologies Inc. Richardson, TX 75081
Phone: +1-469-330-4295 USA
"Black Holes are where God divided by zero"</pre>
</html>
|
|
From: Ravi G. <RGo...@fo...> - 2003-05-28 19:59:23
|
Hi all, Running Valgrind on my application gave the following error. = Immediate help is appreciated. Thanks, Ravi =20 [root@localhost bin]# valgrind ./nfdII.dbg=20 =3D=3D12749=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for = x86-linux. =3D=3D12749=3D=3D Copyright (C) 2002, and GNU GPL'd, by Julian Seward. =3D=3D12749=3D=3D Using valgrind-1.9.6, a program instrumentation system = for x86-linux. =3D=3D12749=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian = Seward. =3D=3D12749=3D=3D Estimated CPU clock rate is 2442 MHz =3D=3D12749=3D=3D For more details, rerun with: -v =3D=3D12749=3D=3D=20 =3D=3D12749=3D=3D pthread_mutex_destroy: mutex is still in use =3D=3D12749=3D=3D at 0x402183B4: pthread_error (vg_libpthread.c:292) =3D=3D12749=3D=3D by 0x402192CF: __pthread_mutex_destroy (in = /usr/local/lib/valgrind/libpthread.so) =3D=3D12749=3D=3D by 0x402AB014: _IO_default_finish (in = /lib/libc-2.1.3.so) =3D=3D12749=3D=3D by 0x402AA665: _IO_file_finish@@GLIBC_2.1 = (fileops.c:162) =3D=3D12749=3D=3D=20 =3D=3D12749=3D=3D pthread_mutex_unlock: mutex is not locked =3D=3D12749=3D=3D at 0x4021928A: __pthread_mutex_unlock (in = /usr/local/lib/valgrind/libpthread.so) =3D=3D12749=3D=3D by 0x4021C916: _IO_funlockfile (in = /usr/local/lib/valgrind/libpthread.so) =3D=3D12749=3D=3D by 0x402A645A: _IO_fclose@@GLIBC_2.1 = (iofclose.c:54) =3D=3D12749=3D=3D by 0x804D951: SaveMyPID(long) (nfmain.cpp:999) disInstr: unhandled opcode 0xEC then 0x88 =20 valgrind: the `impossible' happened: unhandled x86 opcode Basic block ctr is approximately 0 =20 sched status: =20 Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D = 0x0 =3D=3D12749=3D=3D at 0x807C418: inb(unsigned short) (in = /home/ravi62/LATEST/vpnsrc/bin/nfdII.dbg) =3D=3D12749=3D=3D by 0x804BF81: main (nfmain.cpp:127) =3D=3D12749=3D=3D by 0x4026C9CA: __libc_start_main (in = /lib/libc-2.1.3.so) =3D=3D12749=3D=3D by 0x804BDE0: (within = /home/ravi62/LATEST/vpnsrc/bin/nfdII.dbg) =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.478 / Virus Database: 275 - Release Date: 5/6/2003 =20 |
|
From: Alex I. <ale...@in...> - 2003-05-28 19:56:42
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Thank you Paul and everyone who replied - I got it working perfectly now! <p>Regards, <br>Alex <p>Paul Haas wrote: <blockquote TYPE=CITE>On Tue, 27 May 2003, Alex Ivershen wrote: <p>> Hi all, <p>> I have an application that spawns quite a few children processes. These <br>> children cannot be run standalone, they have to spawned by that master <br>> process.? What I would like to do is to spawn just one of the children <br>> with Valgrind. I can tell the master application which child to spawn <br>> with Valgrind via a command-line switch, but the actual spawning is where <br>> I am at a loss.? The master app is doing an execl() call,? so I would <br>> need to explicitly list all Valgrind options in that call and then the <br>> application name. This is not very useful since I won't be able to change <br>> skins and options on the fly. <br>> <br>> One way I could do it is tweak Valgrind code to read options from an <br>> environment variable, say VALGRIND_OPTS="-v --logfile=/tmp/VLOG" <br>> --leak-check=yes" and then in execl() call do something like: <p>Write a 2 line script ValgrindWithOptions, which does: <p>#!/bin/sh <br>exec valgrind $VALGRIND_OPTS $* <p>You can replace the 2 line script with a program in your language of <br>choice, assuming your language of choice supports some form of exec() and <br>won't trample any state information (like file descriptors) that the <br>parent process sends to the child. <p>> if ( valgrind switch is set ) <br>> ??? execl ( ... , "valgrind", "Application", .... ) <p> ??? execl ( ... , "ValgrindWithOptions", "Application", .... ) <p>Or if there is enough information, you could rename "Application" and call <br>your script Application. Then your script gets more complicated, because <br>it would have to figure out which child process should be valgrind'ed. <p>> else <br>> ??? execl ( ... , "Application", ... ) <p>> I would rather not modify Valgrind source, since I would have to carry <br>> over changes between Valgrind versions. Is there any easier? way to do <br>> what I am trying to accomplish?? Any help would be greatly appreciated! <p>> Thanks! <br>> Alex Ivershen <br>> <br>> --? <br>> Alex G. Ivershen??????????????????????????? Inet Technologies, Inc. <br>> Network Products Dept.????????????????????? 1500 N. Greenville Ave. <br>> Inet Technologies Inc.????????????????????? Richardson, TX 75081 <br>> Phone: +1-469-330-4295????????????????????? USA <br>> <br>> "Black Holes are where God divided by zero" <br>> ? ------------------------------------------------------- This SF.net <br>> email is sponsored by: ObjectStore. If flattening out C++ or Java code to <br>> make your application fit in a relational database is painful, don't do <br>> it! Check out ObjectStore. Now part of Progress Software. <br>> <a href="http://www.objectstore.net/sourceforge">http://www.objectstore.net/sourceforge</a> <br>> _______________________________________________ Valgrind-users mailing <br>> list Val...@li... <br>> <a href="https://lists.sourceforge.net/lists/listinfo/valgrind-users">https://lists.sourceforge.net/lists/listinfo/valgrind-users</a> <br>></blockquote> <pre>-- Alex G. Ivershen Inet Technologies, Inc. Network Products Dept. 1500 N. Greenville Ave. Inet Technologies Inc. Richardson, TX 75081 Phone: +1-469-330-4295 USA "Black Holes are where God divided by zero"</pre> </html> |
|
From: Dima B. <di...@cs...> - 2003-05-28 16:56:33
|
Upon further investigation I have found the following.
If I have:
Process 1 Process 2
open( pipe1, O_WRONLY ) -->-->--> pipe 1 -->-->--> open( pipe1, O_RDONLY );
open( pipe2, O_RDONLY ) --<--<--< pipe 2 --<--<--< open( pipe2, O_WRONLY );
The valgrind gets stuck on the open call on pipe1 in process 2. It only
gets stuck in my larger program, a smaller program that just opens the
pipes works fine. My bigger program has many threads, but at the time
of pipe creation no threads have been started up yet.
No if I have:
Process 1 Process 2
open( pipe1, O_RDWR ) -->-->--> pipe 1 -->-->--> open( pipe1, O_RDWR );
open( pipe2, O_RDWR ) --<--<--< pipe 2 --<--<--< open( pipe2, O_RDWR );
^ ^
| |
Than everything works fine. Will provide an strace output shortly.
ttyl
Dima
On Wed, May 28, 2003 at 01:02:47AM -0700, Jeremy Fitzhardinge wrote:
> On Tue, 2003-05-27 at 21:11, Jeremy Fitzhardinge wrote:
> > On Tue, 2003-05-27 at 18:41, Dima Brodsky wrote:
> > > I am not sure why and what is causing the problems. I have not used
> > > previous versions of valgrind with named pipes so I don't know if things
> > > were broken or not before.
> >
> > Valgrind doesn't deal with the blocking semantics of FIFO files. I have
> > a patch, but it doesn't apply to the current tree; I'll need to update
> > it. I've attached it in its current form if you want to play with it
> > before I get to it.
>
> Silly me. This is already in there. If you're seeing problems, it
> would be useful if you can provide a small program which reproduces it.
> strace output would be useful too.
>
> J
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
--
Dima Brodsky di...@cs...
http://www.cs.ubc.ca/~dima
201-2366 Main Mall
Department of Computer Science (604) 822-2895 (DSG Lab)
University of British Columbia, Canada (604) 822-5485 (FAX)
"The price of reliability is the pursuit of the utmost simplicity.
It is a price which the very rich find the most hard to pay."
(Sir Antony Hoare, 1980)
|
|
From: Jeremy F. <je...@go...> - 2003-05-28 08:15:44
|
On Tue, 2003-05-27 at 21:11, Jeremy Fitzhardinge wrote: > On Tue, 2003-05-27 at 18:41, Dima Brodsky wrote: > > I am not sure why and what is causing the problems. I have not used > > previous versions of valgrind with named pipes so I don't know if things > > were broken or not before. > > Valgrind doesn't deal with the blocking semantics of FIFO files. I have > a patch, but it doesn't apply to the current tree; I'll need to update > it. I've attached it in its current form if you want to play with it > before I get to it. Silly me. This is already in there. If you're seeing problems, it would be useful if you can provide a small program which reproduces it. strace output would be useful too. J |
|
From: Nicholas N. <nj...@ca...> - 2003-05-28 07:53:07
|
On Tue, 27 May 2003, Alex Ivershen wrote: > I have an application that spawns quite a few children processes. By default, Valgrind does not trace child processes. This means that if you Valgrind a script, Valgrind will check the script interpreter, eg. Perl or Bash or whatever, but not any child processes exec'd by the script. But if you specify --trace-children=yes, it does trace children. But if you must Valgrind only one of the children, this won't be precise enough. > if ( valgrind switch is set ) #include memcheck.h, and use the RUNNING_ON_VALGRIND macro to do this check. HTH N |
|
From: Jeremy F. <je...@go...> - 2003-05-28 04:11:31
|
On Tue, 2003-05-27 at 18:41, Dima Brodsky wrote: > I am not sure why and what is causing the problems. I have not used > previous versions of valgrind with named pipes so I don't know if things > were broken or not before. Valgrind doesn't deal with the blocking semantics of FIFO files. I have a patch, but it doesn't apply to the current tree; I'll need to update it. I've attached it in its current form if you want to play with it before I get to it. J |
|
From: Dima B. <di...@cs...> - 2003-05-28 01:42:07
|
Hi,
I am having some trouble with valgrind 1.9.6 and named pipes. In the
application when I create the named pipes, mkfifo, the application blocks
indefinitely in the open call if it is run by valgrind. Without valgrind
it works as it supposed to.
I am not sure why and what is causing the problems. I have not used
previous versions of valgrind with named pipes so I don't know if things
were broken or not before.
Thanks for any and all help.
ttyl
Dima
--
Dima Brodsky di...@cs...
http://www.cs.ubc.ca/~dima
201-2366 Main Mall
Department of Computer Science (604) 822-2895 (DSG Lab)
University of British Columbia, Canada (604) 822-5485 (FAX)
"The price of reliability is the pursuit of the utmost simplicity.
It is a price which the very rich find the most hard to pay."
(Sir Antony Hoare, 1980)
|
|
From: Olly B. <ol...@su...> - 2003-05-28 00:57:17
|
On Tue, May 27, 2003 at 03:59:33PM -0500, Alex Ivershen wrote:
> One way I could do it is tweak Valgrind code to read options from an
> environment variable, say VALGRIND_OPTS="-v --logfile=/tmp/VLOG" --leak-check=
> yes"
Um, valgrind already reads options from the environmental variable
VALGRIND_OPTS - it has since at least valgrind 1.0.4 (the oldest I
have to hand).
Cheers,
Olly
|
|
From: Paul H. <pa...@ha...> - 2003-05-27 21:22:02
|
On Tue, 27 May 2003, Alex Ivershen wrote: > Hi all, > I have an application that spawns quite a few children processes. These > children cannot be run standalone, they have to spawned by that master > process.=A0 What I would like to do is to spawn just one of the children > with Valgrind. I can tell the master application which child to spawn > with Valgrind via a command-line switch, but the actual spawning is where > I am at a loss.=A0 The master app is doing an execl() call,=A0 so I would > need to explicitly list all Valgrind options in that call and then the > application name. This is not very useful since I won't be able to change > skins and options on the fly. > > One way I could do it is tweak Valgrind code to read options from an > environment variable, say VALGRIND_OPTS=3D"-v --logfile=3D/tmp/VLOG" > --leak-check=3Dyes" and then in execl() call do something like: Write a 2 line script ValgrindWithOptions, which does: #!/bin/sh exec valgrind $VALGRIND_OPTS $* You can replace the 2 line script with a program in your language of choice, assuming your language of choice supports some form of exec() and won't trample any state information (like file descriptors) that the parent process sends to the child. > if ( valgrind switch is set ) > =A0=A0=A0 execl ( ... , "valgrind", "Application", .... ) =A0=A0=A0 execl ( ... , "ValgrindWithOptions", "Application", .... ) Or if there is enough information, you could rename "Application" and call your script Application. Then your script gets more complicated, because it would have to figure out which child process should be valgrind'ed. > else > =A0=A0=A0 execl ( ... , "Application", ... ) > I would rather not modify Valgrind source, since I would have to carry > over changes between Valgrind versions. Is there any easier=A0 way to do > what I am trying to accomplish?=A0 Any help would be greatly appreciated! > Thanks! > Alex Ivershen > > --=A0 > Alex G. Ivershen=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Inet Technologies, Inc. > Network Products Dept.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 1500 N. Greenville Ave. > Inet Technologies Inc.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Richardson, TX 75081 > Phone: +1-469-330-4295=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 USA > > "Black Holes are where God divided by zero" > =A0 ------------------------------------------------------- This SF.net > email is sponsored by: ObjectStore. If flattening out C++ or Java code to > make your application fit in a relational database is painful, don't do > it! Check out ObjectStore. Now part of Progress Software. > http://www.objectstore.net/sourceforge > _______________________________________________ Valgrind-users mailing > list Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Alex I. <ale...@in...> - 2003-05-27 21:00:05
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi all, <p>I have an application that spawns quite a few children processes. These children cannot be run standalone, they have to spawned by that master process. What I would like to do is to spawn just one of the children with Valgrind. I can tell the master application which child to spawn with Valgrind via a command-line switch, but the actual spawning is where I am at a loss. The master app is doing an execl() call, so I would need to explicitly list all Valgrind options in that call and then the application name. This is not very useful since I won't be able to change skins and options on the fly. <p>One way I could do it is tweak Valgrind code to read options from an environment variable, say VALGRIND_OPTS="-v --logfile=/tmp/VLOG" --leak-check=yes" and then in execl() call do something like: <p>if ( valgrind switch is set ) <br> execl ( ... , "valgrind", "Application", .... ) <br>else <br> execl ( ... , "Application", ... ) <p>I would rather not modify Valgrind source, since I would have to carry over changes between Valgrind versions. Is there any easier way to do what I am trying to accomplish? Any help would be greatly appreciated! <p>Thanks! <br>Alex Ivershen <pre>-- Alex G. Ivershen Inet Technologies, Inc. Network Products Dept. 1500 N. Greenville Ave. Inet Technologies Inc. Richardson, TX 75081 Phone: +1-469-330-4295 USA "Black Holes are where God divided by zero"</pre> </html> |
|
From: Hong C. <hc...@N-...> - 2003-05-27 18:53:14
|
I fixed this by rebuilding the applcation with debug option ( -g ), and
it works now.( One of the libs doesn't contain debug info before ). As
you said , the problem is caused by uninitialized variable,
following is the detailed messages when the app is running :
==4193== Conditional jump or move depends on uninitialised value(s)
==4193== at 0x403AD7AC: __wcslen (in /lib/libc-2.3.2.so)
==4193== by 0x403AEA0E: __wcsrtombs (in /lib/libc-2.3.2.so)
==4193== by 0x40377136: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)
==4193== by 0x403974B3: _IO_vsnprintf (in /lib/libc-2.3.2.so)
==4193==
==4193== Conditional jump or move depends on uninitialised value(s)
==4193== at 0x40348829: internal_ascii_loop (in /lib/libc-2.3.2.so)
==4193== by 0x40347084: __gconv_transform_internal_ascii (in
/lib/libc-2.3.2.so)
==4193== by 0x403AEAC9: __wcsrtombs (in /lib/libc-2.3.2.so)
==4193== by 0x40377136: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)
==4193==
==4193== Conditional jump or move depends on uninitialised value(s)
==4193== at 0x403AEFEE: __wcsnlen (in /lib/libc-2.3.2.so)
==4193== by 0x403AE94A: __wcsrtombs (in /lib/libc-2.3.2.so)
==4193== by 0x403771BC: _IO_vfprintf_internal (in /lib/libc-2.3.2.so)
==4193== by 0x403974B3: _IO_vsnprintf (in /lib/libc-2.3.2.so)
==4193==
==4193== Conditional jump or move depends on uninitialised value(s)
==4193== at 0x40348829: internal_ascii_loop (in /lib/libc-2.3.2.so)
==4193== by 0x40347084: __gconv_transform_internal_ascii (in
/lib/libc-2.3.2.so)
==4193== by 0x403AE9A8: __wcsrtombs (in /lib/libc-2.3.2.so)
==4193== by 0x403771BC: _IO_vfprintf_internal (in
/lib/libc-2.3.2.so)
As this comes from the libc, perhaps it's not a bug of valgrind.
thanks for your help
hong
On Tue, 2003-05-27 at 12:09, Nicholas Nethercote wrote:
> On 27 May 2003, Hong Chen wrote:
>
> > I'm using valgrind to detect leaks in my program without any luck. When
> > I start valgrind :
> > valgrind -v myapp args
> >
> > it worked fine at the very beginning, but when it tried to load a shared
> > object , following error messages showed up :
> >
> > ==2684== Jump to the invalid address stated on the next line
> > ==2684== at 0x0: ???
> > ==2684== Address 0x0 is not stack'd, malloc'd or free'd
> > Segmentation fault
> >
> > Without valgrind, I haven't get any trouble to run myapp. Could anyone
> > give me a pointer ? any input would be appreciated.
>
> That's the message you have a variable that is uninitialised, and then you
> try to jump to the "address" stored in that variable. But since your
> program works fine normally, I'd guess it's a Valgrind bug. Can you
> provide the full output from running with -v? Better still, can you trim
> down your program into a small example that triggers the error?
>
> Thanks.
>
> N
|
188 messages has been excluded from this view by a project administrator.
