RE: ntpd hangs under FBSD 8
>> make install should be done with DEBUG_FLAGS containing -g too, otherwise >> strip(1) is called on the installed binary. > >Doh, yes. I did not do this; that's likely my problem. Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ntpd hangs under FBSD 8
>I bet ntpd doesn't call select() in all that many places. Instead of going to >all this trouble to build a debugging libc, you could just >grep for select() and place breakpoints on all occurrences. (It might also be >obvious from looking at them which one is the offender.) I just checked--there are five calls to select. I might flag each one with a printf or something and recompile to see which one is the culprit. >Also, since a system call is causing the trouble, you might learn something >from truss or ktrace. I'll check these out... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ntpd hangs under FBSD 8
On Wednesday 24 February 2010 5:09:47 pm Kostik Belousov wrote: > On Wed, Feb 24, 2010 at 03:17:25PM -0500, John Baldwin wrote: > > On Wednesday 24 February 2010 1:17:50 pm Peter Steele wrote: > > > >You're going to need a debug version of libc, too. gdb won't be able to > > find a backtrace out of a libc function without it. > > > > > > What's the proper way to build a debug version of libc and the other > > libraries? I tried this: > > > > You can just do this: > > > > cd /usr/src/lib/libc > > make clean > > make DEBUG_FLAGS=-g > > make install > > make install should be done with DEBUG_FLAGS containing -g too, otherwise > strip(1) is called on the installed binary. Doh, yes. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ntpd hangs under FBSD 8
On Mon, 22 Feb 2010, Peter Steele wrote: Just out of curiosity, can you attach to the process via gdb and get a backtrace? This smells like a locked pthread_join I hit in my own code a few weeks ago I'm not using the debug version of ntpd so the backtrace isn't too useful, but here's what I get: (gdb) bt #0 0x000800d52bfc in select () from /lib/libc.so.7 #1 0x00425273 in ?? () #2 0x0040540e in ?? () #3 0x00080058 in ?? () #4 0x in ?? () I bet ntpd doesn't call select() in all that many places. Instead of going to all this trouble to build a debugging libc, you could just grep for select() and place breakpoints on all occurrences. (It might also be obvious from looking at them which one is the offender.) Also, since a system call is causing the trouble, you might learn something from truss or ktrace. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ntpd hangs under FBSD 8
On Wed, Feb 24, 2010 at 03:17:25PM -0500, John Baldwin wrote: > On Wednesday 24 February 2010 1:17:50 pm Peter Steele wrote: > > >You're going to need a debug version of libc, too. gdb won't be able to > find a backtrace out of a libc function without it. > > > > What's the proper way to build a debug version of libc and the other > libraries? I tried this: > > You can just do this: > > cd /usr/src/lib/libc > make clean > make DEBUG_FLAGS=-g > make install make install should be done with DEBUG_FLAGS containing -g too, otherwise strip(1) is called on the installed binary. pgpTclt7JKHiZ.pgp Description: PGP signature
RE: ntpd hangs under FBSD 8
>> How do I get libc built with full debug symbols? > >I haven't tried it by myself but think here is the way to go: put the >following to /etc/make.conf and recompile needed libraries / ports. >WITH_DEBUG=yes >DEBUG_FLAGS=-g That didn't seem to have any effect. I still see -O2 being used instead of -O0. >Mmm... Do other daemons (sshd, lpd, ...) also fail when started through this >script? Normal commands (ls, ps) seem not affected. I tried a few other things and they all seemed to run correctly. We use this same general approach in the full version of this script to launch lots of applications. Its role in fact is a process launcher/monitor. I stripped it down to the bare minimum in order to isolate the cause of the problem. It seems that only ntpd hangs, but not if I use Python 2.5.1. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ntpd hangs under FBSD 8
>> What's the proper way to build a debug version of libc and the other >> libraries? I tried this: > >You can just do this: > >cd /usr/src/lib/libc >make clean >make DEBUG_FLAGS=-g >make install When I tried this the make actually failed with various errors. So I decided to do a full "make buildworld DEBUG_FLAGS=-g" but in looking at the output being generated I see see -O2 in the cc commands and this at least should be -O0. It doesn't look like the DEBUG_FLAGS is having any effect. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ntpd hangs under FBSD 8
On Wednesday 24 February 2010 1:17:50 pm Peter Steele wrote: > >You're going to need a debug version of libc, too. gdb won't be able to find a backtrace out of a libc function without it. > > What's the proper way to build a debug version of libc and the other libraries? I tried this: You can just do this: cd /usr/src/lib/libc make clean make DEBUG_FLAGS=-g make install -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[Fwd: odd nfs behaviour]
--- Begin Message --- I have home dir's nfs mounted via amd on the jack the following error occurred on (I do not have NIS I do uid/gid syncing manually): ~/master.C091 ar...@kate% telnet jack Trying 72.89.191.146... Connected to jack.istudentunion.com. Escape character is '^]'. Trying SRA secure login: User (aryeh): aryeh Password: [ SRA accepts you ] FreeBSD/i386 (jack.istudentunion.com) (pts/0) nfs server pi...@jack:/host: not responding nfs server pi...@jack:/host: not responding nfs server pi...@jack:/host: not responding nfs server pi...@jack:/host: not responding nfs server pi...@jack:/host: not responding nfs server pi...@jack:/host: not responding NFS Server: FreeBSD kate.istudentunion.com 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 9 21:30:43 UTC 2009 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 NFS Client: FreeBSD jack.istudentunion.com 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Jan 7 02:15:16 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC i386 --- End Message --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 2 bytes allocated problems
Andrey Zonov writes:
> Dag-Erling Smørgrav writes:
> > Pointers have no boundareis in C.
> And how free() finds that the need to release?
That is a very simple question with a very complicated answer. Whole
books have been written about the subject. Normally, I'd say "look it
up on Wikipedia", but the Wikipedia article on dynamic memory allocation
is little more than a stub. Try Knuth's The Art of Computer Programming
instead.
However, none of this changes the fact that pointers in C have no
boundaries. In practical terms, a pointer is just a number that
refers to a particular location in memory.
If you do
char *p = malloc(10);
strcpy(p, "abcdefghi")
p += 5;
then *p == p[0] == 'f', and if printf("%s", p) will print "fghi". What
happens if you then try to free(p) will vary from OS to OS and sometimes
between versions of the same OS; in most cases, either nothing will
happen at all, or your program will crash.
The reason printf() knows to stop after the 'i' is that the next char in
memory is 0. That's why your program didn't work: there was no 0 there
to indicate the end of the string. Sometimes it would seem to work
because there would, by coincidence, be a 0 there already, but that
doesn't mean your code is correct.
Why is there a 0 after the 'i'? Because when you write "abcdefghi", the
compiler actually stores "abcdefghi\0". That's the definition of
"string" in C: a sequence of characters immediately followed by a 0. If
you don't want the 0 there, you have to do something like this:
char a[9] = { 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i' };
but then you don't have a string, just an array of 9 chars.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 2 bytes allocated problems
And how free() finds that the need to release? Dag-Erling Smørgrav пишет: Andrey Zonov writes: When I try allocated pointer to a pointer, and in it some pointers (important: size is 2 bytes), the pointers lose their boundaries. Pointers have no boundareis in C. PS in freebsd < 7, it's ok, in Linux too. Only by accident. DES ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ntpd hangs under FBSD 8
On Wed, Feb 24, 2010 at 12:17:50PM -0600, Peter Steele wrote:
> >You're going to need a debug version of libc, too.
> >gdb won't be able to find a backtrace out of a libc function without it.
>
> What's the proper way to build a debug version of libc and the other
> libraries? I tried this:
>
> export CFLAGS="-O0"
> make buildworld
> make installworld DESTDIR=/mydir
>
> and then copied libc.so.7 from /mydir/lib to the /lib dir on
> my target system. I also replaced the ntpd binary with the debug version.
> I can see that -O0 is being used in the various "cc" commands that are
> generated, but libc still doesn't seem to be built properly.
> When I attach to a hung ntpd process, I get this:
>
> # gdb /usr/sbin/ntpd -p 2113
> GNU gdb 6.1.1 [FreeBSD]
> ...
> Attaching to program: /usr/sbin/ntpd, process 2113
> Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
> ...
> Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
> ...
> [Switching to Thread 8012041c0 (LWP 100283)]
> 0x000800dbeddc in select () from /lib/libc.so.7
> (gdb) bt
> #0 0x000800dbeddc in select () from /lib/libc.so.7
> #1 0x004335de in ntpdmain ()
> #2 0x0043310b in main ()
>
> So I'm getting some symbols from ntpd but I still can't see into select().
>
I think not.
> It hangs in there forever so that's where I need to drill down further.
> How do I get libc built with full debug symbols?
>
I haven't tried it by myself but think here is the way to go: put the
following to /etc/make.conf and recompile needed libraries / ports.
WITH_DEBUG=yes
DEBUG_FLAGS=-g
This should do the trick for both base and ports.
>
> [snip]
>
> If anyone has any clues at all as to what is causing this issue,
> I'd appreciate the feedback. Here's the code that reproduces this behavior.
>
> #! /usr/bin/env python
> import os
> import threading
>
> class RunProc(threading.Thread):
> def __init__(self, cmd):
> threading.Thread.__init__(self)
> self.cmd = cmd
>
> def run(self):
> os.system(self.cmd)
>
> def main():
> RunProc("/usr/sbin/ntpd -g -q").start()
>
> if __name__ == "__main__":
> main()
>
Mmm... Do other daemons (sshd, lpd, ...) also fail when started
through this script? Normal commands (ls, ps) seem not affected.
0.02$,
Alexey.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ntpd hangs under FBSD 8
>You're going to need a debug version of libc, too. gdb won't be able to find
>a backtrace out of a libc function without it.
What's the proper way to build a debug version of libc and the other libraries?
I tried this:
export CFLAGS="-O0"
make buildworld
make installworld DESTDIR=/mydir
and then copied libc.so.7 from /mydir/lib to the /lib dir on my target system.
I also replaced the ntpd binary with the debug version. I can see that -O0 is
being used in the various "cc" commands that are generated, but libc still
doesn't seem to be built properly. When I attach to a hung ntpd process, I get
this:
# gdb /usr/sbin/ntpd -p 2113
GNU gdb 6.1.1 [FreeBSD]
...
Attaching to program: /usr/sbin/ntpd, process 2113
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
...
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
...
[Switching to Thread 8012041c0 (LWP 100283)]
0x000800dbeddc in select () from /lib/libc.so.7
(gdb) bt
#0 0x000800dbeddc in select () from /lib/libc.so.7
#1 0x004335de in ntpdmain ()
#2 0x0043310b in main ()
So I'm getting some symbols from ntpd but I still can't see into select(). It
hangs in there forever so that's where I need to drill down further. How do I
get libc built with full debug symbols?
In other testing I've narrowed the problem down to some kind of Python issue.
If I run the Python code at the end of this email where "ntpd -g -q" is
launched as part of a Python thread class, the command hangs (the code assumes
that ntpd is not already running). If I run the same ntpd command in a normal
function (e.g. main) no hang occurs. I've tried subcommand.Popen and os.spawnv
to run ntpd and these calls behave exactly the same way--when called from a
thread the ntpd process hangs but it works fine when called from outside of a
thread. This is a breakdown of course of our larger project into a simple test
app. In our real code we cannot so easily eliminate this thread wrapper.
The same code BTW works fine on our FreeBSD 7 boxes, the main difference being
we are running an older version of Python on those boxes (2.5.1 instead of
2.6.2). I tried installing the same 2.5.1 package on a FBSD 8 box and that
solved the problem. Curiously a slightly newer FBSD 7 version of Python, 2.5.5,
causes the same hang to occur. So only Python 2.5.1 built under FreeBSD 7 works
to get around this issue with ntpd on FreeBSD 8. That means one potential
solution is to downgrade to this 2.5.1, but we have other libraries targeted to
work with Python 2.6 and we don't really want to downgrade all these associated
libraries.
If anyone has any clues at all as to what is causing this issue, I'd appreciate
the feedback. Here's the code that reproduces this behavior.
#! /usr/bin/env python
import os
import threading
class RunProc(threading.Thread):
def __init__(self, cmd):
threading.Thread.__init__(self)
self.cmd = cmd
def run(self):
os.system(self.cmd)
def main():
RunProc("/usr/sbin/ntpd -g -q").start()
if __name__ == "__main__":
main()
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: VirtualBox and vtophys
On Wed, Feb 24, 2010 at 09:43:20AM -0500, John Baldwin wrote: > On Wednesday 24 February 2010 6:41:31 am Jacques Fourie wrote: > > I've noticed that my virtualbox vboxdrv.ko started crashing after > > updating my 8.0-stable install. The crash occurs when vboxdrv calls > > vtophys() on a userland virtual address. Prior to r202894 this was > > working fine. Modifying pmap_kextract() to use vtopte() for non-kernel > > virtual adresses fixes the problem. Is it intended for vtophys() to > > still work on userland virtual addresses? > > Use pmap_extract(pmap, ...) for user addresses. Granted, that is only > reliable if the user pages have been wired in some fashion. The reference code is in sys/dev/cxgb/ulp/tom/cxgb_vm.c:vm_fault_hold_user_pages(), it holds and returns the page that was mapped at the moment of the call at the specified address. pgptv7dsBFZXu.pgp Description: PGP signature
Re: 2 bytes allocated problems
Andrey Zonov writes: > When I try allocated pointer to a pointer, and in it some pointers > (important: size is 2 bytes), the pointers lose their boundaries. Pointers have no boundareis in C. > PS in freebsd < 7, it's ok, in Linux too. Only by accident. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: VirtualBox and vtophys
On Wednesday 24 February 2010 6:41:31 am Jacques Fourie wrote: > I've noticed that my virtualbox vboxdrv.ko started crashing after > updating my 8.0-stable install. The crash occurs when vboxdrv calls > vtophys() on a userland virtual address. Prior to r202894 this was > working fine. Modifying pmap_kextract() to use vtopte() for non-kernel > virtual adresses fixes the problem. Is it intended for vtophys() to > still work on userland virtual addresses? Use pmap_extract(pmap, ...) for user addresses. Granted, that is only reliable if the user pages have been wired in some fashion. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: VirtualBox and vtophys
On Wed, Feb 24, 2010 at 12:41 PM, Jacques Fourie wrote: > I've noticed that my virtualbox vboxdrv.ko started crashing after > updating my 8.0-stable install. The crash occurs when vboxdrv calls > vtophys() on a userland virtual address. Prior to r202894 this was > working fine. Modifying pmap_kextract() to use vtopte() for non-kernel > virtual adresses fixes the problem. Is it intended for vtophys() to > still work on userland virtual addresses? No, vtophys is not intended to be used along with user virtual addresses. -- Gianni ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: 2 bytes allocated problems
On Wednesday 24 February 2010 14:44:35 Andrey Zonov wrote:
> Hi,
>
> When I try allocated pointer to a pointer, and in it some pointers
> (important: size is 2 bytes), the pointers lose their boundaries.
> Why it can happen?
>
> Test program in attach.
Your test program is broken:
>#define S1 "ab"
>#define S2 "cd"
>
>pp = (char **) Malloc(2 * sizeof(char *));
>
>pp[0] = (char *) malloc(2);
>memcpy(pp[0], S1, 2);
>pp[1] = (char *) malloc(2);
>memcpy(pp[1], S2, 2);
>
>printf("%s\n", *pp);
>printf("%s\n", pp[0]);
>printf("%s\n", pp[1]);
Why should *pp == pp[0], or pp[1] be a nul-terminated string? You just copied
the two characters. It's pure luck if there is a \0 at the end of any of
these elements, or that the access doesn't cause a SEGV.
If you do:
>pp[0] = (char *) malloc(3);
>memcpy(pp[0], S1, 3);
>pp[1] = (char *) malloc(3);
>memcpy(pp[1], S2, 3);
instead, you copy the termination and things work as expected.
Regards,
Max
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
2 bytes allocated problems
Hi, When I try allocated pointer to a pointer, and in it some pointers (important: size is 2 bytes), the pointers lose their boundaries. Why it can happen? Test program in attach. PS in freebsd < 7, it's ok, in Linux too. -- Andrey Zonov alloc.c Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: VirtualBox and vtophys
On Wed, 24 Feb 2010 13:41:31 +0200 Jacques Fourie wrote: > I've noticed that my virtualbox vboxdrv.ko started crashing after > updating my 8.0-stable install. The crash occurs when vboxdrv calls > vtophys() on a userland virtual address. Prior to r202894 this was > working fine. Modifying pmap_kextract() to use vtopte() for non-kernel > virtual adresses fixes the problem. Is it intended for vtophys() to > still work on userland virtual addresses? > This was recently (yesterday and today) discussed on freebsd-emulation with subject Virtualbox. See there for suggested actions. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
VirtualBox and vtophys
I've noticed that my virtualbox vboxdrv.ko started crashing after updating my 8.0-stable install. The crash occurs when vboxdrv calls vtophys() on a userland virtual address. Prior to r202894 this was working fine. Modifying pmap_kextract() to use vtopte() for non-kernel virtual adresses fixes the problem. Is it intended for vtophys() to still work on userland virtual addresses? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
