|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-13 09:24:03
|
Hi, I posted message:
Message-ID: <B14C9D7F1977D111AD740060970ACBDA0189307D@warhol>
on the 30th of may 2003, and no answer was received. This patch
adds some ioctls and fixes some documentation (I'm unsure of the
actual extent of it, as I am not the patch author).
From the traffic on the list, it seems this patch suffers from
the same flaw as another one that stayed unapplied: addition of
include files which may or may not be present on the tgarget
system. Am I right in assuming this is the reason the patch was
not applied ? A quick answer would be nice, time permitting.
I can post the patches again if requested, if you can't find
the above message. Main text follows.
Thanks.
--
Vincent Penquerc'h
Hi,
This is from my girlfriend, who had been using Valgrind 1.0.4, and
ported some patches to 1.9.6.
--
Vincent Penquerc'h
Hi
I've been playing with valgrind (which is a very useful tool). I needed some
more ioctls, which I added (patch 'ioctls.diff' attached) and I've some
problems with signals.
IOCTLS:
I've added a tty, 2 sound, several frame buffer and VT ioctls.
These ioctls are very lightly tested : I've run programs which I know use
them
under valgrind, they worked and valgrind didn't complain.
I've also updated README_MISSING_SYSCALL_OR_IOCTL to use the new
SYSCAL_TRACK,
etc. instead of must_be_writable, etc.
SIGNALS:
From the manual (2.9 Handling of signals)
As specified by POSIX, a signal is blocked in its own handler.
From a comment at the beginning of coregrind/vg_signal.c
- A signal is not masked in its own handler. Neither are the
signals in the signal's blocking mask.
Which one is true ? (or which one is meant to be true ? ;)
There's a typical output of the program attached ('signals.c')
(run with valgrind -v --trace-signals=yes) :
... Skipping ...
[ 0] --28471-- signal 29 arrived ... queued
[ 1] --28471-- delivering signal 29 to thread 1
[ 2] --28471-- signal 29 arrived ... queued
[ 3] --28471-- signal 29 arrived ... already pending; discarded
[ 4] --28471-- signal 29 arrived ... already pending; discarded
[ 5] --28471-- signal 29 arrived ... already pending; discarded
[ 6] --28471-- signal 29 arrived ... already pending; discarded
[ 7] --28471-- signal 29 arrived ... already pending; discarded
[ 8] --28471-- signal 29 arrived ... already pending; discarded
[ 9] --28471-- signal 29 arrived ... already pending; discarded
[10] --28471-- signal 29 arrived ... already pending; discarded
[11] --28471-- signal 29 arrived ... already pending; discarded
[12] --28471-- signal 29 arrived ... already pending; discarded
[13] --28471-- signal 29 arrived ... already pending; discarded
[14] --28471-- signal 29 arrived ... already pending; discarded
[15] --28471-- signal 29 arrived ... already pending; discarded
[16] --28471-- signal 29 arrived ... already pending; discarded
[17] --28471-- signal 29 arrived ... already pending; discarded
[18] --28471-- signal 29 arrived ... already pending; discarded
[19] Entering: 1
[20] --28471-- delivering signal 29 to thread 1
[21] Entering: 2
[22] --28471-- signal 29 arrived ... queued
[23] --28471-- signal 29 arrived ... already pending; discarded
[24] --28471-- signal 29 arrived ... already pending; discarded
[25] Returning: 2
[26] --28471-- delivering signal 29 to thread 1
[27] Entering: 3
[28] Returning: 3
[29] --28471-- vg_pop_signal_frame (thread 1): valid magic
[30] --28471-- signal 29 arrived ... queued
[31] --28471-- vg_pop_signal_frame (thread 1): valid magic
[32] Returning: 1
[33] --28471-- delivering signal 29 to thread 1
[34] Entering: 2
[35] Returning: 2
[36] --28471-- vg_pop_signal_frame (thread 1): valid magic
[37] --28471-- vg_pop_signal_frame (thread 1): valid magic
... Skipping ...
As far as I understand, signals in lines #2, #22 and #30 should be
discarded.
I use Linux 2.4.13, gcc 2.95.3, libc 2.2.4, valgrind 1.9.6.
Note: signal 29 (SIGIO: I/O now possible) is non-POSIX, it comes from 4.2
BSD.
The example program was compiled with 'gcc -Wall signals.c'. You may want
to
change the MOUSE_DEVICE define at the beginning of the file if your mouse is
not in '/dev/mouse'. To test the program: run it and move the mouse, type
Ctrl-C to quit.
Thank you
--
Annie Testes
|
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-13 15:48:03
|
> Yes, that is a problem with such patches, unfortunately. Would it be accepted (or considered, at least) with configure checks to only compile in this code (and include the files) if the include files are actually found on the target system (eg, if the files aren't there, then the new ioctls aren't supported, but they are if the files are found) ? -- Vincent Penquerc'h |
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 16:07:51
|
On Wed, 13 Aug 2003, Vincent Penquerc'h wrote: > > Yes, that is a problem with such patches, unfortunately. > > Would it be accepted (or considered, at least) with configure > checks to only compile in this code (and include the files) if the > include files are actually found on the target system (eg, if the > files aren't there, then the new ioctls aren't supported, but they > are if the files are found) ? Um... maybe. (I'll let Julian have the final say on this one.) N |
|
From: Yardumian, H. (H. (hrant) <hr...@ch...> - 2005-01-12 21:51:41
|
Here is the Valgrind command line ... libtool --mode=3Dexecute '/data/intersect/users/liko/valgrind-2.2.0/bin/valgrind = --error-limit=3Dno --leak-check=3Dno -v --skin=3Dmemcheck --logfile=3DVALGRIND = --num-callers=3D25 --show-reachable=3Dyes' simulator_test_simulator_test_main.exe=20 It's version 2.2 Thanks ! Hrant Yardumian ChevronTexaco - ETC Reservoir Simulation Research - INTERSECT Team 4800 Fournace Pl., Rm E-561 Bellaire, TX 77401-2324 Tel : (713) 432-2816 =20 Mobile : (281) 782-8669 Fax : (713) 432-6620 -----Original Message----- From: Chris Shoemaker [mailto:c.s...@co...]=20 Sent: Wednesday, January 12, 2005 2:24 PM To: Yardumian, Hrant (HEYA) (hrant) Cc: val...@li...; Lim, Kok-Thye (KLim); Verma, Ajay Subject: Re: [Valgrind-users] (no subject) On Wed, Jan 12, 2005 at 12:49:23PM -0600, Yardumian, Hrant (HEYA) (hrant) wrote: >=20 > I am trying to use Valgrind on an executable that's built with the -g=20 > option, yet Valgrind complains that it cannot load the debug info and=20 > symbols. (see sample output below.) >=20 > As a result, Valgrind output will not give me exact locations of=20 > problems. >=20 > Are there any settings other than -g that I need when building my=20 > executable? >=20 > Thanks - >=20 You should show the command line used to execute valgrind. What version are you using? =20 >=20 >=20 > =3D=3D30298=3D=3D Reading syms from=20 > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_tes > t/ > simulator_test/simulator_test_simulator_test_main.exe (0x8048000) > =3D=3D30298=3D=3D warning: mmap failed on Why is the mmap failing? > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_tes > t/ > simulator_test/simulator_test_simulator_test_main.exe > =3D=3D30298=3D=3D no symbols or debug info loaded > =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0x1B8E4000) > =3D=3D30298=3D=3D object doesn't have any debug info > =3D=3D30298=3D=3D Reading syms from > /.automount/izu/vol/vol0/rpo_rpp_q1/intersect/users/liko/valgrind-2.2.0/ > lib/valgrind/stage2 (0xB0000000) > =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0xB1000000) > =3D=3D30298=3D=3D object doesn't have any debug info > =3D=3D30298=3D=3D Reading syms from /lib/libdl-2.2.5.so (0xB1031000) > =3D=3D30298=3D=3D object doesn't have any debug info > =3D=3D30298=3D=3D Reading syms from /lib/i686/libc-2.2.5.so = (0xB1035000) > =3D=3D30298=3D=3D object doesn't have any debug info >=20 > Hrant Yardumian > ChevronTexaco - ETC > Reservoir Simulation Research - INTERSECT Team > 4800 Fournace Pl., Rm E-561 > Bellaire, TX 77401-2324 >=20 > Tel : (713) 432-2816 =20 > Mobile : (281) 782-8669 > Fax : (713) 432-6620 >=20 |
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 09:36:35
|
On Wed, 13 Aug 2003, Vincent Penquerc'h wrote: > From the traffic on the list, it seems this patch suffers from > the same flaw as another one that stayed unapplied: addition of > include files which may or may not be present on the tgarget > system. Am I right in assuming this is the reason the patch was > not applied ? A quick answer would be nice, time permitting. Yes, that is a problem with such patches, unfortunately. N |