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 exit
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 ptrac
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> com
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) {
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
>
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
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
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 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
http://dl.dropbox.com/u/8798217/tmp
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-B
On Sep 9, 2011, at 3:56 PM, Xin LI 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 r22488
-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 Wed, Aug 31, 2011 at 4:35 PM, Anton Yuzhaninov 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) =
34366255104 (0x800637
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
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,0x
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 comm
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 "unsubscr
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 tha
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 fi
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() inter
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 contr
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.
>
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 kld
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 l
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 th
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, 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 vuln
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 t
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, Apr 28, 2002 at 08:11:58PM +0200, Riccardo Torrini wrote:
> On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:
>
> > RA>On a fresh current i get this
> > RA># truss /bin/echo hello
> > RA>truss: cannot open /proc/13245/mem: No such file or directory
> > RA>truss: cannot open /proc/curp
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 d
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 freeb
On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:
> RA>On a fresh current i get this
> RA># truss /bin/echo hello
> RA>truss: cannot open /proc/13245/mem: No such file or directory
> RA>truss: cannot open /proc/curproc/mem: No such file or directory
> You need to mount procfs.
Mee too messa
On Sun, 28 Apr 2002, Richard Arends wrote:
RA>Hello,
RA>
RA>On a fresh current i get this
RA>
RA># truss /bin/echo hello
RA>truss: cannot open /proc/13245/mem: No such file or directory
RA>truss: cannot open /proc/curproc/mem: No such file or directory
You need to mount procfs.
harti
RA>
R
35 matches
Mail list logo