D'oh! I noticed that and fixed it in my tree but didn't see how it could
produce the results you saw. But I think I was believing the bogus gdb
output you showed, and nothing explained those bit patterns if gdb was
showing you the right locations. I've checked in my fix now, which should
be abo
Hi,
The type variable was declared const, so here is a new version.
(I find this resetting of type a bit strange, but it is what is used in the
select case, so I copy it).
2001-10-28 Marcus Brinkmann <[EMAIL PROTECTED]>
* hurd/hurdselect.c (_hurd_select): Set type to zero if
S
On Sat, Oct 27, 2001 at 09:59:15PM -0400, Roland McGrath wrote:
> At a quick glance, the code for both (hurdselect.c) looks the same to me,
> but I don't have time right now to examine it too thoroughly. If the
> problem with poll does not happen with select, then hurdselect.c is almost
> certain
On Sat, Oct 27, 2001 at 10:12:12PM -0400, Roland McGrath wrote:
> > Similar on line 93 already. d[1] is not initalized correctly.
>
> Well, there's nothing but simple C code before that.
> You can step through from the beginning of the function and see it all.
>
> Be careful not to let gdb confu
> Similar on line 93 already. d[1] is not initalized correctly.
Well, there's nothing but simple C code before that.
You can step through from the beginning of the function and see it all.
Be careful not to let gdb confuse you. Sometimes it reports bogus types
for variable-sized arrays.
On Sat, Oct 27, 2001 at 09:59:15PM -0400, Roland McGrath wrote:
> I see. It might be telling to recode it using select and see if it behaves
> the same.
D'oh! We had it using select before, and rewrote syslogd to use poll().
I might be able to just use an old version of the code.
> Of course,
On Sun, Oct 28, 2001 at 02:58:30AM +0100, Marcus Brinkmann wrote:
> > (gdb) print d[1].type
> > $23 = -1962934272
> >
> > If gdb doesn't play tricks on me, this is certainly bogus.
> > Note that the first descriptor (0) is the unix socket, while
> > the second is the inet socket.
>
> Similar on
I see. It might be telling to recode it using select and see if it behaves
the same. Of course, it would be best if you could reproduce the situation
with a simple test program (e.g. have a process that writes on a unix
socket every few seconds, nothing writing on the inet socket, and a simple
p
On Sun, Oct 28, 2001 at 02:50:46AM +0100, Marcus Brinkmann wrote:
> On Sun, Oct 28, 2001 at 02:37:28AM +0100, Marcus Brinkmann wrote:
> > So glibc returns the wrong values in revents for poll. I am now going to
> > look into glibc select code.
> >
>
> Actually, in hurdselect.c, line 394ff:
>
>
On Sun, Oct 28, 2001 at 02:37:28AM +0100, Marcus Brinkmann wrote:
> So glibc returns the wrong values in revents for poll. I am now going to
> look into glibc select code.
>
Actually, in hurdselect.c, line 394ff:
(gdb) print d[0].type
$22 = 9
(gdb) print d[1].type
$23 = -1962934272
If gdb doe
On Sat, Oct 27, 2001 at 09:40:59PM -0400, Roland McGrath wrote:
> That syslogd backtrace just shows that it is waiting in recvfrom,
> as it normally should be. The interesting state is in pflocal.
Actually not, see my follow up information. syslogd listens on
both unix and inet ports, and the r
That syslogd backtrace just shows that it is waiting in recvfrom,
as it normally should be. The interesting state is in pflocal.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Sun, Oct 28, 2001 at 02:06:48AM +0100, Marcus Brinkmann wrote:
> So at least two bugs involved here? It seems so. Below you can see
> the gdb output of syslogd at the time of sudo hanging. I should be able
> to narrow it further than that by debugging syslogd in more detail.
It was instruct
Hi,
I am happy to be able to present some more info on the problems involving
sudo/pflocal/syslogd.
There seem to be a couple of issues. First, it seems that sudo and
pflocal/libpipe seem to work fine in the normal case. What happens
is that sudo sends a diagnostic line to syslogd. syslogd re
14 matches
Mail list logo
