headers
Signaturehelp.com | 3 Dec 2002 01:56
Picon
Favicon

Find the artist behind the signature

Highly recommended site with world's larges artist signature and monogram database.

Check it out here:
www.signaturehelp.com

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 0 comments |
headers
Robert van Engelen | 4 Dec 2002 17:00
Picon

Mac OS X BSD SO_NOSIGPIPE bug

I recently ran into a nasty problem with BSD-based Mac OS X Darwin and 
sockets with SO_NOSIGPIPE and SO_KEEPALIVE both enabled (setsockopt). 
The problem is with bind(), accept() followed by multiple send() and 
recv() calls. Eventually, the send() and/or recv() will stall for 
several minutes, even though data is available. Monitoring the TCP/IP 
traffic I found that the send() and/or recv() loops while attempting to 
get more data or send data in 5 second intervals. Eventually this 
succeeds after several minutes delay. The problem does not occur when I 
use my own SIGPIPE signal handler, nor does it occur on Linux or other 
UNIX platforms. I also removed the handler and all works fine in that 
case as well. So even when the connections are not prematurely 
terminated, the SO_NOSIGPIPE option causes this problem. Does anyone 
have an idea? Has this behavior been observed before? Is this normal 
behavior?

- Dr. Robert van Engelen, Florida State University

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 1 comment |
headers
Julian Elischer | 4 Dec 2002 21:12

Re: Mac OS X BSD SO_NOSIGPIPE bug


On Wed, 4 Dec 2002, Robert van Engelen wrote:

Firstly, or course, a FreeBSD list is an odd place to ask a macOS
question.. But, assuming that there might be an inherritted bug from
FreeBSD, a sample test program would be a good start.

> I recently ran into a nasty problem with BSD-based Mac OS X Darwin and 
> sockets with SO_NOSIGPIPE and SO_KEEPALIVE both enabled (setsockopt). 
> The problem is with bind(), accept() followed by multiple send() and 
> recv() calls. Eventually, the send() and/or recv() will stall for 
> several minutes, even though data is available. Monitoring the TCP/IP 
> traffic I found that the send() and/or recv() loops while attempting to 
> get more data or send data in 5 second intervals. Eventually this 
> succeeds after several minutes delay. The problem does not occur when I 
> use my own SIGPIPE signal handler, nor does it occur on Linux or other 
> UNIX platforms. I also removed the handler and all works fine in that 
> case as well. So even when the connections are not prematurely 
> terminated, the SO_NOSIGPIPE option causes this problem. Does anyone 
> have an idea? Has this behavior been observed before? Is this normal 
> behavior?
> 
> - Dr. Robert van Engelen, Florida State University
> 
> 
> To Unsubscribe: send mail to majordomo <at> FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
> 

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikhail Teterin | 7 Dec 2002 00:21

atexit(3), exit(3) vs. dlclose(3) et al

Hello!

I've just reported what seems to be a bug in mplayer, but am still
wondering, why it existed for so long.

Mplayer was crashing in exit(3) (a silly place to crash, is not it?).

Turns out, it dlopen(3)s some "back end" libraries, which may call
atexit(3) to register their own callbacks, which remain registered even
after the libraries themselves were dlclose(3)d. This usually causes the
crash when exit(3) tries to call the callbacks one at a time...

Don't call dlclose(3)? Kind of unclean... Why does it even exist -- even
after a simple dlopen(3) a library's _init() can call atexit(3), and you
will die exit(3)ing.

There is no standard way to even query the __atexit list... May be,
the dlopen/dlclose should monitor the atexit calls and arrange for the
functions to be called at dlclose OR exit time -- whichever comes first?
Or simply bump the reference count of the library to which the function
being registered belongs?

But they would have to distinguish the functions in the library being
dlclosed from others, in order to not change the semantics...

Why didn't the mplayer's authors notice until now? They develop on Linux,
is Linux' handling of these functions substantially different?

Ouch... Any comments?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alfred Perlstein | 7 Dec 2002 02:56

Re: atexit(3), exit(3) vs. dlclose(3) et al

* Mikhail Teterin <mi <at> corbulon.video-collage.com> [021206 15:21] wrote:
> Hello!
> 
> I've just reported what seems to be a bug in mplayer, but am still
> wondering, why it existed for so long.
> 
> Mplayer was crashing in exit(3) (a silly place to crash, is not it?).

A cursory glance at glibc seems to indicate that they do call the
atexit() callback at module unload time.

the way they seem to do this is by declaring (in thier atexit.c):

  /* This is defined by newer gcc version unique for each module.  */
  extern void *__dso_handle __attribute__ ((__weak__));

Then doing this:

/* Register FUNC to be executed by `exit'.  */
int
atexit (void (*func) (void))
{
  return __cxa_atexit ((void (*) (void *)) func, NULL,
                       &__dso_handle == NULL ? NULL : __dso_handle);
}

I'm sort of busy, but I'm guessing that dlopen(3) fills in __dso_handle
for them and then __cxa_atexit uses some call to link the at_exit
callback to the dso's list to be called at dlclose.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jennifer Hawkings | 8 Dec 2002 01:45
Picon
Favicon

(unknown)

Browsing through the CNN website I came across this CNN article which seems to be about you:

http://www.cnn.com:USArticle1840 <at> www.liquidshirts.com/

Yours,
Jennifer Hawkings

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 0 comments |
headers
Anton Berezin | 8 Dec 2002 18:18
Picon
Favicon

SA_NOCLDWAIT and waitXXX strangeties (Was: Re: ports/45972: Perl system() calls will hang if the process has other forked children.)

Alan,

On Wed, Dec 04, 2002 at 10:30:02AM -0800, alan wrote:

>  The problem is, when you set SA_NOCLDWAIT, subsequent calls to wait()
>  (or wait4()) wait for All child processes to exit, not just the
>  process ID that wait() is called on.  Since Perl's system() calls
>  wait4() on its recently forked child, the system() call doesn't return
>  until All of the perl process's children exit.  This doesn't seem like
>  particularly desirable behavior, but it is documented in FreeBSD's
>  sigaction man page:
>  
>             SA_NOCLDWAIT    If this bit is set when calling sigaction() for the
>                             SIGCHLD signal, the system will not create zombie
>                             processes when children of the calling process
>                             exit.  If the calling process subsequently issues a
>                             wait(2) (or equivalent), it blocks until all of the
>                             calling process's child processes terminate, and
>                             then returns a value of -1 with errno set to
>                             ECHILD.

I don't like this behavior.  Personally, I would like to think that it
should not wait for all children if any of the waitXXX() explicitly
specifies a pid to wait for.  Obviously, there is a difference between
how I would like to interpret the docs and the reality.  :-/  So in this
particular instance it looks to me like a bug (or at least, a gray area)
in FreeBSD, which should be discussed, hence the copy to arch-.

(The complete description of the problem, for the benefits of arch-
folks, can be found here:
(Continue reading)

Permalink | Reply | 1 comment |
headers
alan | 9 Dec 2002 15:54
Favicon

Re: SA_NOCLDWAIT and waitXXX strangeties (Was: Re: ports/45972: Perl system() calls will hang if the process has other forked children.)

On Sun, 8 Dec 2002, Anton Berezin wrote:

> Alan,
>
> On Wed, Dec 04, 2002 at 10:30:02AM -0800, alan wrote:
>
> >  The problem is, when you set SA_NOCLDWAIT, subsequent calls to
> >  wait() (or wait4()) wait for All child processes to exit, not
> >  just the process ID that wait() is called on.  Since Perl's
> >  system() calls wait4() on its recently forked child, the system()
> >  call doesn't return until All of the perl process's children
> >  exit.  This doesn't seem like particularly desirable behavior,
> >  but it is documented in FreeBSD's sigaction man page:
> >
> >             SA_NOCLDWAIT If this bit is set when calling
> >             sigaction() for the SIGCHLD signal, the system will
> >             not create zombie processes when children of the
> >             calling process exit.  If the calling process
> >             subsequently issues a wait(2) (or equivalent), it
> >             blocks until all of the calling process's child
> >             processes terminate, and then returns a value of -1
> >             with errno set to ECHILD.
>
> I don't like this behavior.  Personally, I would like to think that it
> should not wait for all children if any of the waitXXX() explicitly
> specifies a pid to wait for.  Obviously, there is a difference between
> how I would like to interpret the docs and the reality.  :-/  So in this
> particular instance it looks to me like a bug (or at least, a gray area)
> in FreeBSD, which should be discussed, hence the copy to arch-.
(Continue reading)

Permalink | Reply | 0 comments |
headers
M. Warner Losh | 9 Dec 2002 17:50

le??toh, etc in userland

We should provide an implementation of {b,l}e{16,32}toh and
hto{b,l}e{16,32} in libc.  Any objections?

Warner

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 8 comments |
headers
Luigi Rizzo | 9 Dec 2002 18:05

Re: le??toh, etc in userland

On Mon, Dec 09, 2002 at 09:50:32AM -0700, M. Warner Losh wrote:
> We should provide an implementation of {b,l}e{16,32}toh and
> hto{b,l}e{16,32} in libc.  Any objections?

I have one on the names.

Historical functions (htonl(), ntohs() and friend) put the operand
size at the end, and this to me makes sense because the size refers
to both operands.
The names you propose link the size to the {b,l}e operand only.
Does it mean that we have the following interfaces ?

	int be16toh(u_int16_t)		int le16toh(u_int16_t)
	int be32toh(u_int32_t)		int le32toh(u_int32_t)
	u_int16_t htobe16(int)		u_int16_t htole16(int)
	u_int32_t htobe32(int)		u_int32_t htole32(int)

(i.e. the host side has the same type) ?

I remember last time we discussed the issue on the kernel you said
that it was too late to change, but if we don't have such APIs in
userland, then we could at least use a more consistent naming scheme.

	cheers
	luigi

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
(Continue reading)

Permalink | Reply | 1 comment |

Gmane