On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.
>
> Mere "timeout 2 sleep 10" correctly times out.
>
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep and the entire thing refuses to
Mateusz Guzik writes:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.
Confirmed on 14.0-RELEASE-p5.
> Mere "timeout 2 sleep 10" correctly times out.
>
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep
This is sort of expected as truss(1) uses
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote:
KB Could you, please, test the change below ? For me, I still can truss(1)
KB or debug with gdb after the change applied. Does truss work for you
KB with only this change, without resetting SIGTRAP handler in truss process ?
KB
KB commit
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote:
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a
On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote:
MG Could you please run ktrace with -i option? The behavior is like if
MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss
MG does not check this.
ktrace -i for truss sleep 5
On Mon, 19 Sep 2011 12:13:56 + (UTC) Anton Yuzhaninov wrote to Mikolaj
Golub:
AY On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote:
MG Could you please run ktrace with -i option? The behavior is like if
MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately,
On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after
MG execve() and wait4() in parent (which was actually waiting for
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop
On Mon, Sep 19, 2011 at 04:03:42PM +, Anton Yuzhaninov wrote:
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG
On Wed, 14 Sep 2011 06:17:45 + (UTC) Anton Yuzhaninov wrote to Xin LI:
AY On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote:
XL -BEGIN PGP SIGNED MESSAGE-
XL Hash: SHA256
XL
XL On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~
On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote:
XL -BEGIN PGP SIGNED MESSAGE-
XL Hash: SHA256
XL
XL On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~ truss /bin/echo x x truss: can not get etype: No such process
FreeBSD 9.0-BETA1 #0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~ truss /bin/echo x x truss: can not get etype: No such process
FreeBSD 9.0-BETA1 #0 r224884M i386
from ktrace of turss
3162 trussCALL
On Sep 9, 2011, at 3:56 PM, Xin LI delp...@delphij.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~ truss /bin/echo x x truss: can not get etype: No such process
FreeBSD 9.0-BETA1 #0
On Wed, Aug 31, 2011 at 4:35 PM, Anton Yuzhaninov cit...@citrin.ru wrote:
It seems to be truss(1) is broken on current
I just tried with a newly build CURRENT, and no problem here.
[solskogen@friend ~]$ truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
In the last episode (Jul 27), Alexander Best said:
hi there,
i was trying to attach truss to chromium via
'truss -p 18445' and got:
[...]
kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
On Wed, Jul 27, 2011 at 11:35:49AM -0500, Dan Nelson wrote:
In the last episode (Jul 27), Alexander Best said:
hi there,
i was trying to attach truss to chromium via
'truss -p 18445' and got:
[...]
kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0
On Monday, October 11, 2010 9:17:19 am Ed Schouten wrote:
Hi all,
I've been seeing this bug for a very long time, but I was too lazy to
figure out the root cause earlier. It is TTY related, but in this case
the TTY layer is not to blame. It does things correctly.
When you run a command in
What is your revision of kern_thread.c? revision 1.58 should fix this problem.
- Original Message -
From: Tim Robbins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 9:06 PM
Subject: truss and KSE
While experimenting with the new libpthread, I found that if
On Thu, Nov 14, 2002 at 05:39:12AM -0800, David Xu wrote:
What is your revision of kern_thread.c? revision 1.58 should fix this problem.
I believe it was 1.57. I'll try with 1.58 and let you know if the problem
is still there.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Sun, 28 Apr 2002, Richard Arends wrote:
RAHello,
RA
RAOn a fresh current i get this
RA
RA# truss /bin/echo hello
RAtruss: cannot open /proc/13245/mem: No such file or directory
RAtruss: cannot open /proc/curproc/mem: No such file or directory
You need to mount procfs.
harti
RA
On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:
RAOn a fresh current i get this
RA# truss /bin/echo hello
RAtruss: cannot open /proc/13245/mem: No such file or directory
RAtruss: cannot open /proc/curproc/mem: No such file or directory
You need to mount procfs.
Mee too message. I
On Sun, 28 Apr 2002, Harti Brandt wrote:
You need to mount procfs.
Oops youre right... Why isn't it listed in /etc/fstab???
Greetings,
Richard.
An OS is like swiss cheese, the bigger it is, the more holes you get!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
On Sun, Apr 28, 2002 at 07:46:27PM +0200, Richard Arends wrote:
Hello,
On a fresh current i get this
# truss /bin/echo hello
truss: cannot open /proc/13245/mem: No such file or directory
truss: cannot open /proc/curproc/mem: No such file or directory
procfs is not mounted by
On Sun, Apr 28, 2002 at 08:11:58PM +0200, Riccardo Torrini wrote:
On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:
RAOn a fresh current i get this
RA# truss /bin/echo hello
RAtruss: cannot open /proc/13245/mem: No such file or directory
RAtruss: cannot open /proc/curproc/mem: No
On Sun, 28 Apr 2002, Kris Kennaway wrote:
procfs is not mounted by default.
New to current (one day old baby :-), so didn't know that. sorry()
Why isn't it mounted by default??
Greetings,
Richard.
An OS is like swiss cheese, the bigger it is, the more holes you get!
To Unsubscribe:
On Sun, 28 Apr 2002, Richard Arends wrote:
On Sun, 28 Apr 2002, Kris Kennaway wrote:
procfs is not mounted by default.
New to current (one day old baby :-), so didn't know that. sorry()
Why isn't it mounted by default??
I believe DES has a largely rewritten version of truss that
On Sun, Apr 28, 2002 at 08:49:55PM +0200, Richard Arends wrote:
On Sun, 28 Apr 2002, Kris Kennaway wrote:
procfs is not mounted by default.
New to current (one day old baby :-), so didn't know that. sorry()
Why isn't it mounted by default??
Numerous and horrendous security
On Sun, 28 Apr 2002, Robert Watson wrote:
The rationale for disabling procfs is that its functionality is largely
redundant to existing sysctls and debugging mechanisms, and that it has
been, and will likely continue to be, an important source of system
security holes.
Okay disable it :-)
On Sun, 28 Apr 2002, Richard Arends wrote:
I think truss is one of the last stragglers that relies on it --
the other is 'ps -e', which gropes through the memory of each process to
dig out the environmental variables. This requires that ps both have
substantial privilege, and that
On Sun, 28 Apr 2002, Robert Watson wrote:
BTW, 5.0 will also allow (once we commit the MAC framework from the
TrustedBSD Project) kernel modules to tweak process visibility protections
in the kernel at runtime. For example, you can kldload a
mac_seeotheruids.ko policy module, which can
On Sun, 28 Apr 2002, Richard Arends wrote:
On Sun, 28 Apr 2002, Robert Watson wrote:
BTW, 5.0 will also allow (once we commit the MAC framework from the
TrustedBSD Project) kernel modules to tweak process visibility protections
in the kernel at runtime. For example, you can kldload a
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In
On Sun, 28 Apr 2002, Crist J. Clark wrote:
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls.
On Sun, Apr 28, 2002 at 05:11:14PM -0400, Robert Watson wrote:
On Sun, 28 Apr 2002, Crist J. Clark wrote:
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which
On Sun, 28 Apr 2002, Crist J. Clark wrote:
Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was
probably thinking of top, which still is setgid in -STABLE. You'll find
however, that -e won't work without setgid kmem being turned on.
'-e' for ps(1) seems to work fine on
35 matches
Mail list logo
