>So this is arguably a Python bug. Did you contacted anybody who cares about
>the Python ?
I did not, mainly because this link:
http://bugs.python.org/msg61870
seems to imply they are already aware of the problem. I agree it must be a
Python bug though. It worked in 2.5.1 but not in 2.5.5 and
On Thu, Feb 25, 2010 at 04:26:22PM -0600, Peter Steele wrote:
> > We'll likely go with this solution instead of downgrading Python and the
> > related libraries.
>
> In fact I came up with another solution. I realized that since the problem
> was related to the process signal mask, instead of ca
> We'll likely go with this solution instead of downgrading Python and the
> related libraries.
In fact I came up with another solution. I realized that since the problem was
related to the process signal mask, instead of called ntpd directly, wrap it up
in a C app that resets the signal mask t
On Thu, Feb 25, 2010 at 09:57:48AM -0600, Peter Steele wrote:
> >Very wild guess, check the process signal mask of the child for both methods
> >of spawning.
>
> I'm running ntpd through Python. How do I check the process signal mask? I
> did some quick searches and it seems Python does not supp
>Very wild guess, check the process signal mask of the child for both methods
>of spawning.
I'm running ntpd through Python. How do I check the process signal mask? I did
some quick searches and it seems Python does not support sigprocmask().
In my searches I came across this link:
http://bug
On Thu, Feb 25, 2010 at 08:12:05AM -0600, Peter Steele wrote:
> >I think problem not in ntpd, since I use ntpdate. And in 50% times, when it
> >run from startup script, it hangs with kernel.
> >No Ctrl+C work, kernel don`t answer for ping, just freeze.
> >Problem somewhere in kernel, maybe in subs
>I think problem not in ntpd, since I use ntpdate. And in 50% times, when it
>run from startup script, it hangs with kernel.
>No Ctrl+C work, kernel don`t answer for ping, just freeze.
>Problem somewhere in kernel, maybe in subsystems that set new time, maybe in
>network(UDP) parts.
>This problem
Alexey Shuvaev writes:
> The flag you should look at is '-g'. GCC supports debuggind symbols
> together with -O2 optimizations.
It is generally not a good idea to use -O2 for debugging versions, since
gcc will optimize away many local variables.
DES
--
Dag-Erling Smørgrav - d...@des.no
On Wed, Feb 24, 2010 at 03:56:35PM -0600, Peter Steele wrote:
> >> 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=
On Wed, 24 Feb 2010 15:56:35 -0600
Peter Steele wrote:
>> >> 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
>> 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.freeb
>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--th
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
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
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
>> 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 instea
>> 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 buil
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
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:
>
> e
>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
>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.
Yeah, you're right. This is definitely an annoying bug...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.o
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.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any ma
>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
On Fri, 19 Feb 2010, Peter Steele wrote:
> I posted this originally on the -questions list but did not make any headway.
> We have an application where the user can change the date/time via a GUI. One
> of the options the user has is to specify that the time is to be synced using
> ntp. Our co
I posted this originally on the -questions list but did not make any headway.
We have an application where the user can change the date/time via a GUI. One
of the options the user has is to specify that the time is to be synced using
ntp. Our coding worked fine under BSD 7 but since we've moved
25 matches
Mail list logo
