You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(15) |
2
(13) |
3
(16) |
4
(12) |
5
(17) |
|
6
(16) |
7
(13) |
8
(15) |
9
(15) |
10
(18) |
11
(5) |
12
(17) |
|
13
(13) |
14
(13) |
15
(5) |
16
(13) |
17
(2) |
18
(19) |
19
(12) |
|
20
|
21
(22) |
22
(23) |
23
(23) |
24
(23) |
25
(20) |
26
(19) |
|
27
(33) |
28
(20) |
29
(15) |
30
(21) |
31
(20) |
|
|
|
From: Christian B. <bor...@de...> - 2012-05-27 02:19:18
|
valgrind revision: 12586 VEX revision: 2352 C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.20.0.20100122-0.7.9 C library: GNU C Library stable release version 2.11.1 (20100118) uname -mrs: Linux 2.6.32.54-0.3-default s390x Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP1 (s390x) - Kernel %r (%t). Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2012-05-27 03:45:01 CEST Ended at 2012-05-27 04:19:04 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 536 tests, 4 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) |
|
From: Tom H. <to...@co...> - 2012-05-27 02:15:18
|
valgrind revision: 12586 VEX revision: 2352 C compiler: gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5) Assembler: GNU assembler version 2.22.52.0.1-10.fc17 20120131 C library: GNU C Library stable release version 2.15 uname -mrs: Linux 3.3.4-5.fc17.x86_64 x86_64 Vendor version: Fedora release 17 (Beefy Miracle) Nightly build on bristol ( x86_64, Fedora 17 (Beefy Miracle) ) Started at 2012-05-27 02:43:28 BST Ended at 2012-05-27 03:15:00 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 618 tests, 9 stderr failures, 1 stdout failure, 1 stderrB failure, 2 stdoutB failures, 0 post failures == gdbserver_tests/mcinfcallWSRU (stderr) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcmain_pic (stderr) gdbserver_tests/nlcontrolc (stdoutB) gdbserver_tests/nlpasssigalrm (stdoutB) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/overlap (stderr) memcheck/tests/str_tester (stderr) drd/tests/bar_bad (stderr) drd/tests/bar_bad_xml (stderr) drd/tests/pth_cancel_locked (stderr) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) |
|
From: Christian B. <bor...@de...> - 2012-05-27 02:05:44
|
valgrind revision: 12586 VEX revision: 2352 C compiler: gcc (GCC) 4.5.3 20110121 (Red Hat 4.5.3-5) Assembler: GNU assembler version 2.20.51.0.7-4bb6.fc13 20100318 C library: GNU C Library stable release version 2.12.1 uname -mrs: Linux 3.3.4-53.x.20120504-s390xperformance s390x Vendor version: unknown Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2012-05-27 03:45:02 CEST Ended at 2012-05-27 04:05:50 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 535 tests, 8 stderr failures, 0 stdout failures, 1 stderrB failure, 1 stdoutB failure, 0 post failures == gdbserver_tests/mcinvokeWS (stdoutB) gdbserver_tests/mcinvokeWS (stderrB) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/circular_buffer (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc21_pthonce (stderr) |
|
From: Roland M. <rol...@nr...> - 2012-05-27 01:25:00
|
On Sun, May 27, 2012 at 3:21 AM, John Reiser <jr...@bi...> wrote: >> A shorter testcase (based on Dan's feedback) is this: >> -- snip -- >> $ valgrind /usr/bin/getconf PIPE_BUF / >> <valgrind throws tactical nuke back... =:-) > >> -- snip -- > > That works for me using both valgrind-3.5.0 (Fedora 4, glibc-2.13-2) > and valgrind-3.7.0 (Fedora 17, glibc-2.15-37). > > Using valgrind-3.6.1 (Fedora 16, glibc-2.14-90): > valgrind --trace-syscalls=yes /usr/bin/getconf PIPE_BUF / > the culprit is: > ----- > SYSCALL[12634,1]( 72) sys_fcntl[UNKNOWN] ( 3, 1032, -718144 ) > valgrind: m_syswrap/syswrap-linux.c:3660 (vgSysWrap_linux_sys_fcntl_before): Assertion 'Unimplemented functionality' failed. > valgrind: valgrind > ==12634== at 0x3804ACB6: report_and_quit (m_libcassert.c:209) > ----- > So valgrind's problem is triggered by an oddity of glibc-2.14-90. Mhhh... Dan and I have updated our test machines to valgrind 3.7.0... since then this problem disappeared... which means: DDNTSHF[1]-error. Sorry for the late-night rampage... ;-/ [1]="dumb developer not testing svn head first" ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: John R. <jr...@bi...> - 2012-05-27 01:20:14
|
> A shorter testcase (based on Dan's feedback) is this: > -- snip -- > $ valgrind /usr/bin/getconf PIPE_BUF / > <valgrind throws tactical nuke back... =:-) > > -- snip -- That works for me using both valgrind-3.5.0 (Fedora 4, glibc-2.13-2) and valgrind-3.7.0 (Fedora 17, glibc-2.15-37). Using valgrind-3.6.1 (Fedora 16, glibc-2.14-90): valgrind --trace-syscalls=yes /usr/bin/getconf PIPE_BUF / the culprit is: ----- SYSCALL[12634,1]( 72) sys_fcntl[UNKNOWN] ( 3, 1032, -718144 ) valgrind: m_syswrap/syswrap-linux.c:3660 (vgSysWrap_linux_sys_fcntl_before): Assertion 'Unimplemented functionality' failed. valgrind: valgrind ==12634== at 0x3804ACB6: report_and_quit (m_libcassert.c:209) ----- So valgrind's problem is triggered by an oddity of glibc-2.14-90. -- |
|
From: Roland M. <rol...@nr...> - 2012-05-27 00:56:53
|
On Sun, May 27, 2012 at 1:29 AM, Philippe Waroquiers
<phi...@sk...> wrote:
> On Sun, 2012-05-27 at 01:20 +0200, Dan Shelton wrote:
>> Is there a way to set the fd number used by the --log-file number?
>> We've encountered serious trouble when we test the bash/dash/ksh
>> family of shells with valgrind, sometimes testing fails because there
>> are fds used by valgrind which are considered free by the shell.
> I understand that Valgrind should properly indicate to bash/dash/ksh
> the fd range which is usable.
>
> Valgrind reserves a part of the fd range for its own use.
> This reserved part should not be visible to the client
> (i.e. valgrind ensures that the syscall getrlimit
> returns a range not including the reserved for Valgrind).
>
> How is bash/... guessing that they can use such
> a reserved fd ?
To clarify Dan's issue (we're sitting together and hunt down some shell bugs):
We see weired test suite failures in ksh93's test suite like these ones:
-- snip --
test io begins at 2012-05-27+02:35:39
io.sh[119]: picked up file descriptor zero for opening script file
io.sh[128]: multiple exec 4< /dev/null can fail
io.sh[193]: parent i/o causes child script to fail
io.sh[204]: trap on EXIT loses last command redirection
io.sh[284]: closed standard output not passed to subshell
-- snip --
These tests used fixed fd numbers (0-6) and "dynamically allocated"
("dynamically" means ksh93 has a syntax to allocate a free fd for a
scripts usage, e.g. by using $ integer n ; exec
{n}</dev/by/path/chutulluh # ; shell variable "n" then contains the fd
number) by the shell (by default anything >=10, for the tests listed
above it's 10-15).
Is it possible somehow that this crosses any paths with valgrind's fd
usage (I'm more or less sure that the ksh93/libast code involved is
correct... at least Rational Purify and Sun Studio's "dbx -check
access" report no issues (but valgrind shows it's teeth)) ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rol...@nr...
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
|
|
From: Roland M. <rol...@nr...> - 2012-05-27 00:19:25
|
On Sun, May 27, 2012 at 2:08 AM, Roland Mainz <rol...@nr...> wrote: > Does anyone know why valgrind goes berserk on such a simple shell > builtin like ulimit? > > I tried a simple, plain, innocent ulimit -a within ksh (ksh93 from > 20120504) and got this reply: > ======================= > valgrind ~/bin/ksh -c 'ulimit -a' > ==29376== Memcheck, a memory error detector > ==29376== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. > ==29376== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info > ==29376== Command: /home/danny/bin/ksh -c ulimit\ -a > ==29376== > > valgrind: m_syswrap/syswrap-linux.c:3655 > (vgSysWrap_linux_sys_fcntl_before): Assertion 'Unimplemented > functionality' failed. > valgrind: valgrind > ==29376== at 0x3804CF26: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) > ==29376== by 0x3804D0CC: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) > ==29376== by 0x380A8D8A: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) > ==29376== by 0x380881A7: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) > ==29376== by 0x3808501C: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) > ==29376== by 0x380861C9: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) > ==29376== by 0x38095C54: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable > ==29376== at 0x53586B8: do_fcntl (in /lib64/libc-2.14.1.so) > ==29376== by 0x5358837: fcntl (in /lib64/libc-2.14.1.so) > ==29376== by 0x5336724: pathconf (in /lib64/libc-2.14.1.so) > ==29376== by 0x551D7C: print (astconf.c:1115) > ==29376== by 0x553024: astgetconf (astconf.c:1477) > ==29376== by 0x553654: astconf (astconf.c:1555) > ==29376== by 0x4A9B41: b_ulimit (ulimit.c:201) > ==29376== by 0x4815B6: sh_exec (xec.c:1367) > ==29376== by 0x418956: exfile (main.c:600) > ==29376== by 0x417B40: sh_main (main.c:373) > ==29376== by 0x416C28: main (pmain.c:45) > > > Note: see also the FAQ in the source distribution. > It contains workarounds to several common problems. > In particular, if Valgrind aborted or crashed after > identifying problems in your program, there's a good chance > that fixing those problems will prevent Valgrind aborting or > crashing, especially if it happened in m_mallocfree.c. > > If that doesn't help, please report this bug to: www.valgrind.org > > In the bug report, send all the above text, the valgrind > version, and what OS and version you are using. Thanks. > ======================= > > Without valgrind the call to ulimit -a worked as I would expect it: > ======================= > ksh -c 'ulimit -a' > address space limit (kbytes) (-M) unlimited > core file size (blocks) (-c) unlimited > cpu time (seconds) (-t) unlimited > data size (kbytes) (-d) unlimited > file size (blocks) (-f) unlimited > locks (-x) unlimited > locked address space (kbytes) (-l) 64 > message queue size (kbytes) (-q) 800 > nice (-e) 0 > nofile (-n) 1024 > nproc (-u) 5796 > pipe buffer size (bytes) (-p) 4096 > max memory size (kbytes) (-m) unlimited > rtprio (-r) 0 > socket buffer size (bytes) (-b) 4096 > sigpend (-i) 5796 > stack size (kbytes) (-s) 8192 > swap size (kbytes) (-w) not supported > threads (-T) not supported > process size (kbytes) (-v) unlimited > ======================= Grumpf... it's "ulimit -p" which causes this trouble (it uses |pathconf()| to find the pipe buffer size): -- snip -- #0 0x00007ffff769c630 in pathconf () from /lib64/libc.so.6 #1 0x0000000000551d7d in print (sp=0x0, look=0x7fffffffd6b0, name=0x586512 "PIPE_BUF", path=0x7f35c8 "/", listflags=0, conferror=0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/lib/libast/port/astconf.c:1115 #2 0x0000000000553025 in astgetconf (name=0x586512 "PIPE_BUF", path=0x7f35c8 "/", value=0x0, flags=0, conferror=0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/lib/libast/port/astconf.c:1477 #3 0x0000000000553655 in astconf (name=0x586512 "PIPE_BUF", path=0x0, value=0x0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/lib/libast/port/astconf.c:1555 #4 0x00000000004a9b42 in b_ulimit (argc=2, argv=0x7ffff7fb0690, context=0x7f4a08) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/bltins/ulimit.c:201 #5 0x00000000004815b7 in sh_exec (t=0x7ffff7fb0610, flags=5) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/xec.c:1367 #6 0x0000000000418957 in exfile (shp=0x7f4500, iop=0x7ffff7fcb100, fno=-1) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/main.c:600 #7 0x0000000000417b41 in sh_main (ac=3, av=0x7fffffffe238, userinit=0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/main.c:373 #8 0x0000000000416c29 in main (argc=3, argv=0x7fffffffe238) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/pmain.c:45 (gdb) cont Continuing. Breakpoint 1, 0x00007ffff769c630 in pathconf () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff769c630 in pathconf () from /lib64/libc.so.6 #1 0x0000000000551d7d in print (sp=0x0, look=0x7fffffffd6b0, name=0x586512 "PIPE_BUF", path=0x7f35c8 "/", listflags=0, conferror=0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/lib/libast/port/astconf.c:1115 #2 0x0000000000553025 in astgetconf (name=0x586512 "PIPE_BUF", path=0x7f35c8 "/", value=0x0, flags=0, conferror=0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/lib/libast/port/astconf.c:1477 #3 0x0000000000553655 in astconf (name=0x586512 "PIPE_BUF", path=0x0, value=0x0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/lib/libast/port/astconf.c:1555 #4 0x00000000004a9b42 in b_ulimit (argc=2, argv=0x7ffff7fb0690, context=0x7f4a08) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/bltins/ulimit.c:201 #5 0x00000000004815b7 in sh_exec (t=0x7ffff7fb0610, flags=5) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/xec.c:1367 #6 0x0000000000418957 in exfile (shp=0x7f4500, iop=0x7ffff7fcb100, fno=-1) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/main.c:600 #7 0x0000000000417b41 in sh_main (ac=3, av=0x7fffffffe238, userinit=0) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/main.c:373 #8 0x0000000000416c29 in main (argc=3, argv=0x7fffffffe238) at /home/test001/work/ast_ksh_20120518/build_normal_64bit_mamfilefix/src/cmd/ksh93/sh/pmain.c:45 -- snip -- A shorter testcase (based on Dan's feedback) is this: -- snip -- $ valgrind /usr/bin/getconf PIPE_BUF / <valgrind throws tactical nuke back... =:-) > -- snip -- ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Roland M. <rol...@nr...> - 2012-05-27 00:08:36
|
Does anyone know why valgrind goes berserk on such a simple shell builtin like ulimit? I tried a simple, plain, innocent ulimit -a within ksh (ksh93 from 20120504) and got this reply: ======================= valgrind ~/bin/ksh -c 'ulimit -a' ==29376== Memcheck, a memory error detector ==29376== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==29376== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==29376== Command: /home/danny/bin/ksh -c ulimit\ -a ==29376== valgrind: m_syswrap/syswrap-linux.c:3655 (vgSysWrap_linux_sys_fcntl_before): Assertion 'Unimplemented functionality' failed. valgrind: valgrind ==29376== at 0x3804CF26: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==29376== by 0x3804D0CC: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==29376== by 0x380A8D8A: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==29376== by 0x380881A7: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==29376== by 0x3808501C: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==29376== by 0x380861C9: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==29376== by 0x38095C54: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==29376== at 0x53586B8: do_fcntl (in /lib64/libc-2.14.1.so) ==29376== by 0x5358837: fcntl (in /lib64/libc-2.14.1.so) ==29376== by 0x5336724: pathconf (in /lib64/libc-2.14.1.so) ==29376== by 0x551D7C: print (astconf.c:1115) ==29376== by 0x553024: astgetconf (astconf.c:1477) ==29376== by 0x553654: astconf (astconf.c:1555) ==29376== by 0x4A9B41: b_ulimit (ulimit.c:201) ==29376== by 0x4815B6: sh_exec (xec.c:1367) ==29376== by 0x418956: exfile (main.c:600) ==29376== by 0x417B40: sh_main (main.c:373) ==29376== by 0x416C28: main (pmain.c:45) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. ======================= Without valgrind the call to ulimit -a worked as I would expect it: ======================= ksh -c 'ulimit -a' address space limit (kbytes) (-M) unlimited core file size (blocks) (-c) unlimited cpu time (seconds) (-t) unlimited data size (kbytes) (-d) unlimited file size (blocks) (-f) unlimited locks (-x) unlimited locked address space (kbytes) (-l) 64 message queue size (kbytes) (-q) 800 nice (-e) 0 nofile (-n) 1024 nproc (-u) 5796 pipe buffer size (bytes) (-p) 4096 max memory size (kbytes) (-m) unlimited rtprio (-r) 0 socket buffer size (bytes) (-b) 4096 sigpend (-i) 5796 stack size (kbytes) (-s) 8192 swap size (kbytes) (-w) not supported threads (-T) not supported process size (kbytes) (-v) unlimited ======================= -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |