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
>
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 i
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, truss has to be killed off
with SIGKILL.
Here is
As Conrad has pointed out, it's an explicit PID. The test completes
successfully when not run under truss -f.
On Fri, Sep 13, 2019 at 2:37 PM Mark Johnston wrote:
>
> On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> > This gets me a little further but now the
On Fri, Sep 13, 2019 at 11:37 AM Mark Johnston wrote:
>
> On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> > This gets me a little further but now the wait4 call by the parent
> > never reaps the child and instead blocks forever:
>
> Does it perform a wildcarded wait(), or does it exp
On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote:
> This gets me a little further but now the wait4 call by the parent
> never reaps the child and instead blocks forever:
Does it perform a wildcarded wait(), or does it explicitly specify the
PID of the child? By design, the former will
This gets me a little further but now the wait4 call by the parent
never reaps the child and instead blocks forever:
# truss -f ./pdfork -p
706: mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34361
970688 (0x800221000)
706: issetugid() = 0 (0x0
s a wait4() on the
> child pid. This works fine under normal conditions, but if the parent
> is run under truss -f, the three processes deadlock. If I switch out
> pdfork() for fork(), the deadlock does not occur.
>
> This C file demonstrates the issue:
>
> https://people.fr
I've hit an issue with a simple use of pdfork(). I have a process
that calls pdfork() and the parent immediately does a wait4() on the
child pid. This works fine under normal conditions, but if the parent
is run under truss -f, the three processes deadlock. If I switch out
pdfork() for
[I re-established the crotchet-build based failure context finally.
Unfortunately truss just dies in a new place.]
On 2016-Oct-28, at 7:29 AM, John Baldwin wrote:
> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
>> [The following has been reported in:
>> https://b
13778 .]
>>>
>>> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying
>>> to track things down I ran into truss getting a SIGSEGV when it tries to
>>> handle the situation. . .
>>>
>>> In truss's enter_syscall
cc1 got some SIGSYS examples. In trying
>> to track things down I ran into truss getting a SIGSEGV when it tries to
>> handle the situation. . .
>>
>> In truss's enter_syscall there is (from a live gdb on truss, after the
>> segmentation fault):
>>
&g
On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
> [The following has been reported in:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
>
> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying
> to track things down I ran
[The following has been reported in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying to
track things down I ran into truss getting a SIGSEGV when it tries to handle
the situation. . .
In tr
[The following has been reported in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying to
track things down I ran into truss getting a SIGSEGV when it tries to handle
the situation. . .
In tr
On Wed, Jul 31, 2013 at 11:24:31AM -0700, Yuri wrote:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=180976
I've committed a modified version of the patch as r253850. Thanks!
-Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mail
http://www.freebsd.org/cgi/query-pr.cgi?pr=180976
Thank you,
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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
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)
>>
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.co
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,
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 paren
. Unfortunately,
truss
MG>> does not check this.
AY> ktrace -i for truss sleep 5
AY> http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after
execve() and wait4() in parent (which was actually waiting for thi
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/
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
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: N
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 pr
-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
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) =
34366
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 __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0)
3162 trussSCTL "kern.proc.sv_name.3163
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:
> >
> > [...]
&
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,0x
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
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0
>
> When you run a command in truss which calls ioctls on TTYs, it just
> locks up. This is because truss runs jobs in a separate process group.
> This also means you cannot send signals to it:
>
> truss sleep 1
>
> Pressing ^C here won't work.
>
> I&#
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 truss which calls ioctls on TTYs, it just
locks up. Th
Hello,
While running the next commands on the attached program I get a panic
everytime.
gcc rfk-smtpd.c
truss ./a.out cat
--panic--
Running 5.1-CURRENT from today. I did a 'make world' in a clean /usr/obj
dir.
System P-II 400Mhz UP, 256 MB, IDE, no acpi enabled.
I hope somebody
I don't believe I've seen any reports of this particular lock order
reversal. I got it by pointing truss at syslogd. My kernel and world
were built from a cvsup run slightly before Fri Nov 7 14:50:18 PST
2003.
Sleeping on "stopevent" with the following non-sleepable l
All,
I found current truss behaviour a bit strange. It coredumps always if
trussed process do without any significant reason for my understanding.
I also confused with comment for commit originally introduced this
functionality
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/truss
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 th
While experimenting with the new libpthread, I found that if you run
`truss' on a KSE process, both truss and its victim get into a weird
state and don't respond to TERM, INT or QUIT signals. The truss proc
dies if you send it the KILL signal, but the victim process cannot be
killed
On Sat, Aug 31, 2002 at 05:45:26PM +0200, Anders Nordby wrote:
> # truss -p `sockstat -l | egrep 'sshd.*tcp4' | awk '{print $3}'`
>
> Log into the system with sshd, and truss will segfault:
There is an even easier way to reproduce this:
gonzo 9% sleep 10 &
[
>Submitter-Id: current-users
>Originator:Anders Nordby <[EMAIL PROTECTED]>
>Organization:
>Confidential: no
>Synopsis: Truss segfaults when tracing sshd
>Severity: serious
>Priority: medium
>Category: bin
>Class: sw-bug
&g
t; > mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c
> > echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend
> > ===> usr.bin/truss
> > cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master
> > /bin/sh /usr/src/usr.bin
bin/truncate
> rm -f .depend
> mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c
> echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend
> ===> usr.bin/truss
> cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master
> /bin/sh /usr/src/u
s what happened ?
>
> The error is:
>
> ===> usr.bin/truncate
> rm -f .depend
> mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c
> echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend
> ===> usr.bin/truss
> cp /usr/src/usr.bin/truss/../..
ed to them but no change.
Any ideas as what happened ?
The error is:
===> usr.bin/truncate
rm -f .depend
mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c
echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend
===> usr.bin/truss
cp /usr/src/usr.bin/tru
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
&g
y disable it :-)
> 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 procfs be pres
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
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 director
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
pro
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 nee
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 mou
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
Greetings,
Richard.
An OS is like swiss cheese, the bigger it is, the more holes you get!
To
On Sun, Dec 09, 2001 at 01:38:03AM +0100, Dag-Erling Smorgrav wrote:
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > des 2001/12/08 16:35:30 PST
> >
> > Modified files:
> > sys/fs/procfsprocfs.c procfs_ioctl.c
> > Log:
> > Fix various bugs in the debugging code an
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> des 2001/12/08 16:35:30 PST
>
> Modified files:
> sys/fs/procfsprocfs.c procfs_ioctl.c
> Log:
> Fix various bugs in the debugging code and reenable it.
>
> Revision ChangesPath
> 1.3 +0 -2 src/sys/
* Bruce Evans <[EMAIL PROTECTED]> [011204 13:43] wrote:
> On 4 Dec 2001, Dag-Erling Smorgrav wrote:
>
> > Bruce Evans <[EMAIL PROTECTED]> writes:
> > > Please only commit working code.
> >
> > Tell that to the author of truss(1) (who also wrote procf
On 4 Dec 2001, Dag-Erling Smorgrav wrote:
> Bruce Evans <[EMAIL PROTECTED]> writes:
> > Please only commit working code.
>
> Tell that to the author of truss(1) (who also wrote procfs(5) in the
> first place).
It used to work. Did it not work when it was first commi
Bruce Evans <[EMAIL PROTECTED]> writes:
> Please only commit working code.
Tell that to the author of truss(1) (who also wrote procfs(5) in the
first place).
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-c
On 4 Dec 2001, Dag-Erling Smorgrav wrote:
> I'm about to commit patches to procfs(5) that will (unfortunately)
> temporarily disable truss(1), until I finish extending ptrace(2) and
> rewriting truss(1) to use that instead of procfs(5) (or find a quiet
> moment to figure
I'm about to commit patches to procfs(5) that will (unfortunately)
temporarily disable truss(1), until I finish extending ptrace(2) and
rewriting truss(1) to use that instead of procfs(5) (or find a quiet
moment to figure out why my legacy support code doesn't work). Until
then, us
Hi,
Since I've moved to -CURRENT a few weeks ago [I'm fairly new to FreeBSD] I
had build problems with kdump and truss.
The problem I report here are as far as I can judge them, sorry for any
errors or inconsistencies. I've tried to find something about an earlier
bug report but
I did a cvsup on 01/01/2000, and then did a buildworld. It failed
in kdump and truss in /usr/src/usr.bin. Thinking the problem was
the "make" picking up the wrong include file, I redid the build
once I did a make installworld with the latest build (less kdump
and tru
73 matches
Mail list logo
