I first thought that the libraries were not threaded but it
appears they are. But you have a compile options to disable
threads.
alkonost{pbelang1}-openldap-2.1.4% ./configure --help|grep -i thread
--with-threads with threads [auto]
Don't know what the impacts are but since Samba is non-
Did you try to compile using OpenLDAP? I think that can
be a "quick" fix.
Otherwise, open a ticket with Sun?
Pierre B.
Jeff Mandel wrote:
trace from 12327:
(gdb) bt
#0 0xfecd9794 in __sigprocmask () from /usr/lib/libthread.so.1
#1 0xfecce1e8 in _deliversigs () from /usr/lib/libthread.so.1
#2
trace from 12327:
(gdb) bt
#0 0xfecd9794 in __sigprocmask () from /usr/lib/libthread.so.1
#1 0xfecce1e8 in _deliversigs () from /usr/lib/libthread.so.1
#2 0xfecd05c4 in thr_sigsetmask () from /usr/lib/libthread.so.1
#3
#4 0xb in ?? ()
#5 0xfecdb1f0 in usleep () from /usr/lib/libthread.so.1
Esh, Andrew wrote:
Also, try loading a few other non-Samba programs into gdb, to see what they
require. Maybe threading is a common library to load.
I have tried this against sshd, httpd, radiusd and lpsched. None are
showing libthread anywhere in the list of symbols.
After latest libthread
Jeff,
Ok, you're using nss_ldap from PDAL to use /etc/nsswitch.conf
like
passwd: ldap files (or reverse)
group: ldap files
etc
Right? (From what I recall that's what nss_ldap is used for).
If you did not compile with Samba, it means that if you do "ldd"
on "smbd" it should not print "libthread"
Thanks for the interesting comments. I will take some time to digest them.
Pierre Belanger wrote:
Now I'm looking back at the truss with the libthread, all
I can say besides that it looks "ugly" , I wish I'd know
how to print what's in each memory location to figure out
if the program is doing
Hello all,
Andrew, true GDB is thread aware but I think last time I used
it (back in ~ 1998) I was writing a multi-threaded application
and I really remember like if it was yesterday: GDB was not
thread aware at that time. I'm glad to hear it's now thread
aware!
I found the following if it can he
lent. It's been too long.
> -Original Message-
> From: Jeff Mandel [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 04, 2003 1:59 PM
> To: David Collier-Brown -- Customer Engineering
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Solaris fcntl CPU/Lock
04, 2003 1:59 PM
> To: David Collier-Brown -- Customer Engineering
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Solaris fcntl CPU/Lock update
>
>
>
> David Collier-Brown -- Customer Engineering wrote:
>
> >On Mon, Feb 03, 2003 at 07:38:31AM -0800, Jeff
ginal Message-
> From: Pierre Belanger [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 04, 2003 5:16 PM
> To: David Collier-Brown -- Customer Engineering
> Cc: [EMAIL PROTECTED]; Christopher R. Hertel
> Subject: Re: Solaris fcntl CPU/Lock update
>
>
> Hello,
>
>
Hello,
David Collier-Brown -- Customer Engineering wrote:
"Christopher R. Hertel" wrote: indirectly to you from pbelanger:
Thanx Christopher to forward the info.
Please let know jra that libnspr4.so and libnss3.so ARE linked
to libpthread and libthread under Solaris
I assume l
"Christopher R. Hertel" wrote: indirectly to you from pbelanger:
> Please let know jra that libnspr4.so and libnss3.so ARE linked
> to libpthread and libthread under Solaris
I assume libnspr4.so and libnss3.so are special libraries
provided as part of open LDAP: the So
let know jra that libnspr4.so and libnss3.so ARE linked
to libpthread and libthread under Solaris
this is concerning the ...
Re: Solaris fcntl CPU/Lock update
--- abartlet_asleep is now known as abartlet
--
Christopher R. Hertel -)- University of M
David Collier-Brown -- Customer Engineering wrote:
On Mon, Feb 03, 2003 at 07:38:31AM -0800, Jeff Mandel wrote:
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
jra wrote:>
This is a much more interesting backtrace than the
other.
On Mon, Feb 03, 2003 at 07:38:31AM -0800, Jeff Mandel wrote:
> > Reading symbols from /usr/lib/libpthread.so.1...done.
> > Loaded symbols for /usr/lib/libpthread.so.1
jra wrote:>
> This is a much more interesting backtrace than the
> other. Why is smbd linking in pthread libraries ?
> smbd is *
On Mon, Feb 03, 2003 at 07:38:31AM -0800, Jeff Mandel wrote:
> Here's gdb with bt from two processes 12279 and 12327
>
> root@reiger# gdb /usr/local/samba/bin/smbd 12279
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License,
Here's gdb with bt from two processes 12279 and 12327
root@reiger# gdb /usr/local/samba/bin/smbd 12279
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under ce
2003 09:07:23 -0800
>From: "Jeff Mandel" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Solaris fcntl CPU/Lock update
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>MIME-Version: 1.0
>Content-Transf
On Fri, Jan 31, 2003 at 09:07:23AM -0800, Jeff Mandel wrote:
> I have followed this fcntl bug closely, and I just applied a T-patch for
> solaris 8 which brought the kernel 108528-19. This includes the fix for
> 4735093. This has not fixed the problem of smbd growing to consume all
> available C
I have followed this fcntl bug closely, and I just applied a T-patch for
solaris 8 which brought the kernel 108528-19. This includes the fix for
4735093. This has not fixed the problem of smbd growing to consume all
available CPU.
Environment is SunOS reiger 5.8 Generic_108528-19 sun4u sparc
SU
20 matches
Mail list logo
